I’m trying to switch from the Custom Content Shortcode (CCS) plugin to Loops & Logic but am struggling to find a workable way of converting in-text CCS link shortcodes, such as:
[field title-link id=359]
[field title-link id=143 link_text=“some custom link wording”]
without having to go page by page through the whole site to find and replace them manually.
Does anyone have a solution by any chance?
many tanks
ps. don’t ask me why I created these shortcodes in the first place - it was a long time ago…!
You can create one or more templates returning the same result as the shortcodes and then do a search and replace in the db to change them one by one.
But changing from CSS to L&L offers many other chances to improve you site like css and script templates - so I always concider a rebuild to implement those features.
Thank you Ralph. Do you mean create a separate template for every page link? If so I don’t think this is feasible unfortunately as this site has 340+ pages and some links have custom link_text…
I don’t need to improve the site - it’s just that I have been advised that I should switch to L&L as CCS is no longer ‘in active development’. In an ideal world I would just carry on using CCS but I think there are vulnerabilities with this.
You can create one or more templates returning the same result as the shortcodes and then do a search and replace in the db to change them one by one.
This is what I’d suggest too if you don’t want to manually modify them, though I’d generally suggest not using shortcodes within your post content so widely (sounds like you’ve come to the same conclusion )
Worth mentioning if you didn’t already know that you can call saved templates with the [template name=my-template-slug] shortcode, and you can pass local variables to the shortcode like so: [template name=my-template-slug post_in="195" link_text="some custom link wording]
You’d create a template that looks something like this:
Which would loop through the post ID supplied in the shortcode with post_in and display a link that contains the link text if it exists and falls back to the page title. You may need to add a variable for the post type if ever you’re linking more than just pages. Hope this helps!
The nice thing about this approach is that if ever you need to extend the functionality of your page link shortcode or add a classname or make any other modifications, you can just modify the template.
That’s sounds just what I need, thank you so much Julia
So, if I’ve got this right, I would create just one template as you have described above.
Then, for example, where the old shortcode was: [field title-link id=143 link_text=“some custom link wording”] the new shortcode would be: [template name=my-template-slug post_in=143 link_text="some custom link wording"]
So I think that means I could do a search and replace of the database that would automatically correct ALL the shortcodes at once:
Find “[field title-link id=” and replace with “[template name=my-template-slug post_in=”
I haven’t done the database search and replace yet but the template works - I just had to add a missing slash in this bit: <If check="{Get local=link_text}"> to make it <If check="{Get local=link_text}" />
One thing though, when I add the template short code in a paragraph, the resulting element is surrounded by this: [twrap] [/twrap] Do you know what I can do to get rid of this? It doesn’t appear like this if I add the same shortcode in a Code element (ie without any surrounding html). FYI, I am using the Avada theme.
A quick search through our codebase and it looks like this is part of our recent updates to improve compatibility with Gutenberg:
Gutenberg applies content filters such as wptexturize and do_shortcode to the entire page after all blocks have been rendered, which can corrupt valid HTML and JSON. The dummy shortcode [twrap] prevents do_shortcode from processing its inner content. This workaround can be removed if/when Gutenberg provides an option for register_block_type() to opt-out of these content filters.
Sorry, I think the situation is this: This extra [twrap] stuff seems to appear when the shortcode appears inside an Avada Fusion Text Block but is OK if placed inside a Fusion Code Block element (even if html added).
Do you think your developers will be able to do anything to remove this dummy shortcode for non-Gutenberg users? Otherwise it’s not going to be usable.
We’re working on improving the Gutenberg workarounds and I see a lot of activity around those in the development branch that should make it into the next release. I expect we’ll get to a solution here.
That’s good to know, thanks Gabriel. Do you know if there is a date for the next release? I’m keen to switch from the Custom Content Shortcode plugin ASAP as I have been alerted to a vulnerability…
I don’t have a specific date for that, and even if I did we can’t guarantee that a fix for this specific issue would be included in the next release, it might be 2+ releases out. Historically we’ve done around 1 release per month but lately it’s been more like 1 per week so it hopefully won’t be too long.
)
