@boldc I've noticed following in your PHP configuration which could be improved.

If you say you have had 4.0.3 working with these settings then they might not be the reason for the issue.

But it's worth a try because to me they seem to be too small.

Your hosting provider's documentation might tell how you can modify PHP ini values. In most cases you just need to place a suitable php.ini file into the folder with your Joomla installation.

Please check and report back the result. Thanks in advance.

memory_limit: 32M

I suggest to increase this to 64M at least.

upload_max_filesize: 2M

This should be increased to 24M at least.

post_max_size: 8M

This should be increased to 24M at least, and it should not be smaller than the previously mentioned upload_max_filesize.

max_input_vars: 1000

This should be increased to 5000.

Hi thank you for your response. I increased to the following:

max_input_vars: 5000
post_max_size: 64M
upload_max_filesize: 32M

And this helped in most cases. However, when I have error reporting enabled, I'm still hitting memory issues (blank white page) when I try to open a custom module I built. The module has a lot of fields, but it is by no means complicated. In order to be able to open the module in the backend without getting a blank white screen, I have to set the following value in php.ini

memory_limit: 256M

Should Joomla debugging require this much? It seems high but I don't have a frame of reference -- I am not well-versed in cPanel, or Joomla 4 debugging memory requirements. I'm just a novice module developer.

@boldc Maybe something is wrong with that module? Does it produce any database queries?

The module does not query any databases. The modules I write are what I would call rudimentary. They use xml fields (mostly list, radio, and text) to collect values which are applied to the CSS styling/layout of the module's text content.

The module does have nested subforms (three subforms total), and I noticed if I removed some of the fields from the last subform, then the module's backend will display normally.

I ran the subform through an XML validator, and tried removing particular fields to see if there was an error in one of them. But the issue does not appear to be with the content of the XML fields, but rather the quantity of XML fields. If I turn off Joomla debugging, the module's admin will display using

memory_limit: 128M

Other modules appear to work fine with if the memory_limit is 64M. Am I abusing Joomla's memory usage because of nesting subforms, or too many XML fields, or both?

Module's xml: 47 fields
Subform: 1 field
Sub-Subform: 5 fields
Sub-Sub-Subform: 38 fields

Not all fields are displayed at once because a lot of them are conditional (they use showon=)

Am I abusing Joomla's memory usage because of nesting subforms, or too many XML fields, or both?

@boldc I have no idea ? Maybe @Fedik has?

Anyway it seems not to be an issue or a bug with the CMS core. The ini values which I had advised to use are our recommended minimum values times 1.5 to have some reserve.

So I think this issue can be closed as not a core issue (if we don't get some other opinion within a reasonable time).

The problem is the total number of fields. showon only visually hides the field

This was the reason you had to increase the max_input_vars

Sub-Subform: 5 fields
Sub-Sub-Subform: 38 fields

That seems not much, but when you create 10 rows it will be huge.
You better find a way to do what you doing in other way.

Subform not very memory friendly, especially with a loot nested subforms.

Thank you Richard, Brian & Fedik for the info! If had better dev skills I would convert the module into a component. Perhaps I can find fields to migrate to the main xml (or triage them).

@boldc So we can close the issue or you close it yourself?

Thanks