ECI 2.9 – Shortcodes In Use
This new versions brings a couple of very handy features that will make life easier. The best feature added is ability to use WordPress Shortcodes in your WYSIWYG Designs. This is a feature that can appear to be simple, then you realise it is complicated but only if you have not watched or read the tutorials, which there are none of. So I ask that you bare with me and ask questions if there is anything your not sure about until I get those videos made. There is some information in the About boxes, please take some time to browse these as it will help. I’m going to go over the other changes and further down I’ll describe how to use shortcodes.
Changes
- A new Log page has been added. It opens the plugins log and displays the full list of entries on the page. This has obvious advantages especially during testing. I’m aware that there is no way to reset these files automatically so don’t worry. A version soon will automatically reset the file, by deleting it and re-creating it. That simple really with the only issue being the chance of doing this action just before you happen to need the logs entries. We’ll cross that bridge when it gets built but deletion is the fastest automated approach.
- Log page also holds its own options, so the Log File options have been removed from the Settings page.
- The function for adding Log entry now has a Priority attribute, will be used to highlight each level of priority for easier reading on the Log page.
- Custom Fields form once again shows your current saved settings.
- Fixed problem with trying to open designs and resulting errors.
- Project Configuration page no longer behaves as if there is a current project when it is set too “None Selected”, the default on installation and it was causes none critical interface errors.
- Post Type and Publisher ID on the Project Options panel now have defaults. Type is post and the admin default of 1 for the publisher.
About Shortcodes
Shortcodes are very different from tokens, so the first thing you need to decide is which to use and when or where. The future benifits of learning this and getting it right is worth taking the time to read on. Here are a few key points to know before I keep writing…
- Shortcodes always exist as shortcodes and opening posts in the dashboard will show the shortcodes within the editor, not the data they represent.
- The data for each shortcode you use must be in the posts Custom Fields for them to work properly.
- You must add the Custom Fields on the Project Configuration page for each Shortcode you plan to use in your design.
- The plugins post updated has 2 approachs, total post re-build or Custom Fields update only.
- A total post re-build will re-create posts based on the applied design and data available.
- A total post-rebuild will cause any manual changes made to be lost.
- Custom Fields updating only, will not cause manual changes to post content to be lost.
- Posts are updated when they are viewed in either the dashboard or by public visitor, not all at once.
The idea here is to allow you to manually edit posts in various ways, possibly with other plugins, without losing those changes. The shortcodes will always represent and display the latest data value available. Tokens do the same but they are overwritten by the actual value of data they represent, during the Post Creation process. You will not see tokens when opening a post in the dashboard and if you make changes to the content, you will lose those changes if you allow updating to be done. This did not used to be the case because Shortcodes did not exist in ECI 1, ECI 2 aims to be far more advanced.
To make this work, you must tell the plug-in to create custom fields for each shortcode you will use. The csv column name, shortcode and custom field should all share the same name with no variation at all. The function that processes each Shortcode and replaces it with data when a post is opened for viewing, requires a custom field with the exact same name as the value in the shortcode in order to work.