Copy a row to another page

Glad to have turned you on to clipboard.js! You’re right that inserting into the Page Builder post_meta record would limit the ability to copy between installs, and you’re also right that that is an important feature of a Copy Row feature. I’ve done some more thinking about how to solve that problem.

This also led me to realize that a useful feature in a row copy scenario would be the ability to multi-select rows to copy, rather than having to choose between one-row-at-a-time and the-whole-page.

A ‘Copy Rows’ toolbar button would add a checkbox next to each row. Once one checkbox is ticked, the ‘Copy Rows’ button would activate dropdown available next to it with the options of Export to File, as well as a list of all pages/posts that are Page Builder pages. The Export to File would download a JSON file similar to your current export and would likely contain an initial comment indicating that this is a ROWS file, rather than a PAGE file.

SOLVING THE PROBLEM BETWEEN INSTALLS
Divergent UI processes are created if copying a row between installations uses the clipboard for a copy/paste process, while copying a page between installations uses a file download/upload process.

Copying a row between installations is (to some extent) already supported by the existing Import tool. Extending the Import tool to differentiate a PAGE file from a ROW file would allow the user to export either a row(s) or a whole page structure for moving between installs and the import tool would simply execute the correct import method, depending on the source file type. Now we have a single path to take whether we’re copying rows or duplicating a page.

I realize that importing a page layout currently overwrites the existing Page Builder content, but if we checked what kind of import is happening, the ROW import file could be handled differently than the PAGE file. The ROW file could be parsed and inserted to the gird without overwriting the existing grid by reusing the row-insert method (theoretically) used by the copy-a-row-within-an-install process:

$target_post_ID = $post->ID;
$content = array(widget_content_imported_from_file);
$grids = array(grid_definitions_imported_from_file);
$page_builder_page.insert_row_to_post_meta( $target_post_ID, array( $content, $grids ) ) );

SOLVING THE PROBLEM IN A SINGLE INSTALL
Once the between-installs row copy process is implemented via direct DB manipulation, it’s trivial to implement that solution within an install. Rather than the source data coming from a file and the target post ID being the current page/post, it would look similar to this:

$target_post_ID = $selectedTargetID;
$content = array(widget_content_from_identified_rows);
$grids = array(grid_definitions_from_identified_rows);
$page_builder_page.insert_row_to_post_meta( $target_post_ID, array( $content, $grids ) ) );

Additionally, if the “Select your target pages/posts” were a multi-select box, you could do the following:

$target_post_ID = $selectedTargetIDs;
$content = array(widget_content_from_identified_rows);
$grids = array(grid_definitions_from_identified_rows);

foreach ($selectedTargetIDs as $targetID)
  $page_builder_page.insert_row_to_post_meta( $targetID, array( $content, $grids ) ) );

I hope this reasoning encourages you to use the post_meta concept, rather than the clipboard concept. While it seems cool to be able to use the browser clipboard, I feel that the post_meta concept allows for the most flexibility in choosing multiple rows, copying to multiple destinations, exporting across installs, and minimizing the number of UI processes the user has to remember.

Thanks for the discussion on this one!