webdevstudios / wds-simple-page-builder

Uses existing template parts in the currently-active theme to build a customized page with rearrangeable elements.

WDS Simple Page Builder

Uses existing template parts in the theme to dynamically build a custom page layout, per page. An options page allows you to define your template part directory (if you wanted to keep these template parts separate from other template parts) and the template part prefix you are using.

Questions? Check out the wiki!

Usage

To use this plugin, your theme template files must have the following do_action wherever you want the template parts to load:

<?php do_action( 'wds_page_builder_load_parts' ); ?>

This will take care of loading the correct template parts in the order you specified. You can also specify a specific saved layout by passing the layout name to the do_action as a second parameter, like this:

<?php do_action( 'wds_page_builder_load_parts', 'my-saved-layout' ); ?>

Note: With saved layouts, the name you pass to the do_action must match exactly the way it is saved on the options page. So, if your layout was instead named "my saved layout", you would need to pass it to the do_action with the spaces intact.

Page vs Global Parts vs Saved Layouts

The page builder will, by default, use the template parts that were set on the page when you set them on the Edit page screen. However, if no template parts were defined on the individual page, you can also set Global Template Parts that will load on all pages that don't have their own, individual template parts defined.

You can leave the Global setting to "- No Template Parts -" to not define any global template parts if individual page-specific template parts weren't set.

Saved layouts are used when there is no layout set for that page (or post) with Global layouts used as a generic fallback. You can set a saved layout to be the default layout for all posts of a type or you can call them specifically when you add the do_action to your theme template files.

Screenshots

Dynamically add template parts within the Edit Page screen and reorder those components.

The results are saved to post meta on the page and visible as soon as you save the page.

Options page

Changelog

1.6

• added new Page Builder "Areas" feature (documentation)
• CMB2 takes care of figuring out which version to run internally, so don't check CMB2_LOADED
• fixed a bug where saved layouts were getting deleted when the options were registered
• fixed an issue where a saved layout wouldn't display when layouts were displayed if registered layouts existed
• fixed an issue where the global layouts didn't display the templates dropdown if no global layout was saved
• added filters for template-specific fields, users can now use a filter of wds_page_builder_fields_{$part_slug} to allow fields to show when a user selects that template part (Issue #19)
• added template tags for getting part-specific data, wds_page_builder_get_this_part_data( $meta_key ) and wds_page_builder_get_part_data( $part_slug, $meta_key ) respectively. The former can be used in the part itself, the latter can be used anywhere within the site.

1.5

• fixed a bug that prevented options from being saved with an empty saved layout name (removed the name requirement) (issue)
• added a new page_builder_class function (issue | documentation)
• added a new function that will initialize page builder with a wrapping container around it (issue | documentation)
• added a new function to initialize the page builder options and set those initialized options as either hidden or visible but uneditable (issue | documentation)
• added the ability to register Page Builder as a theme feature (using add_theme_support( 'wds-simple-page-builder' )) and a helper function to initialize the Page Builder options (documentation)

1.4.2

• added saved_page_builder_layout_exists function

1.4.1

• fixed empty templates showing up after options save in Saved Layouts (fixes #5)

1.4

• added actions and filters for plugin developers to hook into. See Hooks documentation
• removed some unused functions
• deprecated wds_template_part_prefix and wds_template_parts_dir and replaced them with wds_page_builder_template_part_prefix and wds_page_builder_template_parts_dir, respectively
• added unregister_page_builder_layout to unregister a single registered layout (or all of them if 'all' is passed)

1.3

• added new template tags -- wds_page_builder_load_parts for loading an array of specific template parts and wds_page_builder_load_part for loading a single template part
• added new feature to programmatically register a new layout

1.2

• added saved layouts feature. Now you can save layouts and set those saved layouts as the defaults for post types. Or you can define a specific layout in the do_action, e.g. do_action( 'wds_page_builder_load_parts', 'my named layout' )
• added a check for the existence of a template part before loading it -- prevents accidental blowing up of the page if parts are changed and not found

1.1

• added post type support beyond just pages. Options page now allows you to check which post types you want to use the page builder on, and the page builder metabox will appear on the Add New/Edit page for those post types.

1.0.1

• switched to using get_queried_object instead of get_the_ID to get a post id when checking the existence of post meta for cases when a loop is not being used or the action is fired outside the loop.

wds-simple-page-builder's Issues

Allow code-configuration of per-cpt defaults

For devs to pre-define some defaults w/o having to setup in every site/db.

Can only display one (of the same) template parts per page

If you select the same template part for more than one area, only the first one loads.

More hooks for the new stuff

@bradp reminded me today that hooks are good because they don't break things if the function doesn't exist.

So add new action hooks for all the new functions that have been added.

wds_page_builder_get_part_data does not get meta values for areas

wds_page_builder_get_part_data() only looks in the meta key '_wds_builder_template' but when you add parts to areas, it puts that meta under a key with the area appended like '_wds_builder_footer_template'.

So, this does not return the proper meta data from fields within declared areas for the page builder, only within the main area.

Add support for container and class to wds_page_builder_areas

Since wds_page_builder_load_parts is deprecated, let's add support for changing the container type and wrapper class.

Parts not being loaded into layout

I've been trying to implement this plugin in one of my sites but im struggling a bit to get it working.

Im registering a layout like this:

register_page_builder_layout( 'events-layout', array(
     'part-events-calendar',
     'parts/events/part-events-loop'
), true );

And calling it from a page template like this:

{% do action('wds_page_builder_load_parts', 'events-layout') %}

Note this is twigs syntax for:

do_action( 'wds_page_builder_load_parts' , 'events-layout')

In the dashboard SPB seems to be aware of my registered layout:
https://www.dropbox.com/s/twtmw8icd5tmr3x/Screenshot%202015-07-24%2019.54.06.png?dl=0

But the parts names doesn't get loaded in those select inputs, nor do I see any option on my page related to this layout.

Am I missing something?

Color picker and radio (inline) losing values when changing template position

The 2 fields field types in question are the color picker and the radio (inline).

When changing the order of templates, the fields are not keeping their values.

(gif)

In wds_page_builder_get_this_part_data( $meta_key ) the get_part method returns an empty value

This is supposed to detect the part which we are using to get the data. However, it is returning an empty value and not getting set. I've fallen back to using wds_page_builder_get_part_data and passing in the part slug

Undefined index: template_group

Notice: Undefined index: template_group in /Applications/XAMPP/xamppfiles/htdocs/clp.dev/wp-content/plugins/wds-simple-page-builder/inc/template-tags.php on line 270

Still see this error message when I have not selected a part in an area yet and view the page.

Display 'Layout Name' as accordion heading title for Saved Layouts

If you have multiple Saved Layouts, and all their accordion items are expanded the screen gets long. However, if you collapse them all to try and simplify the ui, and visual clutter then all you see is: "Layout 1", "Layout 2", "Layout 3", etc. (see screenshot https://www.dropbox.com/s/oz64gxgjx078tph/Screenshot%202015-07-14%2011.14.08.png?dl=0)

Would be nice to use the designated Layout Name field to also update the title in the accordion so at least you know which layout is which when you collapse?

Global template parts are empty

Dropdown isn't displaying at all...maybe being removed with js?

Parts index not being set properly, causing meta values not being returned

https://github.com/WebDevStudios/WDS-Simple-Page-Builder/blob/develop/inc/template-tags.php#L518

The part index in here is always returning zero when we are trying to get values for fields in template parts. This is not getting iterated or set when looping through builder parts, so the proper meta values are not being returned.

add generic wrapper function for all the things - `wds_do_page_builder()`

this would be different than wds_page_builder_load_parts but could potentially use that function. usage would look something like this:

wds_do_page_builder( array(
     'section',        // wrapper type, e.g. <div>, <aside>, whatever
     'part-container', // wrapper class or classes
     'layout-name',    // optional, the layout to load or whatever the default is
) ); 

When registered areas have a symbol, those symbols appear in the dashboard

 When using a underscore, register_page_builder_area( 'after_content' );

The underscore appears in the dashboard: https://www.dropbox.com/s/qm35hf890m17826/Screenshot%202015-08-11%2010.45.46.png?dl=0

Maybe we could use something similar to register_nav_menu() or register_sidebar()

register_page_builder_area( array( 
    'hero'           => esc_html__( 'Hero Area', 'textdomain' ),
    'before_content' => esc_html__( 'Before Content', 'textdomain' ),
    'after_content'  => esc_html__( 'After Content', 'textdomain' ),
) );

Unable to display data from field type "file"

Using the field type "file" in a field array prevents any page builder parts from displaying on the front end.
Data for a meta box using this field type successfully saves, displays in the admin, but doesn't display on the front end and prevents all other page parts from displaying.

collapsing/expanding does not persist

Originally reported by @colorful-tones in #10

if you collapse some in order to try and simplify screen real-estate, but then update (click 'Save') an option you'll get them all expanded again 🐼

Allow parts to be used multiple times

This is key to making #19 invaluable. Allowing a the same template part to used multiple times, but w/ different configurations will allow things like custom loops for different categories, etc.

This broke in this commit: 401fcf8

Allow registering (repeatable group) fields to be loaded into or available to a template part

Example UI:

But below 'Content Package Tag' would be the template part dropdown selector.

The data could be made available to the template part via a template tag like get_page_builder_layout_field( 'package_tag' )

Interface wastes a lot of space

Im not sure this is related to this plugin directly or CMB2, either way I was wondering if this is something you would be welcoming a PR to improve things a little.

Attached bellow is a screenshot of how much space could be spared, probably making the interface just a bit more intuitive in the process.

Child theme loads parts from parent and child

Currently child theme only loads parts from the child theme. Should array_merge that list with parts from the parent, too, but will need to tread carefully.

First reported in #16

Filing this as an enhancement because the current functionality works as expected (child loads parts from the child), but it could be made better if there were parts in the parent that we also wanted to use.

Check to see if a part/template has been loaded

We should add in some utility functions that will return a boolean if part/template has been loaded.

Something like?

function has_part( $part_name )

Do not conditionally load init.php based on CMB2_LOADED.

By wrapping in the CMB2_LOADED check you are short-circuiting CMB2's system for ensuring the newest version is loaded. https://github.com/WebDevStudios/WDS-Simple-Page-Builder/blob/master/wds-simple-page-builder.php#L36-L38
the check is not needed and will provide a bad precedent for other devs who use this lib as an example to follow.

Add ability to limit parts to only be used in a certain area

This came up on our call this morning. We thought it would be valuable to only allow a builder part to be used within a certain area. Some parts may not make sense in another area or could break another area unless front-end devs put in a lot of extra work to ensure design compatibility. It would be best to not give an option to place parts in areas if we know they will break the area or should not go in that area for whatever reason.

One option I have for declaring this, is to require a file header for builder template parts like how WordPress themes require them for page templates. You can use the following function to easily parse this: https://developer.wordpress.org/reference/functions/get_file_data/

In there you could declare a builder area which that part can only work for. This may also be a better way to display the names of template parts rather than the current method of taking the file name. It would allow better descriptions that don't fit in the few words you probably want to use for a file name.

Performance Issues on Load

Just wanted to bring up an issue I have been experiencing with PB. So considering the usage I am going to be more general here and have a BC task with details. Suffice to say that you can PM for further details.

So the basic issue is the more complex a page with parts the more performance degradation experienced both on load times, but also equally so when saving.

Let's give this some more TLC and get PB performing better on load.

Saved Layouts - Blank templates added on save

Save revisions of settings

@blobaugh Suggested the idea of saving revisions of PB settings and layouts so if something gets messed up, the user (or the developer/admin/whatever) can roll back to the last good settings

Load template parts from inside a plugin

It would be cool if a plugin could add template parts to the list of template parts PB uses, so all functionality could be contained inside the plugin. Ultimately, this would prevent parts of the page from being broken if there was a badly written template part that was dependant upon a plugin that was disabled.

Parent theme loads parts from parent

Brought up in #16. Currently parent theme will load parts from the parent theme but the part names from the child.

When using areas, multiple instances of the same part display

This is related to the field data stuff that @dusty was working on because there was a solution for this problem built in a while ago that's no longer working.

Saved layouts custom columns

Let's add some custom columns to the saved layouts page:

• areas
• metabox hidden
• post types

Remove unused method in WDS_Page_Builder_Layouts

https://github.com/WebDevStudios/WDS-Simple-Page-Builder/blob/develop/inc/class-wds-page-builder-layouts.php#L18

Method was added when I was trying to port over the old layouts method and never removed when I changed layouts to a CPT.

Show/hide areas per page

It came up in f2s conversation that it would be nice to not display certain areas on all pages. For instance, a homepage area should only show on the homepage edit screen and maybe not other areas, whereas the other areas may need to display on all edit screens except the homepage.

Maybe we could add 2 new lines in the header for including and excluding edit pages?

Rough idea

/**
 * ....
 * Include: home
 * Exclude: all
**/

Backwards compatibility for do_action( 'wds_simple_page_builder' )

We have sites that are based around the action and it's in the documentation. Even if we're no longer recommending using this action, we should still make sure it works to some degree.

Was working with @JayWood today and we were able to replace existing calls to do_action( 'wds_simple_page_builder' ) with wds_page_builder_area() -- I think we could just change what function the action hooks to, and hook to the wds_page_builder_area instead with some minor tweaks and be good to go.

Saved Layouts - cannot remove a saved layout after creating

I see the 'Remove Layout' button, but appears inactive even though I created and saved a new 'Saved Layout', therefore I can not actually remove the layout.

New default area layouts needs defaults per post type

We need to be able to set default layouts for each area per post type. I think this should probably be handled on the new layout post type rather than on an options page. This wouldn't work if you wanted xyz layout for the Hero for Car posts but zyx layout for the Hero for Train posts.

saved_page_builder_layout_exists check

add a check for saved_page_builder_layout_exists, e.g.:

if ( saved_page_builder_layout_exists( 'layout-name' ) :
     /* do something */
endif;

Option to enqueue scripts if needed per part

Wondering if we can pass an optional argument through wds_page_builder_load_parts() to either of the following places that would allow user to wp_register_script() in their theme's functions.php, and then pass the argument to enqueue for certain part(s):

• https://github.com/WebDevStudios/WDS-Simple-Page-Builder/blob/master/inc/functions.php#L74
• https://github.com/WebDevStudios/WDS-Simple-Page-Builder/blob/master/inc/functions.php#L111

An example, in functions.php (or our _s /inc/scripts.php):

    wp_register_script( 'packery', get_stylesheet_directory_uri() . '/bower_components/packery/dist/packery.pkgd.js', NULL, $version, true );

then in template where we want to output parts we reference and pass the $handle parameter from wp_register_script:

<?php do_action( 'wds_page_builder_load_parts', 'packery' ); ?>

github submodules don't exist in zips :(

On a fresh instance on GoDaddy's new "Pro" Managed Host (test server) I get the following upon trying to activate:

Warning: require_once(/home/content/p3pnexwpnas07_data03/82/2695782/html/wp-content/plugins/WDS-Simple-Page-Builder//inc/cmb2/init.php): failed to open stream: No such file or directory in /home/content/p3pnexwpnas07_data03/82/2695782/html/wp-content/plugins/WDS-Simple-Page-Builder/wds-simple-page-builder.php on line 37

Fatal error: require_once(): Failed opening required '/home/content/p3pnexwpnas07_data03/82/2695782/html/wp-content/plugins/WDS-Simple-Page-Builder//inc/cmb2/init.php' (include_path='.:/usr/local/php5_4/lib/php') in /home/content/p3pnexwpnas07_data03/82/2695782/html/wp-content/plugins/WDS-Simple-Page-Builder/wds-simple-page-builder.php on line 37

Fatal error: require_once(): Failed opening required '/home/content/p3pnexwpnas07_data03/82/2695782/html/wp-content/plugins/WDS-Simple-Page-Builder//inc/cmb2/init.php' (include_path='.:/usr/local/php5_4/lib/php') in /home/content/p3pnexwpnas07_data03/82/2695782/html/wp-content/plugins/WDS-Simple-Page-Builder/wds-simple-page-builder.php on line 37

Ability to drag-n-drop parts from one area to another

Ran into this yesterday...I built a part using the new fields functionality. It took a while because of all the images and text I had to input. When I was done, I realized I had it in the wrong area and had to start all over. 😭

Add a drag and drop template part, to create layouts with template parts

The idea is to have a template part and when this is chosen have a custom cmb field show that is a drag and drop for template parts specific to this draggable area. Like if it was a 2 or 3 column layout and give a user ability to drag between columns. Sorta like WP widgets but with better UI.

I'm going to do this as a plugin and not in core as core should not be bloated with this end user UX/UI

Ability to disable post editor and other metaboxes when "Page Builder Only" page template is used

When we use the "Page Builder Only" page template, we don't need to have the post editor metabox on the screen. It's confusing and creates clutter.

If we're going to disable that, let's look into disabling other metaboxes too (Yoast, Featured Image, Comments, etc... )

(Featured image is great, but I'd rather a client add an image via Page Builder field, than try to explain why they need use a one-off metabox to the right)

Registering Areas Permanent

Once you use register_page_builder_area() to create an area, it persists.

Feature request: Option to set default global for posts

If a post does not have any parts assigned to it then have a repeatable field group on plugin's settings page to allow user to set default parts to display.

unregister layouts

We have a way to register layouts, and layouts get updated if they are changed, but we should be able to unregister layouts, too. Something like:

unregister_page_builder_layout( $layout_name );

...or...

unregister_page_builder_layouts();

^^ which would unregister all layouts.

multiple part checks in wds_page_builder_after_load_parts sometimes leads to all the js loading

Weird issue that didn't have time to debug fully...adding a second parts check to a function hooked to wds_page_builder_after_load_parts caused all the js to load on a particular page, including page content from a completely different page.

source:

/**
 * Conditionally enqueue styles & scripts via Page Builder.
 */
function wds_clp_enqueue_page_builder_scripts() {

    // Get the page builder parts.
    $parts = get_page_builder_parts();

    // Knowledge Park Search.
    if ( in_array( 'part-facetwp-searchform', $parts ) ) {
        wp_enqueue_script( 'chosen' );
        wp_enqueue_style( 'chosen' );
        wp_enqueue_script( 'wds-clp-facetwp-search' );
        wp_enqueue_script( 'jquery-ui-accordion' );
    }

    // Contact/FAQ page.
    if ( in_array( 'part-contact-faq-content', $parts ) ) {
        /**
         * If WP is in script debug, or we pass ?script_debug in a URL - set debug to true.
         */
        $debug = ( defined( 'SCRIPT_DEBUG' ) && SCRIPT_DEBUG == true ) || ( isset( $_GET['script_debug'] ) ) ? true : false;

        /**
         * If we are debugging the site, use a unique version every page load so as to ensure no cache issues.
         */
        $version = '1.0.0';

        /**
         * Should we load minified scripts? Also enqueue live reload to allow for extensionless reloading.
         */
        $suffix = '.min';
        if ( true === $debug ) {
            $suffix = '';
        }
        wp_enqueue_script( 'jquery' );
        wp_enqueue_script( 'jquery-ui-core' );
        wp_enqueue_script( 'jquery-ui-tabs' );
        wp_enqueue_script( 'wds-clp-contact-faq', get_template_directory_uri() . '/js/contact-faq' . $suffix . '.js', array( 'jquery-ui-tabs' ), $version, true );
    }
}
add_action( 'wds_page_builder_after_load_parts', 'wds_clp_enqueue_page_builder_scripts' );

add `page_builder_class` function

would work like post_class does in WordPress core. echoes a generic class (e.g. pagebuilder-part) and takes an optional string parameter to pass specific classes. would be used in markup when building containers/wrappers, e.g.

<div <?php page_builder_class( 'my-class-name' ); ?>>
     <!-- stuff here -->
</div>

which would display as:

<div class="pagebuilder-part my-class-name">
     <!-- stuff here -->
</div>

Options Filter/Function

As we discussed on Skype, would be super cool if there was an options filter. Much like how we use wp_nav_menu

wds_client_page_builder_options( array(
   'container'       => 'section',
   'container_class' => 'part-container',
   'parts_folder'    => 'parts',
   etc...
) );

Restrict template parts by post type

similar to #30 -- instead of restricting template parts to specific areas, restrict them to specific post types, so a user is seeing template parts that are relevant to the post type they are editing.

Page Builder menu should link to options page

Change the page builder menu top level link to link to the options page instead of the saved layouts page.

Default Templates support for Areas

Right now I can't setup a default template and configure what parts are in what areas by default, so I'm having to configure on a per-post basis.

https://cloudup.com/c2GNxJ6lCAV+