4

One can see from the code on the WordPress Importer Plugin that it was a thought decision to bail early when imported posts had post_title and post_date matching existing posts.

For that reason, they don't run the imported versions through wp_insert_post() which would update them accordingly. There are also no hooks to modify this behavior.

Does anyone know a of a clear reason for this? Was it just a decision-not-options design or are there's any hidden gotchas that could creep from that sort of repurposing?

I'm trying to decide wheter I'll send in a patch adding that hook or actually fork this and build my own version without that restriction, so it would be handy to know.

Improve this question

2 Answers 2

Reset to default
1

I can see both sides of the coin in the situation and they are reasonable.

If you are interested in this feature for this plugin and the plugin otherwise meets your needs, I would say re-write the section of the plugin which handles this evaluation and add in the allowance for an optional argument (boolean in this case should be fine) that acts as a flag to either omit or overwrite and propose it to the plugin author (assuming they are actively maintaining it). While temporarily maintaining your own, customized version

Improve this answer
2
  • I'm actually looking for a solution to migrate data from staging to production in the least messiest way, so it seemed like a good idea to use the "native" plugin. Also seems likely that they thought it over before closing the door on updating posts, so I just want to measure how deep I'll need to go into this to be able to use it.
    – moraleida
    Commented Dec 11, 2014 at 22:53
  • makes sense and I can appreciate it. I've seen similar "gotchas" in plugins I have to support and sometimes business requirements are such that the customization is necessary. is this sense, your "update" is likely additional functionality and it's related metadata being introduced during a push to prod. Short of a mirrored server and some routing work, you would likely be better served to simply fork the plugin and manage it as a separate entity and submit an update request with your suggestion. Decision by committee and necessity and all that
    – Brandt Solovij
    Commented Dec 11, 2014 at 22:57
0

Updating the posts would involve the possible destruction of data, which would be unexpected and could cause a lot of problems. This is why the importer doesn't update posts.

Making sure you only update the posts that have been updated, with zero accidental clashes were 2 unrelated posts had the same title, or if the post was updated in the import, and on the site, etc etc is extremely difficult.

It's safer to simply not update, thus ensuring there is never a loss of data.

This question implies you have an issue syncing content between a production and staging environment, and this is your solution ( which itself has an issue ). Perhaps you should return to the original problem.

Improve this answer
2
  • I'm aware of the dangers of ovewriting by default. What intrigues me is the fact that there isn't a hook to allow for that. Makes me wonder if it was just a decision-not-options design or if there's any hidden gotchas that could creep from that sort of repurposing. As I commented on the other answer, this is indeed an issue of moving content around environments, but from dev to staging to production, which makes a sync impossible. The other way around is obviously much simpler.
    – moraleida
    Commented Dec 12, 2014 at 13:07
  • Adding a hook means implementing updating, which means dealing with the maintenance and support of people such as yourself who try to use it and managing their expectations. It's simpler, easier and cheaper simply not to do it
    – Tom J Nowell ♦
    Commented Dec 12, 2014 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.