This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Thank you very much, Christian!
Hi Christian. Just fyi in case it would be useful: I discovered that everything works fine with a view as options in the post creation form if not expert editor is used. But when I try to use not expert mode for the user form it doesn't work.
Okay that's interesting, it could point to the problem being related to some a conflict with other Form contents. I'm continuing my investigation and will update you as soon as possible.
I think at this point I need to loop in my 2nd tier support team, because everything seems to be configured correctly and nothing I do is fixing the problem. If it's okay with you, I'd like to share a copy of your site. I can install the Duplicator plugin or the All-in-One WP Migration plugin to make the clone and share with the team. Let me know if you approve and I'll go ahead and get started.
Hi Christian. Yes, please go ahead with a clone site
Okay after a few more hours debugging this, I have some updates for you. I see PHP warnings in my local logs related to the custom child theme's e, you might want to check these
---> PHP 6. filemtime() /path/to/site/wp-content/themes/astra-child/functions.php:20 ---> PHP Warning: filemtime(): stat failed for <em><u>hidden link</u></em> in /path/to/site/wp-content/themes/astra-child/functions.php on line 21
Here is the code that produces the PHP warnings:
$my_typgraphy_css_ver = date("ymd-Gis", filemtime( get_stylesheet_directory_uri() . 'https://cdn.toolset.com/typography.css' )); $my_custom_child_css_ver = date("ymd-Gis", filemtime( get_stylesheet_directory_uri() . 'https://cdn.toolset.com/style.css' ));
The problem there is filemtime expects a server path to the file, not a complete URL. The best solution is to drop _uri() when passing the path to filemtime:
$my_typgraphy_css_ver = date("ymd-Gis", filemtime( get_stylesheet_directory() . 'https://cdn.toolset.com/typography.css' )); $my_custom_child_css_ver = date("ymd-Gis", filemtime( get_stylesheet_directory() . 'https://cdn.toolset.com/style.css' ));
But that does not solve the problem with generic select field options, unfortunately. The same problem happens with Twenty Twenty One active, so it's not related to the theme as far as I go. So I am still investigating, but I believe I have found part of the problem and a potential workaround. In the expert mode builder, it seems that a space before and after the View shortcode in the generic field options is required. So the options line should look like this, wth spaces before and after the View so:
"options":[ [wpv-view name='institutions-as-options-for-other-views'] ]
But...the first time this View is placed in the options of a generic select field, it doesn't work. If you place the same View in another select field's options, it works! So the first implementation seems broken. For now, I have left the same View in all 3 generic select fields with dynamic options so you can see it working.
That leads me to suggest a workaround while my 2nd tier team continues to investigate. You can duplicate each generic select field, and give them different slugs. Place the same View of options in both generic fields, and hide the first field so only the duplicate is visible.
This was a tricky one, so it took longer than usual to diagnose. Hopefully my 2nd tier team can find out why this is necessary, and how it can be fixed. I've reported the issue and will keep you updated here as I receive more information.
Thank you, Christian!
I edited functions.php of the child theme and I also tried your approach with duplicates of generic fields with views.
Unfortunately, it didn't work for me. I tried to to hide generic fields in two ways: through HTML comment and through CSS display:none. Both options didn't work. The select fields with a view as an option just don't show up.
I am not sure what am I doing wrong...
As Christian is currently on Vacation at the moment I will be doing the follow up on this ticket from our 2nd tier supporters.
Our 2nd tier supporters are reporting that the problem occurs when the form is added on a page that is being edited with the Block editor and there are other Toolset blocks on the same page.
Essentially the output of the form gets broken in the process.
Our Team did provide a solution by just having that form only on the page with no other block elements.
Another workaround is to add your JSON view to the page using the view's shortcode. However if you are using 3 fields with the JSON output from our views, then you will need to add the view's shortcode 3 times to the page and then use CSS to hide these views on the page.
Please let me know if these solutions work for you as our team has reported the issue to the development team however this may take some time to get resolved.
Hi, Shane. Many thanks to Christian, you, and your 2nd tier support team.
I will check your solutions and I will let you know how it works.
Great, once you can confirm that the workaround works then you can go ahead and mark this ticket as resolved.
This issue should now be resolved in the latest version of our Toolset plugins.
You can download the latest updates from the link below.
Hi Shane, thank you for the update.
I checked and if I add any toolset block on the page with a user form, the issue remains the same. As soon as I added the Header block, for example, the generic field with options generated by view is not showing up.
Confirming here that as long as the page has no other block elements then it will work fine correct?
Perhaps what you can try doing is to create a content template and add the form to that content template only, then add this content template that has the form to the page that you want the form to be added on.
I've relayed the information about this still not working to our 2nd tier team so i'm currently waiting on an update.
"Confirming here that as long as the page has no other block elements then it will work fine correct?" - yes correct.
I removed all Toolset blocks from the page. I just use Gutenberg blocks + Toolset Form block. In this case, everything works fine.
I checked on your site and it would appear that you're not running the latest version of the plugins. Please check the link below and perform the updates and check again to see if the issue still remains.