OK, SEBLOD is just amazing, no doubt about it, but sometimes I feel I'm in dark. That´s what is going on: using SEBLOD 3.5.0 and Joomla 3.6.6 I made a form with few fields. It worked fine but including (creating) more fields it stop saving (and no message Item Saved). After a few searches I figured out that my PHP configuration was not OK, so I change the configuration to:
max_input_vars = 9000
max_file_uploads = 50
Everything was fine than but now, after the update to Joomla 3.4.0 the Not Saving problem is back again! And with a variation: on the ADMIN VIEW it works fine (saving, showing message) and on SITE VIEW just the old and misterious problem. Now the question: where can I find a solution? Joomla? Seblod? Any clues will be very welcome! Thanks!
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....
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.
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.
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.):
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.
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
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
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.
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,
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.
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,
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.
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,
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.
#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..