UPDATED: wpDataTables Master-Detail Plugin in X

[philcoggins]

Dear " X’ers"

I’m using wpDataTables and its Master-Detail Add-on to include tables in pages constructed using Pro. An option of the Master-Detail setup is to open the “details” page (from a table entry) in a separate page (or post, either one works) – which involves setting up a template page to accept the relevant values. The template page (and it is just a regular kind of page) takes entries in the form %example%

Here’s an example from WpDatatables site to illustrate.

All of this works fine for me on a regular page or post built and edited directly in Wordpress but not in a page/post edited in Pro – the entries are just treated as regular text.

BTW, WpBakery Page Builder interprets the fields properly too.

How do I get X pages to interpret these fields correctly?

Thanks in advance!

UPDATED: The entries I am interested are interpreted properly if they are within a “Classic Text” element (but not a new text, raw content, classic raw content , or new content area element).

I would still welcome input for a more elegant solution or understanding. For example, it would be nice if this worked with the headline element – it doesn’t so far.

[rad]

Hi Phil,

Thanks for reaching out.

Your only option is classic elements and or using shortcode format ([name] template instead of %name%).

The reason for that is, v2 elements are complex elements that its data is saved somewhere to prevent bloated content. And those data are called upon element renders. But classic element are simple, its data is equivalent to shortcode attributes and content. Example, this is the generated content from the builder

This is text element

[cs_element_text _id="4" ]

and this is the classic text element

[cs_text id="sample-text" class="cs-ta-center the-text" style="margin:0px;"]%name%[/cs_text]

Thanks!

[philcoggins]

Thanks for reply @rad

At least I know I’m not missing something simple, and I can confirm that the classic elements (beyond the classic text element for example) seem to offer me enough flexibility for the moment.

The [name] format alternative does not appear to work – I checked that and several other variations.

I will reach out to the wpDataTables team and see if they have any alternative suggestions.

Cheers
Phil

[friech]

Yes, let us know how it goes,

Cheers!

[philcoggins]

Hi Themco Team

Further to this issue with wpDataTables Master-Details Add-on. I reached out to their support and this is what they had to say:

"The Add-on is using WordPress’ hook the_content for filtering the content, where our placeholders are being replaced. If the theme has its own logic for generating content, or if it’s overriding the hook with some of its own hooks, then you could ask them if there’s a hook in the theme which can be used for filtering the content.

If there is, you can forward them and that builder to us, so we can test it, and maybe add it in Master-Detail."

Hopefully this information is helpful and there is something I can pass along to wpDataTables to resolve this issue. This particular plugin is a very powerful data manipulation and presentation tool, and highly regarded, so I think it would be worth the effort.

Best Regards,

Phil

[rad]

Hi Phil,

Yes, that’s the problem. The plugin only looks for the_content, the builder doesn’t override the hooks or else the classic text element with %name% will not work either. As I mentioned above, v2 data and content are saved somewhere else and only called upon render. The data are saved in _cornerstone_data post meta, unfortunately there is no available hook in the theme and builder that they can use as of this moment. What I can recommend is still using classic text element, or convert %name% format [name], I mean the plugin should convert it, adding [name] right away isn’t going to work.

Thanks!

[philcoggins]

Hi @rad

I will pass your comment back to the wpDataTables developer and see what they can do but I think this isolated issue speaks to a wider (growing?) concern I have with X.

The most recent editions of the various builders do offer an incredible amount of functionality and flexibility but if that comes at the cost of compromised functionality in some other user critical cases then that is a problem.

In my current case, the V1 element is actually “superior” to the V2 by virtue of being more data (content) agnostic. Tools to enhance look and feel are great but ultimately a website is about the data it presents, and increasingly, that data is both sourced and presented from dynamic data sources that parse and present the specific requested output as the page is being built. Is X becoming a well laid out walled garden where other code and functionality may struggle to execute?

Cheers
Phil

[christian]

Hey Phil,

To your question:

@philcoggins

Is X becoming a well laid out walled garden where other code and functionality may struggle to execute?

No. It’s just that the 3rd party plugin you used only supports wp_content. If your plugin can use shortcodes, you can display it in Cornerstone.

Thanks.

[philcoggins]

…but that’s exactly my point. A regular Wordpress page or post does not enforce that distinction – X does!

[rad]

Hi Phil,

Indeed, and it’s X’s standard versus 3rd party standard. If a plugin wishes to integrated to another system, then it must follow the standard of the system it wishes to integrate to. And this time, it’s X system.

It’s not about Wordpress’s distinction, because there is none. Wordpress doesn’t require any plugin to use %name% format type of shortcode, nor {name}, nor |name|. It is the plugin that do that, Wordpress only provide the standard shortcode format which is [name] https://codex.wordpress.org/Shortcode_API

Because there is no distinction, any theme or plugin could create their own standard. Our builder standard is to save robust data to post_meta instead of post_content, while the 3rd party plugin chooses to create its own standard for shortcode formatting which is %name%.

Again, our builder doesn’t block the_content hooks, the data is just saved somewhere that 3rd party plugin can’t find. The the_content is very important, it’s where the content is rendered and processed, without it, even our builder will not work so there is no point blocking it

In conclusion, the fix for all these issues is integration similar to other robust plugins and themes. Compatibilities aren’t automatic just because it’s made for Wordpress especially there are multiple local standards in play.

Thanks!