1509 posts
  • Has referred 1+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Made it to the Authors' Hall of Fame
+2 more
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
  • Has been part of the Envato Community for over 5 years
  • Has referred 50+ members
  • Has sold $1,000+ on Envato Market
  • Sells items exclusively on Envato Market
+1 more
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.

501 posts
  • Has referred 1000+ members
  • Has sold $250,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+8 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.

498 posts
  • Has referred 10+ members
  • Has sold $40,000+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Sells items exclusively on Envato Market
+2 more
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
  • Has been part of the Envato Community for over 5 years
  • Has referred 50+ members
  • Has sold $1,000+ on Envato Market
  • Sells items exclusively on Envato Market
+1 more
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.

55 posts
  • Has been part of the Envato Community for over 6 years
  • Has collected 100+ items on Envato Market
  • Has sold $1+ on Envato Market
  • Sells items exclusively on Envato Market
+1 more
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] .....
501 posts
  • Has referred 1000+ members
  • Has sold $250,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+8 more
pixelentity says

So, you basically want to do what I just said?
or not.
158 posts
  • Has been part of the Envato Community for over 5 years
  • Has referred 50+ members
  • Has sold $1,000+ on Envato Market
  • Sells items exclusively on Envato Market
+1 more
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.

501 posts
  • Has referred 1000+ members
  • Has sold $250,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+8 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.
55 posts
  • Has been part of the Envato Community for over 6 years
  • Has collected 100+ items on Envato Market
  • Has sold $1+ on Envato Market
  • Sells items exclusively on Envato Market
+1 more
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 ?

Helpful Information

  • Please read our community guidelines. Self promotion and discussion of piracy is not allowed.
  • Open a support ticket if you would like specific help with your account, deposits or purchases.
  • Item Support by authors is optional and may vary. Please see the Support tab on each item page.

Most of all, enjoy your time here. Thank you for being a valued Envato community member.

Post Reply

Format your entry with some basic HTML. Read the Full Details, or here is a refresher:

<strong></strong> to make things bold
<em></em> to emphasize
<ul><li> or <ol><li> to make lists
<h3> or <h4> to make headings
<pre></pre> for code blocks
<code></code> for a few words of code
<a></a> for links
<img> to paste in an image (it'll need to be hosted somewhere else though)
<blockquote></blockquote> to quote somebody

:grin: :shocked: :cry: Complete List of Smiley Codes

by
by
by
by
by
by