1400 posts
  • Has been a member for 2-3 years
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 10 and 49 items
  • Referred between 1 and 9 users
  • Croatia
OriginalEXE says

Couldn’t you just dump meta value to post content on theme deactivation?

Besides, layouts are often in JSON or similar format that does not make much sense on the frontend if not parsed.

158 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Referred between 50 and 99 users
  • Sold between 1 000 and 5 000 dollars
  • United States
greenshady says

Couldn’t you just dump meta value to post content on theme deactivation? Besides, layouts are often in JSON or similar format that does not make much sense on the frontend if not parsed.

I’m sure there are several different methods you could utilize. I was just kind of throwing some rough ideas out there. The big thing is to make sure that the actual content (words, images, media, etc.) are still there when the user switches to another theme. If you can manage that, use whatever method you want.

488 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Won a Competition
  • Referred between 1000 and 1999 users
  • Author had a Free File of the Month
  • Author had a File in an Envato Bundle
  • Bought between 10 and 49 items
+3 more
pixelentity says

Sure. Essentially, the idea is to tie all the data back into $post->post_content without resorting to shortcodes.
I don’t see post content as viable solution to store page builder structure, to me it has too many drawbacks. For instance, you would need to parse the markup and rebuild the builder layout each time the page is edited.

Consider a block which pulls data from other posts, you would store the generated markup at the time the page is saved but changes made to those posts afterwards would be ignored unless the parsing/markup translation is done again each time the page is rendered.

Using a single meta to store the builder layout as a serialized object is simpler and requires no parsing (unlike markup/shortcode case).

Markup can be rendered into post_content as well when saving the builder layout, this way user switching theme won’t lose any content.

490 posts
  • Sold between 10 000 and 50 000 dollars
  • Referred between 10 and 49 users
  • Bought between 50 and 99 items
  • Exclusive Author
  • Has been a member for 3-4 years
wopethemes says


Sure. Essentially, the idea is to tie all the data back into $post->post_content without resorting to shortcodes.
I don’t see post content as viable solution to store page builder structure, to me it has too many drawbacks. For instance, you would need to parse the markup and rebuild the builder layout each time the page is edited.

Consider a block which pulls data from other posts, you would store the generated markup at the time the page is saved but changes made to those posts afterwards would be ignored unless the parsing/markup translation is done again each time the page is rendered.

Using a single meta to store the builder layout as a serialized object is simpler and requires no parsing (unlike markup/shortcode case).

Markup can be rendered into post_content as well when saving the builder layout, this way user switching theme won’t lose any content.
Total agree. Include all things to post content will make a mess. Let leave post content the natural beauty as it was.
158 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Referred between 50 and 99 users
  • Sold between 1 000 and 5 000 dollars
  • United States
greenshady says


Sure. Essentially, the idea is to tie all the data back into $post->post_content without resorting to shortcodes.
I don’t see post content as viable solution to store page builder structure, to me it has too many drawbacks. For instance, you would need to parse the markup and rebuild the builder layout each time the page is edited.

Consider a block which pulls data from other posts, you would store the generated markup at the time the page is saved but changes made to those posts afterwards would be ignored unless the parsing/markup translation is done again each time the page is rendered.

Using a single meta to store the builder layout as a serialized object is simpler and requires no parsing (unlike markup/shortcode case).

Markup can be rendered into post_content as well when saving the builder layout, this way user switching theme won’t lose any content.

So, you basically want to do what I just said? Sounds like a good idea.

50 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Bought between 100 and 499 items
  • Referred between 1 and 9 users
  • Sold between 1 and 100 dollars
Svipic says

Guys, As i see many of you bring couple ways of solutions. But i really want to know if everybody or at least most of you agree that Shortcodes for building layouts of a page in Themes is not a best for end user?

Like it will be a way better if this layouts could be in Page Templates and not shortcodes and as long as developer want to provide some extra functions, it can be done by widgets or maybe by page builders but definintly not by shortcode writing in to the editor.

I really don’t see how End user (lets say some kind of Fisherman) can handle writing and understanding shortcodes like that in content.

[one_half] .... [/ one_half] [two_half] ... [/two_half] .....
488 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Won a Competition
  • Referred between 1000 and 1999 users
  • Author had a Free File of the Month
  • Author had a File in an Envato Bundle
  • Bought between 10 and 49 items
+3 more
pixelentity says

So, you basically want to do what I just said?
or not.
158 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Referred between 50 and 99 users
  • Sold between 1 000 and 5 000 dollars
  • United States
greenshady says


So, you basically want to do what I just said?
or not.

I’m pretty sure people simply don’t read the words that I write sometimes. Either that or they want to disagree for the sake of disagreeing, even when they agree with me.

488 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Won a Competition
  • Referred between 1000 and 1999 users
  • Author had a Free File of the Month
  • Author had a File in an Envato Bundle
  • Bought between 10 and 49 items
+3 more
pixelentity says

I’m pretty sure people simply don’t read the words that I write sometimes.
I thought the same since, in my post, i explained why i don’t think to store builder layout data into post_content is a viable solution and you’d still rely on meta for that.

To use post_content as builder storage and saving rendered markup into it as fallback for customers switching theme are not the same thing in my book: builder itself won’t need/use post_content to edit/render page content.
50 posts
  • Exclusive Author
  • Has been a member for 5-6 years
  • Bought between 100 and 499 items
  • Referred between 1 and 9 users
  • Sold between 1 and 100 dollars
Svipic says


I’m pretty sure people simply don’t read the words that I write sometimes.
I thought the same since, in my post, i explained why i don’t think to store builder layout data into post_content is a viable solution and you’d still rely on meta for that.

To use post_content as builder storage and saving rendered markup into it as fallback for customers switching theme are not the same thing in my book: builder itself won’t need/use post_content to edit/render page content.

Is there a way to create Page Template file on the fly from wordpress admin with page buider?

Like if user creates some layout with page builder, is there a way creating php file of page template instead of saving markup in the DB ?

by
by
by
by
by
by