I do a lot of exporting and importing, and within the last month or so, I noticed an issue where the import process creates duplicate templates, styles, etc.
At first, I thought this was something I was doing wrong, but it’s happening when doing very straightforward imports with only minor changes to existing templates/styles, so I believe an issue has been introduced with a recent plugin update.
Before this issue appeared, the process was flawless, and I never once saw an issue after hundreds of exports and imports.
Basically, what happens is I will do an import and get an alert for a new file that already exists. The new template/style is renamed with a -2 at the end.
While writing this post, I realised this may have started with the introduction of the .png export format. I will try using only the .json export for a while and see if that resolves the issue.
Update: Tried using the .json export/import and ended up with a ton of duplicates.
Something that might be related is that some of my templates did not have a Universal ID; however, this seems to be resolved after deleting all templates and re-importing them using the .json file.
Is the Universal ID required to match templates across websites?
Yes, it’s how the importer recognizes duplicate templates across sites, since their post IDs can be different.
You’re right about the cause of the issue: from the screenshot, it looks like some templates are not getting assigned a universal ID for some reason, causing them to be created as duplicates during import. The logic for assigning universal IDs hasn’t changed in a while, so I’m not sure why/how the issue is happening - but the solution will be to make sure templates always have a universal ID assigned, during post save and maybe also check before exporting.
Right, I have many templates, some of which are quite old, so something probably happened in the past. I know how to ensure they all have the same UID now, so this should resolve the problem of migrating templates between websites.
I am still having issues with duplicates. The only way to avoid them is to delete all existing templates before doing an import.
I suspect there may be a conflict with the Permalink Manager Pro plugin. The plugin has a page to exclude custom post types, but L&L does not appear as an option.
@eliot I believe L&L uses custom post types for storing templates, so I’m just wondering why it would not appear here under Post Types. The Galleries post type I created with ACF can be seen.
It could be that the Permalink Manager Pro plugin is only querying for publicly viewable post types for listing in their settings page. L&L template types are registered as non-public, only for viewing in the admin area by admin users.
I think the issue will be solved when I implement #69, which is for the exporter to assign universal IDs to any templates that don’t have it yet.
@eliot I’ve narrowed this bug down to using the CTRL+S shortcut for saving templates.
For some reason, using this save method removes the UID from the template instantly, which I think is also why I’m getting duplicates during export/import.
Tested on a vanilla WordPress install with only L&L active.
Given that issue #69 has been resolved, it seems this has been fixed in the template system codebase (you can download the latest zip here and install it like a regular plugin) but it hasn’t made its way into a versioned L&L release on the WP repo yet.
@eliot is there a particular reason we’re holding off on releasing this batch of bug fixes?
@Rips could you provide some additional info about your template and setup and maybe do a bit more troubleshooting to identify what exactly about those options page fields isn’t working? I just created a vanilla WP install with an options page containing a few different types of fields and I was able to display them using <Field field_name from=options /> even with the latest build from Github (the Tangible Template System plugin) activated.
The latest build has made some changes to the way ACF’s date/time/datetime fields work, since they were a bit broken before. I’m able to display those field types with no problem, but maybe your template is doing something funky.
Let me know what’s going on on your end and I’ll try to replicate your issue and pass it along to a dev
Marking this thread as resolved since this fix was released in 4.1.0 and the other issues that arose in that version have (I believe) all been addressed in other threads.
Template post types: Ensure templates always have a universal ID assigned, during post save and before exporting. This improves how duplicate templates are handled during import.
