Jump to content

Recommended Posts

Posted

Agreed! The way things are going with my community, the CMS/Pages content will likely be some of the most valuable we will have (with collaborative databases etc), would be great to have an extra layer of backup security for this app.

Posted

It’s unlikely to happen though because of all the dependencies (like member IDs, foreign database IDs et cetera) in those databases. They could be deleted between export and import, which would essentially break site. 

  • 3 months later...
Posted

Bumping this as I think this would be a good option to have.  Could have a warning that it should only be used as a backup (all content), or toggle a switch if there are plans to use on a different site (different members, for example) and then it will filter out certain fields.  Great if you want to share a database and the records, but not share author names (since the user ID's and such won't match up) or the 'post_key' and such.  But if copying from a dev to a live site, might be able to do a full download/upload.

The only real issue I see is with the category ID's.  For the 'field_id' number, the field key could be used so on import, a matching field_key can be found and it get sorted that way.  If no matching one is found, then it reports it as an issue to resolve before the database can be used.  (Import all the records first, then handle the re-assigning of the field_key values.)

Category ID could be tackled by a new SQL column that provides a unique key to each category as it's created and then match it up that way.  MD5 hash of {site's URL}{microtime()} so that it's a key that should never be encountered again.  Continue to use the numerical category ID# (simplicity among other reasons).

Maybe someone could make a 3rd party app to handle it. 😊

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...