Hmm, to me that looks like a new feature as it adds a new configuration option to the plugin.

New features would have to go into 6.1-dev.

Hmm, to me that looks like a new feature as it adds a new configuration option to the plugin.

New features would have to go into 6.1-dev.

I could apply the fix without the additional configuration option. But I did not see any harm in adding that option.

People are unable to use the login module when the page cache plugin is enabled. So we need to fix it as soon as possible.

Would you also like me to create separate pull requests to 5.4-dev and 6.1-dev?

I could apply the fix without the additional configuration option. But I did not see any harm in adding that option.

@AbhishekDas Is does not matter if it does harm or not. We follow Semantic Versioning https://semver.org/ .

A new configuration option normally counts as a new feature.

Would you also like me to create separate pull requests to 5.4-dev and 6.1-dev?

No, it does not make sense to create 3 separate pull requests. But the one pull request has to be created for the right branch.

5.4 and 6.0 had already feature freeze, so new features go into 6.1 and nowhere else.

We will discuss it in the CMS Maintainers team and come back to you here with the result.

Depending on that, you or we might have to rebase your branch for this PR.

@richard67 Ok. I thought it was a bug fix.

I'll wait for your update.

realistically the page cache plugin should not be used for a site requiring login. its only intended for very static sites

There is existing code in the CMS addressing the exact scenario mentioned in this PR:

I have tested this item 🔴 unsuccessfully on 1814726

I'm unable to reproduce the described issue.

realistically the page cache plugin should not be used for a site requiring login. its only intended for very static sites

@brianteeman Yes, I also used to say the same thing to everyone until we added the "Exclude Menu Items" and "Exclude URLs" options to the plugin. But now they use it on all sites, including very dynamic ecommerce websites. So, they also want the login module to function correctly.

Did you check if the performance was improved. On good hosting I never saw any measurable performance

There is existing code in the CMS addressing the exact scenario mentioned in this PR:

joomla-cms/libraries/src/Cache/Cache.php

Lines 540 to 547 in 3507660

	if (isset($data['body'])) {
	$token = Session::getFormToken();
	$search = '#<input type="hidden" name="[0-9a-f]{32}" value="1">#';
	$replacement = '<input type="hidden" name="' . $token . '" value="1">';
	$data['body'] = preg_replace($search, $replacement, $data['body']);
	$body = $data['body'];
	}

@SniperSister Yes, that indeed does the job. It seems the customer was on an older version. I am closing this PR.

Did you check if the performance was improved. On good hosting I never saw any measurable performance

Yes, it does help a few sites that run query-heavy extensions and are hosted on shared servers.