[Turned Down]: Option to save / load all categories & albums (without pictures) [Turned Down]: Option to save / load all categories & albums (without pictures)
 

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Main Menu

[Turned Down]: Option to save / load all categories & albums (without pictures)

Started by CARST, July 04, 2009, 09:34:31 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

CARST

Hello everyone,

i would like to have an option to to save the category-album-structure to a file and load it again.

Everytime i set-up a new server i have to create all 15+ categories and about 550+ albums from scratch. Batch-adding the pictures isn't that time-consuming, but creating all the albums is a pain in the a*s.

I could imagine that the plugin/feature could write a file which would look like this:
<cat "no=1" "parent=none">Name of category 1</cat>
<subcat1 "no=1" "parent=Name of category 1">Name of sub-category 1</cat>
<album "no=1" "parent=Name of subcategory 1">Name of Album no1</album>
... more albums ...
<subcat1 "no=2" "parent=Name of category 1">Name of sub-category 2</cat>
... more albums ...
<cat "no=2" "parent=none">Name of category 2</cat>
<album "no=3" "parent=Name of category 2">Name of Album no3</album>
... more albums ...


etc....


The file should have a very easy structure so everyone could write it by hand and not having to create all cats/albums "online" at CPG.

Regards,
Carst

Nibbler

Just export the albums and categories tables using phpMyAdmin. Then import the dumped files when needed. No need to reinvent the wheel.

CARST

I get your point Nibbler, but ...

1) I once saved the whole CPG database before moving to a new server and after importing the DB CPG went all crazy and i had to setup everything from scratch, could have been a one-time thing but nevertheless not the optimal solution...

2) The advantage of my idea is to write the file on your computer and then have the possibility to import it everytime you setup a new server, totally indepent from MySQL or CPG versions...


Rgds,
Carst

Nibbler

What you suggest would only be useful to people that need to set up multiple servers with the same cat/album structure but are unable to do simple table dumps correctly. I don't think this would be useful to enough people to be a core feature of Coppermine.

Αndré

Quote from: Nibbler on July 04, 2009, 11:12:22 PM
I don't think this would be useful to enough people to be a core feature of Coppermine.
Agree. It's very easy to do this with a regular database export/import. No need to reinvent the wheel.

Joachim Müller

Quote from: CARST on July 04, 2009, 11:07:07 PM
1) I once saved the whole CPG database before moving to a new server and after importing the DB CPG went all crazy and i had to setup everything from scratch, could have been a one-time thing but nevertheless not the optimal solution...
You probably haven't created the dump properly, which is sad for you, but not really a valid reason to create a complicated feature that will create a proprietary backup. In an ideal world, coppermine could create a database dump for backup purposes. That's what the existing backup plugin does. That's what might go into a future version. What will not go into future versions is your suggested special flavor of XML data that just serves as failure-prone surrogate for a real database dump.
If you have created a dump and want to make sure that it will work as expected, just attempt a restore on a temporary platform (a local testbed would be fine for that purpose, e.g. the Coppermine Live Demo), before deleting the source (or before the source get's inaccessible because you switch webhosts). That's best practise for all kinds of database-driven apps. There really is no reason to change that, as your proposed method would inherit all possible flaws that database dumps have (danger of timeouts for large dumps, problem of escaping special chars properly, collation issues etc.).
While we welcome your suggestions and want to encourage you to keep on contributing in one way or the other, we have to turn down your feature request. Marking thread accordingly. Please don't get discouraged by that: maybe you had a bad start with mySQL dumps, but they really work fine once you understand where the problems lie.