I am developing a Joomla component. In javascript I use jQuery.ajax() for making a (php) controller method put data (from javascript) into the database. However, after installing the component on one Joomla site, it works, but on another site the data passed through jQuery.ajax() is not obtained by JInput::get().

The (simplified) ajax request is as follows:

jQuery.ajax( {
  'type': 'POST',
  'url': 'index.php?option=com_example&task=examplecontroller.handleAjaxRequest',
  'data': { 'ajaxData': 'test' },
  'success': function( ajaxResult ) {
    alert( ajaxResult );
} );

The (simplified) controller method:

public function handleAjaxRequest()
  $app = JFactory::getApplication();
  $input = $app->input;
  echo $input->get( "ajaxData", "defaultValue", "string" );

On one of my sites, an alert with text 'test' is shown as expected. But on the other site, an alert with text 'defaultValue' is shown, indicating that JInput::get() did not find data item 'ajaxData' and used the default value provided in its second parameter.

Both sites are installed on the same domain, each on a different subdomain. So same php version, Joomla upated to the same version (3.9.26), using same jQuery version (in jquery.min.js it says v1.12.4-joomla).

Anyone any idea what or which setting could cause this? I would really appreciate it, because I have no idea any more.


I inspected the $_POST and the $_GET variables: url parameters 'option' and 'task' are present (in $_GET) on both sites, but url parameter 'ajaxData' is only present (in $_POST) on one of the sites.

The .htaccess files are exactly the same on both sites.


2 Answers 2


in such cases I would inspect the $_POST variable to see if anything even gets into Joomla. This is to rule out something is happening within Joomla.

This can be as simple as this pirce of code into your index.php file. This will give a nice formatted output of everything that is posted.

echo __FILE__ . '::' . __LINE__ . ':: ';
echo 'POST: ';
echo '<div style="font-size: 1.5em;">';
echo '</div>';

This way you will know if you need to look at the server or further at the code. In case you have XDebug that would be even better, you can put a breakpoint at where you want to stop in the code.

If you see the ajaxData in that output, you know that it reached the site. If you do not see the ajaxData there is most likely something on the server filtering it out. For example the .htaccess might be doing a redirect and thereby losing the payload.

  • Thanks for your response. I inspected the $_POST and the $_GET: url parameters 'option' and 'task' are present in $_GET on both sites, but url parameter 'ajaxData' is only present in $_POST on one of the sites. The .htaccess files are exactly the same on both sites.
    – Herman
    May 13, 2021 at 7:53
  • @Roland I appreciate that your post is endeavouring to help, but your post is actually assisting in acquiring diagnostic details versus actually resolving the problem of not receiving the data on the server-side. This community can afford some flexibility when volunteers do not have the privilege to comment. It is important that I make this distinction because in other SE communities, your answer would be deleted or converted to a comment under the question -- because it is Not An Answer (does not resolve the question). Hopefully more details come which allow a resolving answer. May 13, 2021 at 8:26
  • @Herman please edit your question body to include these newly discovered details. Researchers will always want the whole story all in one place. Also, the question body offers better formatting than comments. You can even mention in your edit the diagnostic technique that Roland offered. This way his answer can afford to remove the diagnostic step and cut right to the resolving advice. May 13, 2021 at 8:30
  • 1
    @mickmackusa - Thanks for keeping this forum nice and clean. This is why I really appreciate StackExchange (and don't like most other forums). I added the extra info to my question.
    – Herman
    May 13, 2021 at 9:15

I overlooked a rewrite rule in .htaccess that was actually different between both sites. This rewrite rule caused a 301 redirect. The GET parameters, which are in the url itself, were copied to the newly formed url by the rewrite rule, but the POST parameters got lost, because they are not passed on to the new url in a redirect.

Removing this (incorrect) rewrite rule from .htaccess solved the problem.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.