Tell us what you are trying to do? I will admit I haven't worked on my website in years, and it appears that a list of select options is no longer populating. It worked very well for a long time, though I'm not sure when it broke. The parameters I'm using are:
[cred_field field='_wpcf_belongs_meeting-places_id' value='' order='title' ordering='desc' required='true' select_text='(Select a meeting place)' validate_text='You must select a meeting place' class='form-control' output='bootstrap']
And it generates this:
<select id="cred_form_174576_1-select-1-1616871543" preset_value="" urlparam="" make_readonly="" max_width="" max_height="" class="form-control wpt-form-select form-select select" output="bootstrap" select_text="(Select a meeting place)" data-orderby="title" data-order="desc" data-author="" data-wpt-validate="{"required":{"args":{"1":true},"message":"You must select a meeting place"}}" data-wpt-field-title="meeting-places Parent" data-parsley-required="true" data-parsley-required-message="You must select a meeting place" data-wpt-type="select" name="_wpcf_belongs_meeting-places_id"><option value="" class="wpt-form-option form-option option" data-wpt-type="option" data-wpt-id="cred_form_174576_1_cred_form_174576_1-select-1-1616871543" data-wpt-name="_wpcf_belongs_meeting-places_id" selected="selected">(Select a meeting place)</option> </select>
I've confirmed that a different page is loading the meeting places, so the data exists. I haven't changed anything. How do I fix this menu?
Is there any documentation that you are following?
Old documentation, I haven't worked on this since 2017.
Is there a similar example that we can see?
No
What is the link to your site?
hidden link (though the form requires authentication)
Since posting this I've discovered more issues. All of my archive pages are not customized, like Toolset is no longer controlling them. For example, hidden link is just looping through all Members. On the Toolset Dashboard I still see the Members Archive in the list, and when I click on the link it takes me to the same custom Archives page. The first bit of HTML in the Loop Editor box is <h1>Members</h1> but the Archive page does not display a title like this. It's like it's ignoring it. I'm seeing the same thing with other Archive pages.
In addition, Toolset Maps isn't generating the map. It's drawing the box and displays "Loading the map showing the meeting place..." but then doesn't progress from there.
<div id="map-loading">Loading the map showing the meeting place...</div></div><div style="display:none" class="wpv-addon-maps-marker js-wpv-addon-maps-marker js-wpv-addon-maps-marker-meeting-marker js-wpv-addon-maps-markerfor-plan-map" data-marker="meeting-marker" data-markertitle="CO: Johnson Village, Gunsmoke Truck Stop" data-markerfor="plan-map" data-markerlat="38.8115428" data-markerlon="-106.1067971" data-markericon="" data-markericonhover="" data-streetview="no">12916 US-24, Buena Vista, CO 81211, USA</div>
The only issues I'm seeing are with Toolset pages, and I'll admit I haven't looked at them in a while. I've disabled a few plugins to try to see if there is a conflict, but nothing has been successful. Thanks!
it appears that a list of select options is no longer populating.
...Since posting this I've discovered more issues. All of my archive pages are not customized, like Toolset is no longer controlling them.
...In addition, Toolset Maps isn't generating the map. It's drawing the box and displays "Loading the map showing the meeting place..." but then doesn't progress from there.
Okay let's focus on the Forms post relationship field issue in this ticket. I have split off separate tickets for your other concerns, and a supporter will pick up those tickets in turn.
_wpcf_belongs_ No Longer Working
Before Types 3.0, post relationships were defined in the child post using a postmeta key in the format _wpcf_belongs_{parent-post-type-slug}_id, where the value was the parent post ID. As of Types 3.0, new and migrated post relationships no longer rely on the old _wpcf_belongs_{parent-post-type-slug}_id postmeta key to define post relationships. Those associations are now stored in custom database tables without any postmeta values involved. To find out if your site is using the new relationships system, you can go to Toolset > Relationships. If you see messages prompting you to migrate to the new relationships system, your site is still using the old relationships system and has not yet migrated.
If you see a dashboard-style list of all the post relationships involved on your site, your site is using the new relationships system and it is best to update your Forms to use the appropriate shortcode syntax. I would delete the post relationship field from the Form builder and add it back using the Form builder controls instead of trying to type the shortcode out manually.
Any shortcodes that use the old _wpcf_belongs_{parent-post-type-slug}_id syntax should be updated for full compatibility. Use the item attribute in any Types or Views shortcode to access information about the parent post. The updated syntax for accessing information in a parent post from the context of a child post:
item="@relationship-slug.parent"
You would replace relationship-slug with the slug of this post relationship. You can find the relationship slug in Toolset > Relationships when you edit the post relationship. For example, let's say I have a one-to-many (O2M) post relationship between Books (one) and Chapters (many) with the slug "book-chapter". To get the ID of the parent Book and display it in the child Chapter template, I would use the wpv-post-id shortcode with the item attribute like so:
[wpv-post-id item="@book-chapter.parent"]
Reference:
https://toolset.com/documentation/programmer-reference/views/views-shortcodes/#wpv-post-id
https://toolset.com/documentation/programmer-reference/views/views-shortcodes/item-attribute/
Let me know if you have questions about
I see that I haven't migrated my site yet. It looks like I wouldn't have to, and my site would continue to function as it has before, correct? Or did that use of the legacy code not work in my case?
Can I not do the migration and still use the new shortcodes? Or does that only come with the new relationships?
I'll read about the migration and get that figured out. Unfortunately, I haven't looked at Toolset in years so I only know how it used to work in 2018 or so. I think I have some catching up to do.
I see that I haven't migrated my site yet. It looks like I wouldn't have to, and my site would continue to function as it has before, correct? Or did that use of the legacy code not work in my case?
Right, if you have not migrated to the new relationships system, the old Forms shortcode should continue to work as expected. However, if you've updated to the latest versions of Toolset plugins it could be the case that there is a bug where the newer version is struggling with legacy relationships...I haven't worked on a site recently that is still using the legacy relationships system, but that's a possibility. I would need to create a clone of your site to investigate further.
Can I not do the migration and still use the new shortcodes? Or does that only come with the new relationships?
No, I think the new item="@relationship-slug.role" syntax is specifically for the new relationships system. Forms also has a new syntax for relationship fields now, so the old relationship field shortcode you have should be updated during the migration to the new system.
To be clear, if you plan to update the site to use new features like the block editor and many-to-many relationships, it's best to run the migration process. The Block Editor's post relationships features are based on the new relationships system, and many-to-many relationships are not supported in the legacy relationships system.
Is there information somewhere about what happens if I migrate my site? I've realized the date picker on the same page is also not working. I created a shortcode to pull the options out of the database in JSON to use in a cred_generic_field and that is also not working (the JSON looks good but cred_generic_field doesn't generate anything). I don't plan on doing any new work on the site, but I do need this page to work.
Would migrating the site to the new relationships allow me to fix this page without having to do additional work to other pages? The site is pretty heavily customized. How easy is it to roll back if the migration doesn't work? Thanks!
Here's a blog post from the release:
https://toolset.com/2018/05/toolset-post-relationships-release/
You can try migrating your site to a staging environment, then running the update there first. The system will generate a list of possible conflicts with any custom code during the migration process, and after making the required changes you'll be able to verify things are working as expected. But I suspect the datepicker and generic field issues are unrelated, unless you've integrated those with related posts somehow.
I can take a quick look if you provide a login and the URL where I can see the Form.
Okay I don't see anything obviously wrong on the Form itself, but I do see quite a few JavaScript errors on the front-end page with the Form. That explains a bit, since the datepicker and post relationship fields are heavily reliant on JavaScript. The next few troubleshooting steps should help determine if there is a conflict with another plugin, theme or custom code snippet.
- Temporarily activate a default theme like Twenty Twenty
- Temporarily deactivate any custom code snippets in Toolset > Settings > Custom Code tab
- Temporarily deactivate all plugins except Types, Views and Forms. If you need to activate a Maintenance Mode plugin during testing that should be okay
- Temporarily comment out any custom JavaScript in the Form editor
- Refresh the page with the Form and test the two fields that were having problems.
- If the problem is resolved, there is a conflict somewhere with one of the other components. Reactivate your theme, custom code snippets, Form scripts, and other plugins, one by one, testing each time until the problem returns. See if you can isolate one component responsible for breaking the Form.
- If the problem is not resolved by deactivating all other components, I'll need to take a closer look.
Let me know what you find out and we can go from there. My suspicion is that the optimization settings in Autoptimize are a bit too aggressive for Forms, but I'll be interested to know what you find out.
You're so intuitive! I disabled Autoptimize and Async Javascript and the form is back to normal. I'll mess with those plugins -- they have given me issues before, years ago, but they do make a difference in load times. Thank you!!!
