Input variables exceeded 1000 (to big table sets in JCB) #136

New Issue

Closed

opened 2017-10-10 20:08:00 +00:00 by Llewellyn · 7 comments

Llewellyn commented

2017-10-10 20:08:00 +00:00

Owner

I am moving all repeatable fields to subforms in JCB as most of you know by now. But I have run into an issue that may cause some headaches to say the least.

Repeatable fields were stored in a single field as json, but the subforms are not, this means when a page has many subforms the variables skyrocket... and this is the case with Admin Views, not to even mention Joomla Component Views. So now we run into the following error soon as we start to really use these subforms.

PHP Warning:  Unknown: Input variables exceeded 1000.
To increase the limit change max_input_vars in php.ini.

Option One

This seems like a case to decouple many of the tabs (consepts) from the Admin and Joomla Component Views. So that we will have smaller tables and smaller forms. I mean the Joomla Component Table has nearly 200 columns....

Option Two

The other option is that all those who use JCB increase the max_input_vars to about 5000 at least. Yet this is usually discourage as bad practice.

I would really appreciate some input from the community.

The implication of option one

Will really bump my time to do this... this is not a good time for this
Will make JCB even more complex then before
Will do amazing scalability and faster page load
Will remain easy to run JCB on shared hosting

The implication of option two

Will be a quick fix
Will break good practice of micro components
Will not run well on shared environments
I really hate this option.... but wow, I am even more upset at Joomla for removing something that worked, Repeatable Fields.

I am almost finished with the next update that would have removed repeatable fields from site_view, custom_admin_view and admin_view. Then during testing I opened some admin views and when trying to save it... landed back on the dashboard. Looking at the logs I discoverer the above error... so now the big question.

Does any of you know how we can better resolve this issue?

I am moving all repeatable fields to subforms in JCB as most of you know by now. But I have run into an issue that may cause some headaches to say the least. Repeatable fields were stored in a single field as json, but the subforms are not, this means when a page has many subforms the variables skyrocket... and this is the case with Admin Views, not to even mention Joomla Component Views. So now we run into the following error soon as we start to really use these subforms. ``` PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. ``` ### Option One This seems like a case to decouple many of the tabs (consepts) from the Admin and Joomla Component Views. So that we will have smaller tables and smaller forms. I mean the Joomla Component Table has nearly 200 columns.... ### Option Two The other option is that all those who use JCB increase the `max_input_vars` to about 5000 at least. Yet this is usually discourage as bad practice. ## I would really appreciate some input from the community. ### The implication of option one - Will really bump my time to do this... this is not a good time for this - Will make JCB even more complex then before - Will do amazing scalability and faster page load - Will remain easy to run JCB on shared hosting ### The implication of option two - Will be a quick fix - Will break good practice of micro components - Will not run well on shared environments - I really hate this option.... but wow, I am even more upset at Joomla for removing something that worked, **Repeatable Fields**. > I am almost finished with the next update that would have removed repeatable fields from site_view, custom_admin_view and admin_view. Then during testing I opened some admin views and when trying to save it... landed back on the dashboard. Looking at the logs I discoverer the above error... so now the big question. # Does any of you know how we can better resolve this issue?

kevincam3 commented

2017-10-10 20:14:30 +00:00

(Migrated from github.com)

Author

Owner

I wish I was that good of a PHP programmer to have something to offer. I run JCB only on my localhost so for now I have no problem with just bumping up the max_input_vars

mwweb commented

2017-10-10 20:26:10 +00:00

(Migrated from github.com)

Author

Owner

For now, at least, it might be best to REQUIRE the increase of max_input_vars to 5000, for the initial major upgrade, perhaps with a notice upon install or update about the requirement, but that this "issue" will be resolved in a future release.

That way, anyone using JCB will know about this major change and requirement. Then, as time permits, gradually start decoupling the tabs. Then, as a tab is decoupled, push a minor update, then another. Baby steps. Once all the decoupling is done, then there could be a notice that users can lower max_input_vars back to 1000.

It may not be the "best practices" method, but to me it would be the sensible method in making these major changes.

I, too, only run JCB on my localhost. For ease, since there are other things that Joomla has depreciated and will be removed in J!4 (see my notes on issue 126 about JRequest and JError being depreciated). It actually looks like a lot of the legacy functions may be getting removed in J!4, as part of a cleanup of the code. For now, at least, it might be best to _REQUIRE_ the increase of max_input_vars to 5000, for the initial major upgrade, perhaps with a notice upon install or update about the requirement, but that this "issue" will be resolved in a future release. That way, anyone using JCB will know about this major change and requirement. Then, as time permits, gradually start decoupling the tabs. Then, as a tab is decoupled, push a minor update, then another. Baby steps. Once all the decoupling is done, then there could be a notice that users can lower max_input_vars back to 1000. It may not be the "best practices" method, but to me it would be the sensible method in making these major changes.

Flicka2510 commented

2017-10-10 21:58:01 +00:00

(Migrated from github.com)

Author

Owner

Yea, do the notice on install and or update.

We already established that this is a developers tool, so it should be no problem for those using it to update the php.ini with the required values.

You could point newbies in the right direction with some guidance to how this is done. But mostly all devs should already have their mind around this.

Yea, do the notice on install and or update. We already established that this is a developers tool, so it should be no problem for those using it to update the php.ini with the required values. You could point newbies in the right direction with some guidance to how this is done. But mostly all devs should already have their mind around this.

ro-ot commented

2017-10-11 23:49:39 +00:00

(Migrated from github.com)

Author

Owner

@Llewellynvdm I think it will help if you remove all the field permissions from the admin and Joomla component views. This alone is adding very heavy load on this views.

I did a check and it seems like the admin view has around 500 variables on the page, but if you add the permissions fields you have almost 80 per user group. So dumping the permissions may just do the trick for now.

@Llewellynvdm I think it will help if you remove all the **field permissions** from the admin and Joomla component views. This alone is adding very heavy load on this views. I did a check and it seems like the admin view has around 500 variables on the page, but if you add the permissions fields you have almost 80 per user group. So dumping the permissions may just do the trick for now.

Llewellyn commented

2017-10-12 00:35:13 +00:00

Author

Owner

I am seeing a huge slowdown on the JCB admin and component views. Many subforms on one view/page is really not working that well. It is really a headache. I have removed the permissions... but it is still very slow on big admin views like JCB's own admin view in admin view... takes 30 seconds just to open, and almost a minute to save. I will push the staging branch up so you all can test it and give me feedback.

Llewellyn commented

2017-10-12 00:44:40 +00:00

Author

Owner

Just a little heads-up the staging branch can not yet be used in production... only testing. It can not import or export JCB packages at this time.

IT seems like the option to decouple a few concepts from the admin view is inevitable.

Just a little heads-up the staging branch can not yet be used in production... only testing. It can not import or export JCB packages at this time. IT seems like the option to decouple a few concepts from the admin view is inevitable.

Llewellyn commented

2017-10-14 03:55:32 +00:00

Author

Owner

We had to go with the decoupling option. Those of you who can please test the following pull request

IF you need help to know how to run a test, what this video!

We had to go with the decoupling option. Those of you who can please test the [following pull request](https://github.com/vdm-io/Joomla-Component-Builder/pull/138) IF you need help to know how to run a test, [what this video](https://youtu.be/cxryVA5Cni8)!