peter8nss
Forum Replies Created
-
Sorry for not gettting back to you sooner but I wanted to test it on a different site to rule out any issues relating to the theme. I have repeated the test on another site using a form containing only the consent field and got the same result (although without the hidden error in this case as the consent is always visible).
I’ve uploaded the form export to Google Drive but it is trivial to recreate it from scratch. I’ve also uploaded a screenshot of the validator error.
Look at page https://8nss.org.uk/introduction/ and in particular the button with id “cboxPrevious”. On that page the button will never become active – so it doesn’t matter it doesn’t have any content. [It is there as a placeholder for pages where it is needed.]
I’ve done some further testing. What gets stored for the submission depends on the setting of “Default Stored Value”. If you have “Option values” selected, you get “custom_option” stored when an “other” value is entered. If you have “Option labels” selected, you do get the text entered for the other value stored for the submission. So the problem is limited to the fact that the entered value is not included in the field_data_array passed to the filters. [The original issue raised]
A (temporary) workaround for someone using forminator_custom_form_submit_before_set_fields is to access static Forminator_CForm_Front_Action::$prepared_data which does have the value for select-n available as custom-select-n.
I’m sorry about the duplicate post. However, I think it is important to note that I have now determined that the problem is wider than first identified and is not just confined to those writing code using apply_filters. Specifically, if you have select field with the “Other option” enabled, the text entered by a user for that other value is NOT stored in the submission at all.
I am an experienced developer.
When you have “other option” enabled for a select field you are right the field_data_array returns “custom_value” to tell you that the “Other” option has been selected. What it does not do is tell you what the value typed for that field was. Nor is that information included anywhere else in the field_data_array – which is surely an ommission. As result that information is unavailable in a number of crucial filters (e.g. forminator_custom_form_submit_before_set_fields) I wish to use to customize the form behaviour.
If I modify Forminator_CForm_Front_Action::maybe_handle_custom_option to remove the outer “if ( self::$is_draft ) {” it works as I would expect, including an additional entry in the field_data_array.
{
"name": "custom-select-1",
"value": "The text I entered for the other option"
}Can that change please be incorporated in the code base or how else am I supposed to get the “other” value that was entered when processing the data in filter forminator_custom_form_submit_before_set_fields.
Should Forminator_CForm_Front_Action::maybe_handle_custom_option be adding an entry for “custom-select-1” to field_data_array which could then be read to get the actual value?
To be sure we are on the same page, in the second case, the form doesn’t highlight which field has the issue when compared to the 1st case, where the field will get highlighted with a message like “This field is required. Please enter a number.” Correct?
Yes
The problem is linked to how the id field is set for repeating group subsequent items. Whereas the field name in the field data array is, say, “number-1-2” (and that is what the plugin uses when generating a server side error messages) the id in the form is actually something like “number-1-1j38bpfj604e940035982a1” where “1j38…” equates to the “original_id” stored in the fields “field_array”.
Forum: Plugins
In reply to: [WP Mobile Menu - The Mobile-Friendly Responsive Menu] PHP deprecated errorI’m haven’t seen it for a while and am having trouble replicating it. However, I can see the code that would cause this in function mobmenuscssc::reduce. Specifically:
$fn = "op_${opName}_${ltype}_${rtype}";
if (is_callable(array($this, $fn)) ||
(($fn = "op_${ltype}_${rtype}") &&
is_callable(array($this, $fn)) &&
$passOp = true) ||
(($fn = "op_${opName}") &&
is_callable(array($this, $fn)) &&
$genOp = true))All three seem to be deprecated in PHP8.2, e.g. “….${xxx}…” should be “…{$xxx}…”.
Forum: Plugins
In reply to: [The Events Calendar] PHP dreprecated error in 6.13.2Seems to be fixed by 6.14.1
In fact, I’m not sure the dynamic-menu option is needed at all. It only seems to be used to hold the CSS if the write fails in generateSaveCSS. And is only read in printCSS (if setting css==’generate’). But if that is the case, enqueueCSS will already have the CSS needed.
Its odd. I only see it when I’m logged in as administrator and I’m searching the event log for a particular word.
ps: on my debug test site I connect to the deprecated_function_run hook and write to my Simple History log with traceback. Hence, pick up the occasional oddity like this.
Forum: Plugins
In reply to: [The Events Calendar] ORM order_by affects resultsIf I look at the query_vars at pre_get_posts stage, I can see that the only difference is the addition of “orderby” set to “start_date”.
If I use “event_date” rather than “start_date” it seems to work better. This is probably linked to https://ww.wp.xz.cn/support/topic/orm-order-by-start_date-not-working/. Once again I’ve wasted a lot of time becuase the examples in the online documentation are (still) incorrect.
Forum: Plugins
In reply to: [The Events Calendar] ORM order_by affects results- PHP: 8.3.16
- WordPress: 6.7.2
- The Events Calendar: 6.11.2
- Events Calendar Pro: 7.4.5
- Theme and Version: Bespoke
Fixed in Pro 7.4.5. Thanks.