View Documentation

Gallery Merge:

The 'near impossible' attempted.. :) Merging two Coppermine Photo Galleries! Having collapsed a few websites into one - and finding myself with multiple galleries... Finding several requests over the years in the forum looking for the same capability... I decided to tackle the project.

This plugin offers the ability to merge 2 Coppermine galleries into one - running the merge in the target or receiving gallery. Merges database records, and optionally image files (if local filesystem).

  • The galleries must be at the same version/maintenance level
  • If both galleries are on the same server, simplest to allow the plugin to merge both files and database.
  • If galleries are on separate servers - the file moves will be left to the user.
    A remote connection to the database will be needed (or a local copy made) to complete the DB merge.
  • The galleries cannot be bridged. (see note below)

CONFIGURATION settings allow specification of local or remote, filepath specification for local, and database connection information for remote. Options for handling duplicates, permissions, copy/replace are provided. Varying levels of messages and debug can be set to see what is (or will be) happening.
Specified CPG Config options are used for values like album and userpics filepaths, etc.

 

A SIMULATION mode is provided - and the default - that will perform all the checking, and generate the migration SQL, but NOT execute it. Any exceptions needing investigation will be reported. Once satisfied that any conflicts have been addressed (rerun simulate as many times as needed) - then select EXECUTE and let the plugin do the work! Depending on gallery size, it may be necessary to 'break up' the processing. Thresholds provided can be set to quiesce the process, and restart to resume to fit within your servers memory and execution limits.

 

A note about Bridged Galleries..
A bridged gallery is tied to another application (forum, etc) for user and optionally group assignments and management. The current release of this plugin does not support merge for bridged galleries - as it will not be able to determine the new userid and groupid to use for mapping.
I do intend to support these configurations with a future release - with the caveat that moving users and groups between bridged applications would have to be done first by some other means... This is after all 'gallery merge' and not 'forum merge' :) The plugin would access the forums data for mapping purposes to preserve ownership. My thoughts here would work if only one gallery is bridged - or if the galleries are bridged to different applications... But some code to write still to make that happen.

 


Of course - PLEASE - backup the TARGET filesystem and database prior to running the actual merge! The SOURCE system is only read from - no changes will be made there. Yes - the script will backup the database tables being changed as well - and offers the ability to restore/backout the database changes - but ultimately the backup responsibility, and ability to recover your gallery remains YOURS.
The plugin makes no attempt to backup the target filesystem - again that responsibility is YOURS. The plugin should only update the albums directory - and based on config settings can add to plugins, languages, and themes directories. I recommend completing the merge on a test copy of your gallery first to verify expected results.

 

Generally I would recommended merging filesystems and then the database (though both can and should be simulated before any executions.) This order will prevent entries in the database from referencing non-existant files in the event your gallery in online. It also allows the optional copying of any missing plugin folders for plugins you may need to install in the target.
Special note if you are using User Galleries:
(if albums/userpics is populated with folders like 10001, 10003, etc) - Merged Database information is needed to properly name these folders (see details about userpics below).
File simulation will report if this case exists. File execution is designed to process all other files and will then pause/quiesce if database merge is required to complete userpics processing. File execution can be restarted when database merge is complete.
Of course if database merge is completed first, File Execution will process all - including User Galleries.

 

File Merge:

For FILE MERGE, the gallery can remain online - as we will not be impacting current gallery functions. Of course any files added to the source gallery AFTER merge execution will not be copied over... so uploads, or actions creating thumbnails, etc during this time are not recommended...

The following are compared:

  • Languages: Compares all language files in main CPG lang directory.
    Optionally (config setting) can copy any unique language files from SOURCE to TARGET
  • Plugins: Compares all plugin folders in main CPG plugins directory.
    Optionally (config setting) can copy any unique plugin folders from SOURCE to TARGET
    This will only copy complete main folders (and all contents/subfolders) if the main folder does not exist in TARGET.
    No copy/merge will be performed if main folder already exists.
    *Note - this does NOT install the plugins - that must be done manually using the Plugin Manager to allow the plugin to run its install script.
  • Themes: Compares all theme folders in main CPG themes directory.
    Optionally (config setting) can copy any unique theme folders from SOURCE to TARGET
    This will only copy complete main folders (and all contents) if the main folder does not exist in TARGET.
    No copy/merge will be performed if main folder already exists.
  • Albums: The main effort to compare all pictures/media in Albums path
    This folder is named based on the CPG Config setting 'fullpath' - the default value is 'albums/'
    Option (config setting) to replace existing files in the event of conflicts (default NO).
    'edit' directory is excluded - this is a temporary home regularly cleaned.
    'userpics' - is handled separately - see below
    Simulate drives only deep enough into the directory structure to identify any conflicts.
    (ie: if albums/dir1 doesn't exist in target, then no subdirectories under dir1 need to be verified)
    Execution of course processes all directories - driving php file copy recursively with checkpoints on completion of each directory, and ability to pause at threshold limit of copies.
    If desired of course you can use your cpanel's copy/move functions or shell commands to perform the copy/move yourself (but read my notes on userpics first!), and use gallery_merge to handle the database side.
  • Userpics: The unique userpics folder in your albums directory
    This folder is named based on the CPG Config setting 'userpics' - the default value is 'userpics/'
    A different structure as pictures are stored here in folders that depend on the users id (10000+userid) in most cases - so we have to process this differently. Any files in the main userpics folder will be copied (based on replace settings). Files could reside in main userpics folder if running CPG in 'silly_safe_mode' - which disables the folder creation for each user.
    For each numeric folder (10000, 10003, etc) we will identify the user in source, and its corresponding userid in target to set the new destination folder name.
    There is a 'hidden' option in CPG named 'upload_create_album_directory' that creates a numeric folder within the users folder for each album (when they choose the album to upload to). If the option and folder exist, the folder name will also be translated to match the new album id.
    If the source contains 'new' (to target) users - this will require the database merge to be completed before file merge - so we can obtain the new userid.
  • Remaining CPG files/folders Directory compare only to see if any files/folders in SOURCE are missing from TARGET
    These will NOT be copied/merged - just reported for your review.
    Contents will not be compared - except for anycontent.php to see if it is in use/different.

 

Database Merge:

For DATABASE MERGE, it is recommended that the gallery be offline - warnings will be issued if it is not.
If you choose to have the gallery online, please insure no other admin or user updates are occurring - including adding pictures, categories, albums, users adding comments or making votes.

 

The following tables (with your specified prefix) are examined and differences reported:
(No merge actions taken automatically for these tables)

  • cpg_config - compares all parms and reports differences.
    review output and determine if parameters need to change in target.
    make any required changes via normal cpg admin menus
  • cpg_plugins - compares and reports plugins actually installed in the source, and not in the target
    installing these plugins is up to you to do via pluginmgr - as you need more than just updating this table.
  • cpg_bridge - The contents of this file are unique to an installation and would not be appropriate to merge. Use bridgemgr.php to adjust any settings if needed. (Note V1.0 of Gallery Merge doesn't support bridged galleries.) In a non-bridged gallery, there will be only a few entries, and all blank or '0'.

 

The following tables are merged in the order given.
Source and target table structures are compared to validate inserts will work (with checks for obsolete fields in the event they still exist in older galleries.) All relationships (users to usergroups, albums to catagories, pics to albums, etc) are maintained via mapping arrays to convert references.
By default, the process assumes no duplicates exist WITHIN the target for usergroup, user, category, album names... (only users is enforced by database structure). Records coming from the source will be merged into existing target entries with same name. (ie: same category name exists in source and target - all source sub-categories and albums in that category will be related to existing target category)
An album that is a user album in one gallery, and system album in the other is NOT considered a duplicate. User albums owned by different users between target and source are also not considered duplicates. If there is a duplicate in the target system AND there is a matching source record we need to merge that matches - we will issue a warning/error (depending on execution mode) as we don't know which one to map to. Plugin config options allows a specification to add all categories and/or albums as new even if same name exists already - which also allows duplicates to exist in the target (since we don't need to map to them...)

For any duplicates found, the difference between source and target will be reported. Differences that are resolved by mapping are accounted for (ie - pic1 is in album1 in both source and target, but album1 has a different aid in each gallery - is not considered a difference). Fields that will be obviously different (time/date stamps, hit counts, etc) are not reported as differences.
Some config options to minimize memory use affect the amount of data that can be compared - see doc on config settings below.

  • cpg_usergroups
  • cpg_users
  • cpg_categories
  • cpg_albums - hits merged, keyword updated if not already set in target for any duplicates; all values preserved for any inserts
  • cpg_pictures - hits, ratings, keywords merged for any duplicates; all values preserved for any inserts
  • cpg_categorymap
  • cpg_comments
  • cpg_favpics - favorites of users exisitng in both galleries merged

 

The following will be re-generated if in use

  • cpg_dict - holds album keywords in use. Not required, but if populated, will be rebuilt after above merges

 

The following contain transient, regeneratable data, or static - no action taken - and no impact expected

  • cpg_exif - only used if exif processing is set in config table can be emptied any time and will be re-populated as pics are viewed. (has been truncated in previous release updates)
  • cpg_banned - transient data and hopefully not heavily used. Data regularly purged by Coppermine based on expire date.
  • cpg_languages - static data - updated only by maintenance as far as I can see..
  • cpg_sessions - transient data
  • cpg_temp_messages - transient data

 

The following tables are CONDITIONALLY used by CPG and contain historical information only.
Will let you know if table is being used, and number of rows, but no additonal actions taken.

  • cpg_ecards - log for ecards send if set in config
  • cpg_hitstats - log for detailed hit info if set in config
  • cpg_votes - detailed vote information if set in config (and regularly pruned)
  • cpg_vote_stats - log for detailed vote stats if set in config

 

PLUGIN data tables

  • Support is provided to allow accomodation of tables added by CPG Plugins - leveraging the mappings already performed
    For each installed plugin in SOURCE, will determine if plugin is installed in TARGET, if support exists, and produce appropriate messages and/or call necessary merge scripts.
    See readme_plugin_doc.php (or .txt) for detailed information on how to add support for a plugin you have.
    (If a plugin doesn't ALTER the structure of CPG tables or CREATE it's own tables - then it won't affect the data merge... Compare of the CPG plugin table performed earlier will tell you what plugins you may need to install for functionality to remain.
    This section deals with plugins that CREATE tables for Coppermine - with data that may need to be merged.)

 

The following tables are not addressed (will be listed)

  • 'unknown' tables - any tables using the CPG table prefix not listed here
    Tables will be listed in output for your review.

 

Installation:

Unzip the distribution files and upload the contents (including folder gallery_merge) to your plugins directory. In admin mode, select Plugin Manager, and click install next to this plugin.

During 'Execution' mode only, Gallery Merge will attempt to save logs to the gallery_merge/logs directory. To allow this, the gallery_merge/logs folder must be writable to the script. The same permissions used for your albums folder should work fine. (The process will continue without external logs if it cannot write to this location.)

A note about register_globals: This plugin works fine in a register_globals OFF environment.
If register_globals is ON however, code in CPG base deletes far more variables than those input through GET, POST, COOKIE, and does impact this plugin. You can either turn OFF register_globals (can typically be done at the CPG directory level if other parts of your site still require it - or view post in CPG forums at: http://http://forum.coppermine-gallery.net/index.php/topic,76938.msg371885.html#msg371885 fro a possible change to base CPG code to circumvent. The plugin does check to see if this condition exists, and will produce messages on the config screen if action is needed.

 

Uninstall:

Select Plugin Manager, and click uninstall next to this plugin.
The normal plugin manager confirmation will be displayed first - Click 'OK'
A confirmation dialog will be presented by Gallery Merge to allow you to select desired actions.
Gallery Merge maintains a restart table, backups of your tables, and log files in addition to config settings. Default options will be selected based on the saved state of your merge. If restart or backout is possible, the default will be to maintain the needed info. An informational message will be presented.
You can of course select any/all items to be removed.
Click 'Uninstall Gallery Merge' to proceed.

 

Configuration:

Gallery_merge installs into the TARGET or receiving gallery.
References to the SOURCE gallery refer to the gallery that will be merged into the TARGET.

 

Select configure on this plugin from Plugin Manager - or the Gallery Merge button added to the Admin menu.
The Configuration Settings are hidden by default. Click 'show' to expand (much like CPG configuration). Select appropriate check boxes, based on preferences.

config menu

Setting Descriptions:

  • Add button to Admin Menu?
    When checked places 'Merge Gallery' button in admin menu bar
  • Hide currently unusable buttons?
    By default, buttons that are not eligible to be selected are hidden. You can choose to have these buttons displayed, but set disabled. I have found some themes do not differentiate in the display of disabled buttons - and while they are still not selectable, the display is confusing as to what can or cannot be selected.
    Unselecting this option changes the behavior to display all buttons with those not eligible to select set disabled.
  • Is Source Gallery filesystem local?
    A local gallery exists in the same domain (www.domain.com) or its subdomains (subdomain.domain.com). In this case, the merge dialog will have access to the Source coppermine config information and will automatically connect to the database to gather needed information.

 

The following field is used for LOCAL galleries only...

  • Path to Source Coppermine Root: relative or absolute including document root (not http:)
    relative path: path from target gallery to source gallery main directory
    ie: gallery1 is at subdomain1.domain.com/gallery1 and gallery 2 is at subdomain1.domain.com/gallery2 the path would be ../gallery2
    absolute path: the document root of your webserver with continued path to the source gallery
    ie: (based on my ISP's standards) /home/domain/www/subdomain/gallery where subdomain is www for main or name of subdomain...
    To help - the default on installation will be the absolute path to your (target) gallery. Adjust as needed to get to source gallery.

The following fields are used for REMOTE galleries only...
For REMOTE galleries - we need to get to the remote database. In your ISP's control panel, under MySQL Databases, they should provide connection information for remote connections. The id used likely needs to be enabled for remote connections as well. It can be restricted to SELECT and SHOW privleges.

  • Source DB MySQL Connection:
    The connection string provided by the ISP of the Source gallery for remote MySQL connections host:port
    ie: mysql.serverxxx.com:3306
  • Source DB User Name:
    The id set up for remote access with at least READ and SHOW privleges
  • Source DB Password:
    The password established for id above
  • Source DB Database Name: (from source gallery file include/config.inc.php)
    The database used for CPG tables
  • Source DB CPG Table Prefix: (from source gallery file include/config.inc.php - default cpg_)
    The prefix used for CPG tables in the database

 

The following fields provide the (optional) ability to 'add' or 'remove' a level of folders to the files being copied to the target. For 'add', the specified folder(s) are inserted between the galleries album path (config fullpath) and the existing image location (pictures filepath). For 'remove', the specified folder(s) will be removed from those pictures where it exists (pictures filepath)
These setting do NOT apply to the CPG default edit/ and userpics/ folders.
This field will be used by BOTH file and database merge to provide a correct gallery at the end. Can be omitted if current folder structure is desired.
If source files are at {sourcealbums}/folder1, {sourcealbums}/folder2, etc - you can request the files be copied to {targetalbums}/{one_or_more_new_or existing_folders}/folder1, etc...
Examples:
Remove - If source gallery had some/all pictures in albums/pictures/folderx - and target gallery had all pictures in folders directly in albums, you could specify removal of pictures/ to have the matching source folders added to target as albums/folderx
Add - If source gallery had all pictures in folders directly in albums folder - and target gallery had all pictures in albums/pictures, you could specify addition of pictures/ to have the source folders/files added to the target pictures/ folder.
Can also be used to add a level of folders to eliminate duplicates.
Combine - If source gallery has all photos in albums/pictures/subfolderx and target gallery has all pictures in albums/eventx/subfolders, you could specify removal of pictures/ and addition of eventy/ to effectively change pictures/ to eventy/

  • Remove Source Album Subfolder:
    One or more levels of folders to be removed from matching image filepaths as they are copied to target gallery - ending in /
    ie: oldfolder1/ or oldfolder1/oldsubfolder1/
  • Add Target Album Subfolder:
    One or more levels of folders to be added to image filepaths being copied to target gallery - ending in /
    ie: newfolder1/ or newfolder1/newsubfolder1/ or existingtargetfolder/ or existingtargetfolder/newsubfolder1/

 

The following fields provide the options for handling duplicate categories and albums during database merge.

  • Merge Duplicate Categories? - (Default Yes)
    Should cataegories of the same name between source and target be merged?
    If checked, all subcategories/albums in source for the duplicate category will be inserted into the existing target category.
    if unchecked, the duplicate category will be inserted into the target gallery (you will have 2 categories with same name).
  • Merge Duplicate Albums? - (Default Yes)
    Should albums of the same name between source and target be merged?
    If checked, all pictures in source for the duplicate album will be inserted into the existing target album.
    if unchecked, the duplicate album will be inserted into the target gallery (you will have 2 albums with same name).
    The process does distinguish between user and system albums, and will not consider these a duplicate. Likewise same named user albums but owned by different users will not be considered a duplicate.

 

The following fields customize the behavior of permissions for the File Merge (only supported for local filesystems)

Disclaimer about File permissions:
I provide a method for specifiying or obtaining and setting permissions that works on my Linux shared hosting environment. What permissions are right for you depends on your hosting environment. Windows is of course completely different, so allowing permissions to default may be all that works for you. Of course you can always merge your files using another tools or cpanel interface. My providers cpanel doesn't allow copy without replace which was my desired default - and php copy didn't retain the source permissions - so I needed to do something...
I do give you a means to test your permissions settings without performing the merge to see what option works best for you... read on (hint - utilities)...
Simulating file merge when source filesystem is accesible (even if you will move the files yourself) will identify any conflicts between galleries that you may need to address.

  • Folder Permissions:
    Your choice of how to handle folder permissions during copy:
    • Default - Use CPG defined default parms for folders - which are displayed. Config database field 'default_dir_mode' under 'File settings' (Field 'default_file_mode' for files below)
    • Obtain from source file - current permissions will be retrieved from the source folder and used to create the new directory. Not a bad option for folders as volumes should be relatively small.
    • Use specified - use specific permissions you specify in adjacent text box
    • text box - the octal representation of the permissions to see for 'Use specified' - entered WITH leading zero (ie: 0755) The default value on install is the permissions (if I could get them) of your galleries 'albums' folder as indicated in CPG config.
    • None - no permissions will be specified during directory creation or file copy, and system will assign it's default.
  • File Permissions:
    Your choice of how to handle file permissions during copy. Exact same options as Folder above...
    An additonal note however - galleries quickely grow with numbers of files (thumb, normal, intermediate, original). Specifying 'Obtain from source file' can add thousands of additional calls to fileperms. I did successfully use this option for a galley with 60,000 files (approx 20,000 pics) in testing - and it worked... but I would recommend only using this option in testing what works for you - and then specify the result you want with the 'Use specified' option - or setting Coppermines defaults.

 

The following fields customize the behavior of copy/replace for the File Merge (only supported for local filesystems)

  • Copy unmatched language files? - (Default No)
    The lang folder is compared to identify any language files in the source that are not in the target. These will be reported. You can choose to optionally copy these files over to the target.
    No files will be replaced - only missing files added. Addition to the language table (if needed) is not handled automatically in this release. As it appears from my older galleries that language files have been dropped over time, I set the default to no... Review output, and determinethe correct action for your gallery.
  • Copy unmatched plugin folders? - (Default Yes)
    The plugins folder is compared to identify any plugins existing in the source folder that don't exist in the target. This does NOT indicate if the plugin is installed (that is handled in database merge.) These will be reported. You can choose to optionally copy these folders over to the target.
    Copy is for complete folders only where the folder doesn't exist in the target. Matching folders will NOT be merged.
    No folders will be replaced - only missing folders (and the files/folders it contains) will be added.
  • Copy unmatched theme folders? - (Default Yes)
    The themes folder is compared to identify any themes existing in the source folder that don't exist in the target. These will be reported. You can choose to optionally copy these folders over to the target.
    Copy is for complete folders only where the folder doesn't exist in the target. Matching folders will NOT be merged.
    No folders will be replaced - only missing folders (and the files/folders it contains) will be added.
  • Replace existing picture files? - (Default No)
    Action to take is the same picture file exists at the same filepath location (after applying any add/remove folder criteria. Simultation will report the conflicts found to help you determine the correct setting.

 

The following fields control checkpointing and termination. The simulate and execution processes are restartable allowing the merge to be done in pieces to fit within memory and cpu limits of your ISP.

  • DB Checkpoint Frequency: How often to take a checkpoint that can be used for restarting the process. Checkpoints will be taken after each table completes processing, and at the specified frequency while processing a table. Typically only invoked with cpg_pictures, as that will easily have thousands of entries.. but applies to all.
  • DB Quiesce Threshold: Maximum number of inserts allowed in a single execution to address any memory or cpu time limits. Upon reaching threshold, a checkpoint will be taken, and processing quiesced. Restart will be an option to continue. In my webservers configuration, I found about 20,000 inserts as the maximum threshold I could run. The default of 10,000 should be a safe number, but adjust up/down as needed. (Out of memory or time will likely present as a blank screen displayed after a short period of time...)
  • FILE Quiesce Threshold: Maximum number of file copies allowed in a single execution to address any memory or cpu time limits. Upon reaching threshold, a checkpoint will be taken, and processing quiesced. Restart will be an option to continue. In my webservers configuration, I found my connection timed out with 60,000 copies. The default of 30,000 should be a safe number, but adjust up/down as needed. Remember each picture can have at least thumbnail, normal, and fullsize file (and others) based on options - so the number fo files quickly grows. (Out of time will likely present a server/gateway timeout screen...)

 

The following fields control messaging. All status, information, warning, and error messages are supported in language files. Debug trace messages are in English.

  • Set Message level:
    • Summary - provides messages only for conflits, and totals inserted and existed for each table.
    • Detail - adds messages for inserted records (except pictures - due to expected table size).
  • Set Debug mode: Provide additional diagnostic information - for problems or to better understand what is happening
    • None - obviously none
    • Summary - code flow trace with start/end for major sections
    • SQL - adds generated SQL calls for INSERTs and UPDATEs only
      (CPG debug will show all executed calls if enabled - but won't contain calls for 'simulation' runs)
    • Detail - adds mapping (build and translate) and subroutine messages

 

The following fields control memory usage.
For very large galleries - memory usage may become an issue - primarily in processing the pictures table (typically largest table). For comparing source to target, the target table is loaded into an array which facilitates detecting and comparing duplicates, and feeding the mapping process. (Mapping already only maps those pictures referenced in other tables to reduce memory.)
Optionally, the fields loaded can be reduced to only the key and comparison fields. This will reduce the detail provided for duplicate entries. (Restart of execution other than from Quiesce can generate duplicate warnings even if gallery has none...)
Only configurable for pictures table - should be the only one large enough to be of concern (>20,000)

  • Reduce memory used for pictures:
    • Unchecked - provides full comparison of source/target rows for duplicates.
    • Checked - Provides only limited comparison information for duplicates - but uses less memory.

Once submitted, validated, your settings will be saved, and the configuration screen redisplayed with results and eligible actions will become selectable.

 

Execution:

Options will be enabled below the configuration settings as they are applicable.
Configuration must be submitted first to enable Simulate options. Simulation must complete to enable Execution options.

 

DOCUMENTATION:

  • View Readme Doc
    Displays this file.. :)
  • View Plugin Doc
    Gallery Merge is designed to allow support to be added to accomodate tables added by other plugins
    View this doc for details on the interface.
  • View Plugin List
    Displays the list of Plugins that have been defined to Gallery Merge and/or are supported by the merge process.

 

FILES:

  • Simulate Gallery File Merge
    Will perform all actions except actual updates to show what will happen when merged. Please review the output carefully and insure any conflicts are acceptable to you. Simulate can be re-run as often as necessary.
    Required to run anytime the configuration changes before allowing Execute option.
  • Execute Gallery File Merge
    Enabled after a successful simulation of current config, and performs file merge
  • Execute RESTART Gallery File Merge
    Will only be selectable if the last execution started, took checkpoints, and didn't end successfully (quiesce or aborted) Resumes processing loading checkpoint data, and continuing from last checkpoint..
    * In case of abort (any termination other than quiesce) - it is possible the restart will show some items as already existing in the target gallery - as we didn't stop right at a checkpoint... The messages are correct - as the last execution already added these items. This is normal, and will not cause an issue.

 

DATABASE:

  • Simulate Gallery DB Merge
    Will perform all actions except actual updates to show what will happen when merged. Please review the output carefully and insure any conflicts are acceptable to you. Simulate can be re-run as often as necessary.
    Required to run anytime the configuration changes before allowing Execute option.
  • Simulate RESTART Gallery DB Merge
    Will only be selectable if the last simulation started, took checkpoints, and didn't end successfully (quiesce or aborted) Resumes processing loading checkpoint data, and continuing from last checkpoint..
For the EXECUTION options, it is recommended the gallery be offline (admin maintenance setting) - or in other ways be prevented from updates being made to the tables...
  • Execute Gallery DB Merge - recommend gallery be offline (admin maintenance setting) for this process - through merge completion (or backout)...
    Enabled after a successful simulation of current config, and performs database merge
  • Execute RESTART Gallery DB Merge
    Will only be selectable if the last execution started, took checkpoints, and didn't end successfully (quiesce or aborted) Resumes processing loading checkpoint data, and continuing from last checkpoint.. * In case of abort (any termination other than quiesce) - it is possible the restart will show some items as already existing in the target gallery - as we didn't stop right at a checkpoint... The messages are correct - as the last execution already added these items. This is normal, and will not cause an issue.
  • Simulate BACKOUT Gallery DB Merge
    Will only be selectable after an execution has been started and took checkpoints - whether it completed normally or not. The last execution can be 'backed out' - restoring the updated tables to their original state. Validates the information required for backout.
  • Execute BACKOUT Gallery DB Merge
    Will only be selectable after an execution has been started and took checkpoints - whether it completed normally or not. A simulation must also occur first.
    The last execution can be 'backed out' - restoring the updated tables to their original state.
    Gallery will be set OFFLINE (if not already) during restore as core tables will be emptied/restored.
    Gallery will be returned to its initial status (offline/online) at successful completion.
    *BE AWARE* - if the gallery has been updated since the execution by picture adds, comments, votes - this data will be lost with the recovery.
    *BE AWARE* - while I am providing a backup/restore capability, you are advised to take a proper backup of your gallery before running the merge. The integrity and ability to restore your gallery in the event of a problem is yours.

 

UTILITIES: Some additonal views/tests you may find useful...

  • View Execution Summary
    reads restart table and provides one line per initial execution of a merge simulation or execution. (all data from any subsequent restarts or backouts would be included in the single entry.) You can select any desired entry for more detail (described next)
  • View Execution Detail
    Provides all available data from restart table and log files for a given execution. You can specify a timestamp here - or use 'View Execution Summary' to list, and choose from there. Data includes:
    • Ability to view message log from an execution of db or file merge (not saved for simulations)
    • Each checkpoint taken, and link to view detailed checkpoint data that was captured.
      • Initiated - includes the plugin's setting that were in effect for this execution
      • Started - includes the parameters passed to the 'process table' function
      • Inserted - includes the current mapping array to this point - (enables restart mid-process)
      • Quiesce - includes the curreny mapping array at the point we hit processing limit - (enables restart mid-process)
      • Complete - includes the completed mapping array created for future inserts
    • List of any backups available for this execution (backups not taken for simulation)
    • Ability to view log of generated sql executed for this merge (not saved for simulation)
    • Ability to view debug data from this execution (not saved for simulation)
    As you can see the data is quite extensive - in case there are issues to figure out what went wrong. (Or even something as simple as your merge execution timed out replying to you - you can still go see what actually happened as the script continued running.)
  • Post Gallery Merge Compare
    The gallery compares used in simulation and execution are coded with assumption that not all files/folders/ database entires in source will exist in the target... Following a merge - we expect them all to be there. A compare that is more efficient in this scenario is provided here. It will only compare files if file merge was completed - and only compare database tables if a database merge was completed.
  • Test Permissions
    Will create directories and copy files based on the possible configuration options in config.
    New folders will be created in your albums directory with each method:
    • 'gallery_merge_default_perms' using default (inherited) permissions
    • 'gallery_merge_source_perms' using permissions from your albums directory
    • 'gallery_merge_specified_perms' using specified permissions from 'use specified' text box of config
    Your last loaded thumbnail photo will then be copied into each of these folders using their respective method for setting file permissions. Review the results of these creations/copies and decide which option is best for you. The test folders/files created can be deleted at anytime - and the test copy re-run.
  • Set Gallery Offline
    Updates Coppermines config database to set gallery offline - Only selectable if gallery is online.
  • Set Gallery Online
    Updates Coppermines config database to set gallery online - Only selectable if gallery is offline.

 

The following allow for resetting maintained timestamps for File and DB simulations and executions. These functions should not normally be needed. Be aware that any eligible Restarts and Backouts (DB only) will NOT be possible thru the dialogs after the Reset action.

  • RESET File Restart Flags
    Clear all timestamp fields maintained for executions of phases.
    NOTE: automated restarts will not be possible if these flags are cleared.
  • RESET DB Restart Flags
    Clear all timestamp fields maintained for executions of phases.
    NOTE: automated restarts and backouts will not be possible if these flags are cleared.

 

There is support for a 'bypass' function in the event specific steps need to be skipped - without changing mainline code. This is not supported by the plugin configuration menu - and is not intended to be used unless you REALLY understand what you are doing...
Review data/bypass_data.php for details on how to specify.

 

Support for Merging Other Plugins Data:

There is one more piece of doc... If you want to add knowledge or support of other plugins and their impact on Gallery Merge. Click the link below to 'View Plugin Doc' if viewing this through CPG, or navigate to 'readme_plugin_support.php'.

 

Congratulations if you made it through all of this! And good luck merging galleries!!
Your comments are welcome.
I hope you find this useful.
Greg (gmc on the CPG forum)