In this week's post we'll take a closer look at the importing side of our upcoming export/import tool. Plus we'll look at something new in 3.0.70 called markup region hints, which are worthwhile if you are using markup regions in PW3.
A couple of weeks ago we showed you some screenshots of our page export/import work in progress. I was hoping to release an initial version of that tool today, but feel like I need to do more testing and save it for next week. Nevertheless, I do have a lot more progress here, and the tool is now functional and working, so I'll continue with some more screenshots and information about it this week.
In our last post about it, our focus was on the export process. This week we'll look at screenshots of the import process. When the import tab is selected, you have a choice of pasting in text from a previous JSON export, or uploading a ZIP file export.
Once you've pasted in (or uploaded) import data, the tool analyzes the data for the next step in the process. Below is what that screen looks like. At this stage, it wants to know how and where you want the import to proceed.
As you can see above, now you can perform a test import before commiting the changes. This gives you the opportunity to see what's going to happen, as well as the option of excluding pages from the export. Below is what it looks like after performing a test import:
Our test import above looks fine, so we are going to go ahead and commit it. When we do that, the following screen gives us a summary of what happened. At this point our pages are imported and our work is done.
The first version of this export/import tool will be very simple in appearance. But beneath the surface, there's actually quite a lot to it. In ProcessWire, fields are represented by Fieldtype modules (plugins). The core knows nothing about the data managed and stored by the Fieldtype. That's the job of the Fieldtype, and that's by design. It means ProcessWire can support any kind of type, store any kind of data, known or unknown, whether now or in the future. This is a huge benefit, but also creates a challenging task for any export/import tool, as the data that a field can store is very broad, and it's pretty much a black box to the core.
Thankfully, the Fieldtype interface has long had exportValue() and importValue() methods. The purpose of these methods is to make data stored by the Fieldtype portable for exporting and importing. Very few Fieldtype modules actually override and implement these methods, as they were rarely if ever used, until now. Which is to say, the page export/import features of ProcessWire have been in the plans for a long time, and now we're finally bringing them to life. But we've not paid much attention to these methods in the Fieldtype interface till now, and they'll now be getting a lot more attention.
When these Fieldtype exportValue and importValue methods aren't implemented, they fall-back to the Fieldtype sleepValue() and wakeupValue() methods, which are perfect for Fieldtype modules with basic storage needs. But for modules with more complex storage needs, we'll be implementing the exportValue/importValue methods one-by-one. This includes Fieldtypes like like File, Image, Page, Repeater, PageTable, and all the ProFields modules (I just implemented ProFields Textareas this morning). So the initial version of our export tool will be able to import/export many–but likely not all–of the fields. Stay up-to-date and we'll have most covered before long.
In this week's version of ProcessWire, we now have support for something called markup region hints. If you are using markup regions, then we think you may find these worthwhile. It's very easy for ProcessWire to figure out where a markup region begins, but can sometimes take a lot of work for it to figure out where a markup region ends. That's because a markup region might end with a common </div> tag, and in a large section of HTML, there might be several hundred others that it has to sift through before it knows which is the one that ends the region.
Now you can give ProcessWire a hint about which closing tag ends a region. This enables it to operate more efficiently in large HTML documents. In small HTML documents, it likely won't matter much, but it never hurts. These hints consist of HTML comments that come immediately after the closing tag of a markup region. For example, see the <!--#content--> comment at the end of this markup below. This hints that this is the end of the markup region with id of "content".
html<div pw-append='content'> <p>Pretend there's a bunch of markup here</p> </div><!--#content-->
The hint works regardless of what tag or format you are using to start your markup region, or regardless of whether you are using an "id", "pw-id", "data-pw-id" or "pw-[action]" attribute to identify the region. (In the example above, we used a "pw-[action]" attribute.) Using markup region hits helps ProcessWire be more efficient regardless of whether used in the source document (i.e. _main.php) or in any template file that modifies the output of the source document. Meaning, if you opt to use markup region hints, you can use them anywhere you define or manipulate a markup region.
Use of markup region hints is completely optional, and really not necessary for most. But for those that want to optimize the performance of markup regions as much as possible, they are worthwhile, especially when dealing with lots of data and repetitious closing tags like </div>. These hints are pretty darn helpful for your eyes at times too.
Thanks for reading and have a great weekend. For more ProcessWire news be sure to read the ProcessWire Weekly (new editions every Saturday).
This week's version of ProcessWire on the dev branch is 3.0.69 and it includes several minor bug fixes. This week's post focuses in on a new module released today called Login for Facebook, which I think many might find useful, and we've got all the details here. More
We've added a new pages export/import feature to the core! In this post, we tell you how to install it and use it. This post is also updated for related additions added in ProcessWire 3.0.72. More
“Yesterday I sent the client a short documentation for their ProcessWire-powered website. Today all features already used with no questions. #cmsdoneright” —Marc Hinse, Web designer/developer
adrian
import and update existing pages is determined by what ?
Reply
Ryan
See second screenshot, first field "Import mode". As for how it determines whether a page is new or existing, it's not safe to use page IDs because they are likely going to be different between the system they were exported from and the system they are imported to. As a result, it uses the page path. If you select a specific parent to import to then it uses just the page name.
Reply
szabesz
It would also be good to support page IDs too, optionally. When re-importing into the same system, page IDs are even safer than paths/names.
Reply
Chris
- 7 years ago
- 00
★★★★★I love the new markup region hints and have put them in my latest project I am starting today. It wont be huge but it will get me in the habit.
Is there anything you could use that won't appear in markup (I have ProCache stripping comments out so it doesn't matter for me).
Reply
DDV
The import/export works perfect, even managed to transfer a bunch of MapMarker fields from one site to another.
Reply