Hello ciabz,

have you try to update SEBLOD with the 3.5.1 update (fix some bugs on Joomla 3.4).

When you said, "creating more fields", about how many are you speaking ?

We have update some website J3.4 and don't see this kind of issue.

Which kind of storage have you set for your fields ?

Best regards.

Lionel

Hi Lionel! Thank you for your answer! No I did not update to Seblod 3.5.1 yet. I´m trying to figure out where is the problem before the update. The info about version 3.5.1 does not mention this kind of problem. My form has 32 fields on ADMIN and 97 on SITE and the fields are stored as standard article mode. The form was working fine before the update to Joomla 3.4....

Hi there! Ok, just update to SEBLOD 3.5.1 running on Joomla 3.4 and the problem persists.... The backend editing of my form is useless, just can not change fields on SITE VIEW. Any clues? Thanks.

Lionel -

I've just encountered a similar (though not identical issue) using SEBLOD 3.5.1 on Joomla 3.4. I have a content type with 171 fields that worked fine on another system (J3.3.6), but on my development workstation with SEBLOD 3.5.1 and J3.4, after adding 124 fields, I can no longer add fields to the form using the Add Field (+) link. I CAN save the form, and can even add fields that already exist, but I'm unable to create new fields through the Form Construction Site view. Maybe related, I don't know, but sharing this info in case it is and is helpful.

Best,
Denver

Hello Denverh,

the problem of fields number is essentially due to the variable "max_input_vars" which is probably different on your 2 workstations.

Best regards.

Lionel

Hello,

The problem is not alone "max_input_vars".
The "post_max_size" and the "memory_limit" must be adjusted accordingly.
The default post_max_size is 8M.
That's not enough for so many fields.

Best regards.

Paul

Hi folks! Thanks for the infos! What would be the best settings for the "post_max_size" and the "memory_limit" if you have about 100 fields on your form?

Hi there! Thanks for the infos. I think the problem is not related to post_max_size and the memory_limit settings. They are set on my domain to post_max_size = 64Mb and memory_limit = 256Mb. As long as I can see this is a SEBLOD bug indeed.

All the best,

ciabz

I don't want to muddy the discussion if our problems are unrelated, but on the chance they are, I'll add this, because I don't think we fully understand this. Remember, I can save the form, but can't add fields to it.

I am familiar with the resource requirements for memory_limit, post_max_size, and max_input_vars and, in fact, considered they were the issue. But increasing them has not resolved it. Note also that the WORKING system has much lower resource limits. Here is a summary of settings and results (info from Joomla PHP Information screen):

TEST INSTANCE (This is working now with a form of 171 fields. I can send a link and you can verify it. I understand these limits are low and so I'm using higher ones in development, but my point is these are working and the higher limits are not.):

max_input_vars = 1000
memory_limit = 64M
post_max_size= 8M

PRIOR DEV INSTANCE (Was working fine with the same form of 171 fields.):

max_input_vars = 4000
memory_limit = 128M
post_max_size = 32M

NEW DEV INSTANCE (Replaced prior dev instance, but now not working with same form with only 124 fields.):

max_input_vars = 6000
memory_limit = 256M
post_max_size = 64M

NOTE: The new development system is a brand new, very clean install of Joomla 3.4 and SEBLOD 3.5.1. At this point, the resource limits on my new dev workstation are quite high, but it still doesn't work. Keep in mind another difference is that on the working systems, the object type is FREE, but on the new workstation, the object type is Article. I created the new instance to refactor the application, in part, to use Article object in several places where I had used Free.

Hi denverth! Thank you for you contribuition, I´m sure we´re all giving a hand to try to solve this recursive issue. Please, give me some more info: on backend, when editing a form, can you go from tab SITE FORM to ADMIN FORM without problems? Can you save your form both on SITE FORM and ADMIN FORM tabs? You said you can save your form but what kind of edition can you make? Now turning to my case:

1. My form has 32 fields on ADMIN and 97 on SITE and PHP configuration with super extra limits.

2. If I open the form (on backend) clicking on the number of SITE fields on Form and Content Type Manager I can not navigate to ADMIN FORM tab. Clicking on ADMIN tab I get the message:

The most recent request was denied because it contained an invalid security token. Please refresh the page and try again.

3. If I open the form (on backend) clicking on the number of ADMIN fields, again I can not access the tab SITE FORM, getting the annoying message above.

4. Now, if I open the form clicking on the number of ADMIN fields I can edit, create and remove fields from this tab (ADMIN FORM) and the form saves OK, showing the nice green message, as long as I do not click on SITE tab.

For those reasons I think the problem is a SEBLOD one, not Joomla nor server configuration: the very SAME form does not behave as it should if it was a Joomla or server issue.

Hope someone else drop a few more ideas. Cheers,

ciabz

ciabz,

I have discovered and corrected the cause of the problems I was experiencing. I was refactoring my application, converting the content type object from Free to Article. My original content type (Free) was using a highly optimized table for field storage. The new content type, based on the Article object type was using the cck_store_form type table that was made up of fields nearly all of them using VARCHAR(255). By taking some time to optimize the table structure to use more efficient field types and sizes, my problem was resolved. Not sure if this could be a cause for your issue, but with such a large content type having so many fields, you may also wish to look into this as a possible contributing factor.

Thanks a lot Denver! Totally agree.

I've added a Tips & Tricks article based on my experience. It addresses the matter of PHP resources and also optimization of field types and sizes:

http://www.seblod.com/resources/tutorials/working-with-large-forms-having-many-fields

Hi Denverth! Thanks for the clues but unfortunatelly optimazation of my cck_store_form type table did not help. In fact this table has only 33 columns, several fields are storage in #__content. It seems that the number of fields is not the main issue. I went back to a previous version of my form, with only 37 fields (from 97) and it did not work, but going back to an older version, with 35 fields, by magic, it start working. I really don´t know what to think about that... All the best,

ciabz

Nice thread. Would it be an idea to write something about when to alter the table, and to what in accordance to field type etc? To understand better HOW to optimize. 

I understand that I can alter, but I don't understant what would make it better then default..

Hi Kenneth,

To be clear, the kind of optimization I'm referring to is related to the sizes and types of fields and not for performance per se. So, for example, if you have a decimal numeric value requiring 2 digits precision, you COULD store it in the Text field's default type of VARCHAR(255). But storing it as a DECIMAL(10,2) field may be more appropriate, especially if you will perform arithmetic operations on it. Disk storage is cheap, so it's hard to make an argument for optimization solely on the storage space required, but good practice dictates using the most appropriate data type and size for storing data, if only as a final constraint to ensure that only valid data can be stored. Again, in our example that only requires 2 digits precision, the VARCHAR would allow an arbitrarily long value up to 255 characters (alpha or numeric) whereas the DECIMAL(10,2) type field would only allow numeric values up to a known size and up to 2 digits precision. I'm not familiar enough with internals of SEBLOD to know whether this can be an issue also, but for some types of database operations a VARCHAR requires the database to grant memory for query operations based on the maximum declared size of the field-- in our example, 255 bytes. Having lots of fields of the larger VARCHAR types when smaller, more efficient data types can be used, would reserve resources (ie - memory) unnecessarily. And finally, while I don't know exactly WHY it is so, I do know that I've encountered issues where I've been unable to save or continue configuring SEBLOD content types having many text fields of the unnecessarily large VARCHAR(255) that is the default for a Text field, until I've altered all the fields' storage types to types and sizes more appropriate for what is actually required for the field.

Hope this is helpful.

Denver

Hi there! I´m trying to explore this non-saving-recursive-misterious problem from another perspective. Clearly there is a connection between the break of form saving functionality and the invalid token problem. I did a search on this forum (and how I did!) trying to figure out if the token problem is a Joomla or Seblod issue. As long as I can see this is a Seblod issue and I didn´t find any solid solution. The max_input_vars and similar PHP server configuration have nothing to do with token validation. That´s why I think the token issue might be the root of the breaking of the backend saving functionality. Any clues, suggestions or comments will be very welcome! Regards,

ciabz

Hi there! Several days and still in the dark.... To my despair the backend form edition is still useless.... Octopools staff: any clues, help or tip? Regards,

ciabz

Hi Ciabz,

The token issue is mainly due to the fact to have different web navigator windows opened. It controls that no field value has been changed manually, it's a security purpose. The token issue is not related to the number of fields.

Your number of fields is small. It will be surprising to see an issue on this side.

Please add some screenshots about the concerned content type and the message.

Please try to install your website locally and let us know.

Thanks.

Thanks for your feedback!

Thanks a lot, I worked on this problem for weeks, happy to see a working fix !

However, I don't know where my php.ini file is located (not in the directeries I have access to, maybe in some parent directory). Do you know where it is located with ovh mutual servers ?

thanks again !

Hello! Usually the php.ini is on a folder on your server not necessarly on the same folder of your Joomla instalations. This is because you can use the same php configuration to all the Joomla instances. You can save a copy of a php.ini on the root of your Joomla instalation and configure the .htacess to point to this file to customize default configurations. If you do not have access to the php.ini file, ask your server staff to place a copy where you can find, send it to the correct place and than edit it using some text editor. Regards,

Ciabz

Hi,

Thanks a lot. However, with my host, I won’t have a copy of php.ini  (it’s ovh mutual).

Can I make those changes via the .htacces only ? On their guide they say that some php option can be set there.

Hi ciabz, thank you very much!

Your message has helped me solve my problem 37 fields

Five months and some versions later, I want to report that we still have this issue. 

I tried everything on this thread with no success. I uploaded a php.ini but it dosent make much difference, btw not all of us have access to the server php ini, some dont work with a vps server, most of our clients do not have one too.

I even used a ini_set function on template index with no success.

My form has less than 50 fields, I am using seblod 3.7.1 with 3.4.3. I cannot save my admin form and I am seeing the message "The most recent request was denied because it contained an invalid security token." almost every time I switch from admin, site, content and intro.

This is a huge issue,If i cant save this form this stop my entire work.

Hi,

@Kleber, it's not related to SEBLOD. Please check your Joomla table session.

More information http://stackoverflow.com/questions/26916716/invalid-security-token-on-joomla-login

Thanks

Hi,

I am experiencing this same issue on my form of less than 10 fields with Joomla! 3.4.4 and seblod 3.7.2 installation on Amazon EC2 instance.

My for process and return to the form page emptied. No any error message is displayed.

Any permanent fix for this?

Thanks for your time in advance.

Hi Yusuf,

Thanks to follow forum rules:

#1 Your message must begin with something like that: "Hi, Hello.."
#2 Your message must end with something like that: "Thanks, Thank you.."
#3 You must give as much details as possible about your question/issue..

What's your error message?

Thanks.

Hi, sorry about that, I have updated the post. Thanks