Dieser Thread wurde gelöst. Hier ist eine Beschreibung des Problems und der Lösung.
Problem:
The customer was upgrading their site running Toolset Version 2.3.5 to the latest version while also updating PHP to version 7.x. They needed guidance on the upgrade path and encountered issues displaying custom fields with legacy PHP code after the update. Despite the fields being visible in the Classic Editor, embedding Toolset shortcodes in the editor caused site crashes when running PHP 8.2.
Solution:
Solution:
1- Upgrade Path: It was recommended to deactivate and delete the old version of Toolset, update PHP to version 7.x, install the new Toolset version, and import custom fields if necessary. The customer's data was safely retained in the WordPress database throughout this process.
2- Custom Field Display:
To replicate the legacy PHP logic, it was advised to use Toolset Views with conditional shortcodes, such as:
[wpv-conditional if="( NOT(empty($(wpcf-trail-length))) )"] <h4>Your HTML here</h4> [types field="wpcf-trail-loc"][/types]<br /> [types field="wpcf-trail-land"][/types]<br /> [/wpv-conditional]
If continuing with PHP code, the prefix wpcf- remains unchanged. The get_post_meta() function should be used to retrieve custom fields:
$loc = get_post_meta($post_id, 'wpcf-trail-loc', true);
3- Compatibility Notes: The customer was advised to update the PHP retrieval methods to align with current standards and replace older code constructs. The errors reported were related to the use of the continue statement and outdated plugin code.
Relevant Documentation:
https://toolset.com/documentation/programmer-reference/views/views-shortcodes/
https://developer.wordpress.org/reference/functions/get_post_meta/
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.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| - | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | 9:00 – 12:00 | - |
| - | 13:00 – 18:00 | 13:00 – 18:00 | 13:00 – 18:00 | 13:00 – 18:00 | 13:00 – 18:00 | - |
Zeitzone des Unterstützers: America/Sao_Paulo (GMT-03:00)
Dieses Thema enthält 6 Antworten, hat 2 Stimmen.
Zuletzt aktualisiert von vor 7 Monaten, 3 Wochen.
Assistiert von: Mateus Getulio.
Thank you. That worked perfectly. However, my legacy PHP code to display the custom fields from Toolset does not. My site is 18 years old and I'm used to coding HTML and, when I need to, PHP and CSS. What I'd set up in functions.php was an IF statement that if the content was from a certain category, replace the usual display of date & author at the top of the post with destination information with links, creating a cross-referenced index.
It's worked great for years, you can see a front-end example here, above the social icons: versteckter Link
I think I started this before you had Views, so I did the logic in php. I'm not quite ready to move to Gutenberg yet, and have over 2,000 pages on the website. So I'm not ready for Blocks.
Should I go ahead and install Views and use shortcodes to display that output? In the back end of Toolset, it's giving me these warnings about archives but since I can't back up my staging site, I'm a little worried about what might happen when I click that Resolve button.
Thank you again for your assistance.
Here's what the fields (per the example above) I created with Tools long ago look like in the Classic Editor.
And here is the logic I use to display those fields in the front end in lieu of author / date on posts. I added this to functions.php for whatever theme I had in use at the time.
(Screenshot since it is PHP code)
If I can replicate using Views, great! But it isn't working on my staging site. I'm curious if you've renamed the wpcf- field prefix to something different in your current release and that's my problem. Do let me know. Thank you!
