jquery ajax from a C5 tools file resulting in a 302 redirect
Permalink
This simple script:
(or something jQuery similar, like, $.load() ) always hits a 302 redirect from my localhost Apache2 server, which makes ".html(data)" the contents from the referrer.
The flow is:
1) A single_page calls a tools/form_dialog.php, the contents of which load into a modal dialog.
2) The modal dialog then calls another tools/response.php, which I hope to place it's contents into a specified div# on the original single_page. (Which succeeds nicely if I rig it up to temporarily bypass this redirection just as a proof of concept.)
3) Therefore, the only problem is the 302 redirect when calling the tools/response.php.
All files are chmod and chown correctly. I don't see any other js in the jQuery.queue (but I'm wondering if I am debugging that correctly).
Is there something about C5 that would be preventing this? Why would a call from a single_pages/view.php to a tools/file1.php load nicely, but a call from that tools/file1.php to another tools/file2.php cause a 302 redirect?
Thanks,
$.ajax({ url: 'index.php/tools/members/get_member_info.php', success: function(data) { $('#history-results').html(data); alert('Load was performed'); } });
(or something jQuery similar, like, $.load() ) always hits a 302 redirect from my localhost Apache2 server, which makes ".html(data)" the contents from the referrer.
The flow is:
1) A single_page calls a tools/form_dialog.php, the contents of which load into a modal dialog.
2) The modal dialog then calls another tools/response.php, which I hope to place it's contents into a specified div# on the original single_page. (Which succeeds nicely if I rig it up to temporarily bypass this redirection just as a proof of concept.)
3) Therefore, the only problem is the 302 redirect when calling the tools/response.php.
All files are chmod and chown correctly. I don't see any other js in the jQuery.queue (but I'm wondering if I am debugging that correctly).
Is there something about C5 that would be preventing this? Why would a call from a single_pages/view.php to a tools/file1.php load nicely, but a call from that tools/file1.php to another tools/file2.php cause a 302 redirect?
Thanks,
Can anyone explain any issues/solutions they have had with Concrete5 and unexpected 302 redirects?
A few ideas...
Are you using the validation helper in the tools? Sometimes getting that wrong can cause unexpected results.
Do you have 'exit' at the end of the tools?
You might find the jQuery $().load() ajax method saves you code processing the result. The basic $.ajax method is not really meant for end users, more something all the other jQuery methods build on top of.
Are you using the validation helper in the tools? Sometimes getting that wrong can cause unexpected results.
Do you have 'exit' at the end of the tools?
You might find the jQuery $().load() ajax method saves you code processing the result. The basic $.ajax method is not really meant for end users, more something all the other jQuery methods build on top of.
Hey John, I didn't think the Brits stored anything worthwhile on the western seaboard! Looks like the Parliament lost track of you! :)
Thanks so much for the response. Actually, none of your suggestions proved right, but I'll keep them in mind because they were all good.
I wasn't even sending form data (yet), I was just trying to rewrite a simple div using ajax (or load(), same problem existed in both). I thought the <? exit(); ?> would have done it. But what did do it - for curiosity sake - was simply not using a relative URL, even though I had gone down to index.php...all the way up, the solution was simply /index.php... Not so with the initial call to the first tool file, though; that call had no problem with a relative URL.
I was going to investigate the BASE_URL settings (concrete/config files) next, but now that I've discovered the cure, why bother (right?). :)
Thanks so much for the response. Actually, none of your suggestions proved right, but I'll keep them in mind because they were all good.
I wasn't even sending form data (yet), I was just trying to rewrite a simple div using ajax (or load(), same problem existed in both). I thought the <? exit(); ?> would have done it. But what did do it - for curiosity sake - was simply not using a relative URL, even though I had gone down to index.php...all the way up, the solution was simply /index.php... Not so with the initial call to the first tool file, though; that call had no problem with a relative URL.
I was going to investigate the BASE_URL settings (concrete/config files) next, but now that I've discovered the cure, why bother (right?). :)
That leading '/'; its tripped me up in the past and I spent ages tracking it down.
With that in mind, if the tool is in /my_packagename/tools/ you could probably use:
I have only given the package tool example because that is code I am currently working with. There are variations for getting a url for site tools and block tools.
With that in mind, if the tool is in /my_packagename/tools/ you could probably use:
$uh = Loader::helper('concrete/urls'); $next_tool_url = $uh->getToolsURL('next_tool_name', 'my_packagename');
I have only given the package tool example because that is code I am currently working with. There are variations for getting a url for site tools and block tools.
I thought so too, but (in the helpers/concrete/urls.php):
does not put the leading slash and I do not see it implemented in any of the REL_DIR and BASE_DIR definitions in the concrete/config/base.php So I began hard coding the url and only when I implemented the leading slash did I eliminate the 302 error.
(Thanks for your contributions to C5.)
public function getToolsURL($tool, $pkgHandle = null) { if ($pkgHandle != null) { $url = REL_DIR_FILES_TOOLS_PACKAGES . '/' . $pkgHandle . '/' . $tool; return $url; } else { if (file_exists(DIR_BASE . '/' . DIRNAME_TOOLS . '/' . $tool . '.php')) { return REL_DIR_FILES_TOOLS . '/' . $tool; } else { return REL_DIR_FILES_TOOLS_REQUIRED . '/' . $tool; } } }
does not put the leading slash and I do not see it implemented in any of the REL_DIR and BASE_DIR definitions in the concrete/config/base.php So I began hard coding the url and only when I implemented the leading slash did I eliminate the 302 error.
(Thanks for your contributions to C5.)
Perhaps the config/site.php has a missing or dodgy definition of DIR_REL or BASE_URL, or the equivalent rewrite in .htaccess. This can be especially tricky when on loaclhost and not in the web root.
Can you look in the network tab of the inspector to see what the actual headers and request URL is?
Do you happen to have pretty urls enabled? I wonder if this is an interaction between redirection for pretty URLs, and the fact that you are hard-coding the URLs. You probably want to construct the URL to the tools programmatically.
Do you happen to have pretty urls enabled? I wonder if this is an interaction between redirection for pretty URLs, and the fact that you are hard-coding the URLs. You probably want to construct the URL to the tools programmatically.
Thanks for your time, xaritas. I listed the actual solution in my response to John. The headers showed what I mentioned in my OP. Pretty URLs were NOT enabled.
