Posts by greenshady

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


I never said you should store builder layout data into post_content. I said you need to tie everything back into post_content. I never went as far as explaining any method you’d take to get there. Your post just took the idea I noted and expanded on it with more details of one method on how to accomplish that end goal.

If I understand you correctly, you want the content to be editable in the editor, even it you swich off the page builder, or change themes?

Page Builder by Site Origin does this, although it lacks some finesse in other areas. I also find it better to use native wp functionality like widgets instead of shortcodes. It is also much easier to understand for not so tech-savvy users.

Yes, you got it. The purpose is to make sure the content is portable.

I’m unfamiliar with that Page Builder script. I’ll have to check it out sometime.

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


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.

I never said you should store builder layout data into post_content. I said you need to tie everything back into post_content. I never went as far as explaining any method you’d take to get there. Your post just took the idea I noted and expanded on it with more details of one method on how to accomplish that end goal.

Why are we arguing? You’re explaining in more details how to do exactly the type of thing I was asked to elaborate on. We should be celebrating for helping out a fellow theme author.

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.

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.

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.

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


It is entirely possible to create a layout builder without shortcodes or metadata.
could you elaborate more ?

Sure. Essentially, the idea is to tie all the data back into $post->post_content without resorting to shortcodes. What you’d want to do is build out the meta boxes but save the data as post content so that the content itself is still available to the user after switching themes. What they’ll lose is the “design”. This is not exactly easily done (what layout editor is easy to code?), but it’s very possible. You might even consider working with $post->post_content_filtered.

I don’t think I’m allowed to link to other theme sites here, but you should check out The Theme Foundry’s latest theme. I’m not sure of the exact method they used, but I know they took a similar approach. The user’s content isn’t tied to theme metadata or shortcodes according to the devs on that project.

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

Seriously? Tell me more how the page builders are better than the shortcodes? Most of them create MUCH more mess especially in the database. Take one of the very best selling composer plugin, create a page using the builder and then see the meta data for that post.

I agree with you on the point that most page builders create much more of a mess. That’s just poor coding practice and lack of understanding how WordPress works. It is entirely possible to create a layout builder without shortcodes or metadata.

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

The best way to learn about theme development is to play around with other people’s code. Tutorials and books are great, but they don’t give you the practical experience you’ll need to make good themes.

As for best coding practices, I honestly haven’t seen that many themes on TF that follow them. That should be changing with the new theme submission requirements.

For just under the hood stuff, I recommend the WordPress theme repository. Over the past few years, it has had the most rigorous code review of any WordPress theme Web site. Occasionally, something slips through, but for the most part, the code quality is pretty good.

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

Here you go. I fixed a lot of the rest of your code for you too.

function my_shortcode( $attr ) {

    $attr = shortcode_atts(
        array(
            'type'  => 'fhpartners',
            'posts' => 5,
        ),
        $attr,
        'shortcode-name'
    );

    $part_img = get_post_meta( get_the_ID(), '_cmb_partner_image', true );
    $part_url = get_post_meta( get_the_ID(), '_cmb_parner_url',    true );

    $loop = new WP_Query(
        array(
            'post_type'      => $attr['type'],,
            'order'          => 'ASC',
            'orderby'        => 'menu_order',
            'posts_per_page' => $attr['posts'],
        )
    );

    $out = '';

    if ( $loop->have_posts() ) {

        $out .= '<div class="row-fluid ParnersList">';

        while ( $loop->have_posts() ) {

            $loop->the_post();

            /* This what you want. */
            $current_post_id = get_the_ID();

            $image = sprintf( '<img src="%s" alt="logo" />', esc_url( $part_img ) );

            if ( !empty( $part_url ) )
                $out .= sprintf( '<a href="%s" target="_blank">%s</a>', esc_url( $part_url ), $image );
            else
                $out .= $image;

        } // endwhile

        $out .= '</div>';

    } // endif

    wp_reset_postdata();

    return $out;
}
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

I’m thinking you’d need a pattern along these lines (completely untested):

#(http?://.+/.+)(\..+?)(.jpg|.png|.gif)$#i
by
by
by
by
by
by