Making "staging" sites easier to copy to "live" servers!
What is it?
EasyStaging is a Joomla! 2.5.4+ and Joomla 3.3+ component that simplifies the process of copying changes from a private "staging" version of a website to a "live" or public webserver.
- Creating a Plan
How does it work?
EasyStaging works by copying your website from a "staging" location to a "live" location.
EasyStaging uses two basic mechanisms to perform the copy.
- File copy using rsync to the "live" site.
- MySQL table exports to the dababase of the "live" site.
EasyStaging "copies" the changed files from your "staging" location to the "live" location using a process called rsync.
You can read about rsync here.
EasyStaging allows you to specify which files/directories are excluded from the copy process. The default settings don't copy the staging sites configuration.php file, cache, tmp or log directories.
EasyStaging will copy tables from your local "staging" websites to the remote "live" websites database. (By default EasyStaging will not copy the #__session table to prevent users from being disconnected.)
EasyStaging works around the concept of "Plans". Each Plan can be configured to copy specific tables from the staging database, specific directories or a combination of both to the "live" website.
Plans can also be restrcted so that a user can only "run" a Plan in a specific Joomla! group. This could be handy if a website author needs to push new PDF's or images to your live website but you don't want anything else transferred, you can create a plan just for that user that copies just their directory of files and nothing else.
Who should use it?
EasyStaging is meant to make the life of website developers or other suitable technically skilled people easier. If nothing you've read so far is unfamiliar then its probably a good idea to read further. If EasyStaging doesn't sound dangerous to you then you should probably stop reading and find another product.
In the right hands EasyStaging can be a powerful and time saving tool, but in the wrong hands a badly configured staging Plan could wipe out your live website.
Apart from the requirements listed in the table below, the Apache user the runs PHP on your staging website should be configured to allow
proc_close() calls. The Apache user should also be allowed to run
at, i.e. it should not be in the at.deny file.
Warning - never install EasyStaging on a publicly accessible website. EasyStaging is only meant to be installed on private development/staging servers that don't have public access.
EasyStaging is installed like any standard Joomla! component, using the Extension Manager. You have the choice of downloading the latest version or, if you're registered and logged in, by copying the Direct Link.
Navigate to Extensions->Extension Manager->Install
Choose the latest version of EasyStaging and click the "Upload & Install" button.
Alternatively, you can paste the Direct Link you copied previously into the Install from URL field.
After the installation you will see a message similar to this one if it was successful:
To use EasyStaging select Components->EasyStaging and you will be presented the EasyStaging Manager as shown below:
The Manager has all of the standard Joomla! button for managing staging plans. The standard Plan buttons include the "New", "Edit", "Publish", "Unpublish" and of course "Delete".
Finally the Manager has a standard Options button for various EasyStaging configuration options. There are three tabs in the Options screen, the first allows you to set preferences for the way EasyStaging handles data and the second tab allows you to use Joomla's standard permission model to control who can access the component and create, edit or run plans. The third tab called "Advanced" isn't currently used.
Max. Data per Step — The maximum amount of data (in Kb) that should be in any single SQL export step. (A table bigger than this will be processed in several steps.) EasyStaging asks the target database what is the largest amount of data that will be accepted and then automatically adjusts it the data export fit, however if this setting is lower it will be used instead.
Status Check Interval — The interval, in seconds, between checking with the server on the status on the currently running plan. Once a Plan is running the browser will periodically ask for a status update on the place, if you prefer more frequent updates you can lower this number, of for less updates you can increase this number.
Default Table Action — The default action that table will be set to when creating a new plan.
Added Table Action — The table action that will be set when new tables are found that don't currently exist in the plan. As your site grows you may add new extensions which create new tables in your Joomla database, when these
are detected their action will be set to this value. You will be notified when new tables are found and can adjust them as necessary prior to saving the Plan with the new tables added.
The Advanced tab is used to define where the PHP binary is that will be used to run the background Plan Runner. When you install EasyStaging it will try and set this for you, unless you're on Windows and running a version of PHP below 5.4.0.
Important: If you are running on a Windows based computer you must check the path to your PHP binary and make sure it is set in this Advanced tab.
PID Search Timeout is not used in this version of EasyStaging.
Once you've added a few Plans the EasyStaging Manager will look more like this:
What is a Plan?
In EasyStaging terminology a plan is a group of settings that are used to control the two core actions that EasyStaging performs.
- copy new files (images, PDF, PHP etc) from the current server to a "live" or second location
- copy database tables from the current server to a "live" or second location
Anyone that has the permissions set by the Super user can create a Plan - so be very careful who you give these permissions to. In most cases only the Super user will need to create new Plans, as the most common use of EasyStaging is not creating Plans but running them.
So, a Plan provides a mechanism to define which directories are copied from you Staging website locaion to your Live website location and through the use of rsync options and exclusion patterns you can define which files/directories are excluded from the synch process. Similarly EasyStaging Plans provide an interface that lets you specify which and under what conditions tables are copied from the Staging database to the Live database.
As a point of note EasyStaging doesn't copy itself or any traces of itself to the Live site.
How do I run a Plan?
To "run" a Plan you need that permission given to your Joomla! user, EasyStaging works with the Joomla! 1.7/2.5 ACL so that you can give a user or user group just that permission. A user with only "Run" permission can't create, edit, delete or publish/unpublish a Plan, they can simply run plans. Thanks to the flexibility of Joomla!'s ACL you can even create a Plan that can be run by only a single user, and that user is in turn restricted to just that single Plan.
Step 1. Select "EasyStaging" from the Components menu. It looks like this:
This takes you to the EasyStaging Manager screen, shown below.
As you can see, each Plan has a description to tell you what it does. In this case the Super user has setup the "Publish Aritcles" Plan to copy Articles, Categories and Front Page settings (ie. database tables that hold this information) as well as synchronise the /images directory at the staging and live locations.
For the "Publish Site" Plan the Super user has created a plan to copy the entire site ie. all the files and all the database tables to the live location.
Step 2. Select the Plan you want to run by clicking it name in the EasyStaging Manager. In the example screen shown below (click to enlarge) there are two Plans available - "Publish Articles" and "Publish Site".
Step 3. If you only have "Run" permissions you will see the Plan details shown below.
The Plan view shown with "Run" only permission shows the basic details of the Plan and a single TAB called "Staus" with 3 buttons. The first two buttons ( 1 & 2 ) start a specific part of the Plan while the third button ( 3 ) runs the entire plan. Clicking on any of these buttons will start the relevant section of the Plan runnng to run both the file copy and then the database copy use the green button (3).
Once a stage start executing the "Waiting..." text will be updated with the progress log, until the run completes.
IMPORTANT: From version 1.1.0 onwards once a Plan is started it will continue to run even if your internet connection drops out or you close your browser window.
Start File Actions : As the label states this button will start only the file synchronisation, once it's completed nothing else will happen. This can be handy if you're just replacing media on the live site without making any other changes as it is much quicker than the replication of database tables. In the example "Publish Articles" Plan this will copy the files in the /images directory.
Start Database Actions : As you would expect this button will perform just the database copy section of the current Plan, no files (PDF's, images etc) will be copied during this step. In the example "Publish Articles" Plan this will copy only those tables specified by the Plan creator in the "Tables" tab.
Run All Actions : As you would expect this button will perform both the file copy and the database copy section of the current Plan. In the example "Publish Articles" Plan this will copy the files in the /images directory and then copy only those tables specified by the Plan creator in the "Tables" tab.
Clicking on any of these buttons will make the Plan present a confirmation prompt, to make sure you really want to proceed. In Google's Chrome it looks this:
What happens when a Plan runs?
The process that EasyStaging follows after you click one of the buttons is relatively simple, and proceeds as follows:
- Checks in with the server.
- The server checks the user has permission and that the current user session is valid by Joomla! standards.
- The server creates a "RunTicket" to which any action steps are attached.
- The steps are for the selected action(s) are created and the server attempts to start the PlanRunner in the background.
- The server reports it's status back to the browser.
- If the sever responds that all is OK
- the browser updates the Plans current status (so you can see that all is good so far) and then
- the browser waits for the "Status Check Interval" to expire and then requests an update from the server
- the server looks for any unreported progress on this RunTicket and sends the results to browser.
- If the Plan is still running, it goes to step 2A.
- If you clicked the "Start File Actions" button each of the Plan's rsync steps (i.e. the rsync commands) are created for the PlanRunner.
- If you clicked the "Start Database Actions" button each of the table actions are created for the PlanRunner.
- If you clicked the "Copy All" button
- Step 3 is run.
- If no errors occur then
- Step 4 is run.
- Once the PlanRunner starts
- It attempts to execute all of the steps in sequence, starting with File Actions followed by Database Actions.
- As each step makes progress it's results are recorded.
- If a serious error occurs the Plan will be stopped.
- If it completes successfully all the log and SQL export files are ZIP'ed up into an archive for later if required.
- the Plan's status and last run information is updated in the database.
Visually you will see several things happening while a Plan is running. After you've confirmed that you want the Plan to run EasyStaging will start providing feedback details like:
- what stage its at
- how long since the last server response
- any details the server sends back about each step.
Each Plan has several basic attributes including:
- Published States
Ideally a Plan should have a name indicative of it's purpose. In our examples we have two Plans, the first is called "Publish Site" which copies the entire staging site ( files and database tables ) to the live site location. The "Publish Articles" Plan by comparison only copies the contents of the /images directory ( Joomla!'s default location for storing user generated content such as PDF, photo's etc ) and the required tables from database, rather than all of the tables.
The description is primarily used to provide a quick explanation of the Plan's function to users viewing the list of Plans in the EasyStaging Manager.
A Plan can be either Published or Unpublished. In addition you can also specify "Publish Up" and "Publish Down" dates to set a time span during which the Plan can be used.
The "Basics" pane contain basic information commonly found with most Joomla content, including information about who and when a Plan was created, Start and Stop Publishing dates and who was the last person to modify the Plan.
Through out EasyStaging you will find helpful tooltips about each field and button, but sometimes you need to see them together. So, most of the actions you can perform on database tables and files are described in this Pane. Click the disclosure triangle to read them.
To complete a Plan prior to running it you must configure the details and settings in the "Local Site Details", "Remote Site Details" and the "Table Settings" tabs. When you initally create a new Plan the first tab you see will be that "Status" tab as shown below.
Each of these tabs are discussed below including a description of each field or setting available to configure the Plan.
Once the details of the have been configured to your requirements you can "Save" it ready for use.
The "Status" tab contains the Plans "Run" controls and the details of the last time the it was run.
The process of running a Plan is covered in the Plans tab.
The "Local Site Details" tab contains the details to be used as the source or local site from which files and database tables are copied. The initial values that appear in this TAB are copied from the Joomla! configuration file of the staging site and may only need minor tweaking.
The "Site Name" and "Site URL" fields are used in the feedback and logging process to help make it clear to you what each stage is doing.
The "Site Root Directory" is the path to the root directory that your Joomla! site is installed in. It will be used as the base path for the rsync commands created for each of the File Copy Actions for copying/moving files from the local or "Staging" site to the remote/Live site. In the screen capture the path is to the example root directory of the website, your website root will be different.
The "Table Prefix" is used to process the names of the tables in the database and convert them to the correct name on the remote server, of course, your prefix will be different for each site you build. Specifying the prefix allows a different prefix to be used on the staging and live sites.
The "Rsync Options" field should probably be left as the default values unless you are very confident in your understanding of rsync options.
The "File Exclusions" field allows you to set patterns that will be excluded from and rsync operation. EasyStaging will not copy itself, log/ ,cache/ , tmp/ or any .htaccess or Joomla!'s configuration.php file.
To be precise the content of the "File Exclusions" field is appended to these predefined exclusions:
The "Remote Site Details" contains the details to be used for the live site (the destination we are copying files and database tables to).
You can see in the screen shot below the Remote Site Details that are required.
The value in the "Remote Site Directory" field can be any valid rsync structure (
[USER@]HOST[:PORT]/SRC) that points to the root directory of the live websites Joomla installation. This will be combined with the File Copy Action "Target Directory" to build the path used by the rsync command.
The Database Name, User and Password fields are used in conjunction with the "Database Host" field to remotely access the "Live" websites database. The remote database must also be setup to allow remote connections from the IP Address of the "Staging" site that the EasyStaging component is running on.
The "Table Prefix" field is used to convert the names of the local database tables to the correct naming convention for the live site. When used with the "Table Prefix" field from the "Local Site Details" tab EasyStaging can easily swap the prefix out for test and creation of the export SQL.
The "Table Settings" tab contains details of each of the tables in the Database and how they will be treated when a plan is run. Apart from "Skip" this Table", the "Action" that can be applied to a table can be one of the three types available, Push, Pull or Pull then Push. In total there are six table actions available (there were only the three basic action in 1.0.0).
If you look at the screenshot above you will notice that only four tables are visible, which is much more manageable than the 80 tables in this website. From version 1.1.0 when a Plan is opened in its editor any table that is not skipped will be shown by default, all skipped tables are hidden.
To find tables there are several options available to you:
- type three or more letters of the tables name into the filter input box to start realtime filtering by the tables name.
- Click the Filter's blue disclosure triangle to reveal predefined filters for:
- ALL Tables
- Skipped (tables that aren't being actioned)
- Not Skipped (tables that are being actioned)
- Pushed (tables that are being copied to live)
- Pull then Push (tables that are being merged back from live before being copied to live)
- Pulled (tables that are being copied back from live)
For each table in the Staging websites database you can either ignore the table or perform a push, pull then push or push action. Each of these actions are described below.
Skip this Table
No actions will taken on this table, it is ignored by the plan.
Copy To Live
The entire table is copied to the 'Live' server completely replacing the equivalent table.
Copy To Live, Only if not found.
The entire table is copied to the 'Live' server, only if it doesn't already exists. This action should be used for tables that store transitory site specific data, like Joomla's #__session table.
This last option is useful for table like Joomla!'s #_session table. Joomla! needs this table to work but the records in it relate to the user session on the actual site. To copy the session data from the staging site to the live site could potentially delete a users sessions and result in site issue for the end user. When you initially create a Plan the #_session table is automatically set to "Copy To Live, Only if not found" to prevent this very issue.
Pull then Push Actions
Copy To Live, After Merge From Live
The matching table on the 'Live' server is copied back to the local/staging server and merged with the local table before the table is copied back to the live server. This action is useful for tables that have content updated on the live server.
Copy From Live (merges with existing)
The matching table on the 'Live' server is copied back to the local/staging server and merged with the local table. It is NOT copied back to the live server after the merge. This action is useful for tables created by form extensions that collect responses from users of the live website.
Move From Live (merges with existing)
The matching table on the 'Live' server is copied back to the local/staging server and merged with the local table. The records are then removed from the live server. This action is useful for tables created by form extensions that collect responses from users of the live website.
Replace With Live (REPLACES existing with remote)
The matching table on the 'Live' server is copied back to the local/staging server and REPLACES the local table. The local records are completely deleted and replaced by this action.
File Copy Actions (Rsyncs)
The file syncing process is completely different so you will need to:
- change your old 1.0.0 directory settings so they point to your staging and live website root directories
- create new File Copy Actions (FCA) to replace your original settings.
When you first create a Plan the table will show one empty FCA, when you provide a label, source directory and a target directory and "Save" the Plan, your FCA will saved and a new empty FCA will appear below it.
The FCA table is new in version 1.1.0 and greatly expands the file actions available in several ways:
- a Plan can now have several FCA's in place of the original "Copy TO Remote" action.
- a "Copy FROM Remote" action has been added
- a "MOVE FROM Remote" action has been added
rsync is a program that uses the rsync remote-update protocol to greatly speed up file transfers.
EasyStaging uses the concept of a local and remote sites to refer to your Staging and Live sites respectively. When you setup your local and remote sites rsync details you are specifying the path to the root directory in which Joomla! is installed on your server.
These root paths are combined with the Direction, Source and Target Directory for each File Copy Action, to control the movement of files between your servers. You can have multiple File Copy Actions but, be aware that if you're not careful they could overlap each other and your initial copies may be overwritten or changed by subsequent copies.
The fields used in EasyStaging map to the options that can be passed to the rsync program. To find out more open your terminal and use the man rsync command to find out more about rsync on your machine. Alternatively you can read about rsync here, or at the online rsync man page.
Copy TO Remote:
Copies the files from the directory in the Local site, specified by 'Source Directory' TO the remote site.
Copy FROM Remote:
Copies the files from the directory specified in 'Source Directory' FROM the remote site, to the directory specified by 'Target Directory' on your Local site.
MOVE FROM Remote:
MOVES the files from the directory specified in 'Source Directory' FROM the remote site, to the directory specified by 'Target Directory' on your Local site. Once the files are moved to the local server, they are PERMANTLY DELETED from the live server.
The path to the directory or a sub-directory (eg. if you want /images/stories) files will be copied TO.
The path to the directory or a sub-directory to copy files FROM.
*Remeber these paths are from the root directory of the relevant sites.
Copying the Entire Sites Files
First of all there are certain things that EasyStaging is hard-wired not to copy, like any of it's own files (or tables) and in particular the
Prior to the 1.1.0 series you could simply specify the website root directories in the "Local" and "Remote" site details tabs and run the file copy.
For a whole site copy post 1.1.0 series you need to do things a little differently.
First of, in plans where you're copying specific folder all you would nomally define you Local and Remote site root directories with a trailing slash "/" e.g.
Normal Plan Local Site Root:
/path/to/local/domain.com/ or on a real development machin it may look like this
While the Remote Site Root may look like
For a "whole site" file copy you need to remove the trailing slash on both the local and remote sites root directory settings. So, using the examples above you end up with:
Local Site Root:
Remote Site Root:
Then you will need one file action with a source and target directory set to a single slash "/" as shown below:
1.2.2 Release Thursday, 12 January 2016 1530
- 1.2.2 Additions
- Add a check to ensure path to PHP executable is set
- Add Last Modified info to Plans List view in Mgr
- Add last_run_by column to plans table.
- Add last_run_by info to Plans Mgr view.
- Add missing language string for J3 Global Options menu.
- Add package manifest for Pro builds
- 1.2.2 Changes
- Change - Remove /administrator from default site root directory value we insert
- Change - Replace hardcoded version details with build tokens.
- Change - Update the last_run_by when not a dry-run.
- 1.2.2 Fixes
- Fix broken language string for Background Timeout.
- Fix broken language strings in configuration XML.
- Fix plugin build file name
- Fix SQL error from dry_run property
- Fix strict 'undefined' error.
- 1.2.2 Miscellaneous
- Misc - Basic code style clean up
- Misc - Change - Don't set the local database details
- Misc - Initial build file.
- Misc - Initial version
- Misc - Restructure directories.
1.2.1 Release Monday, 26 May 2014 1830
- 1.2.1 Changes
- Change Plan run message in Plan view to local time not UTC.
- Remove unnecessary width limitation on #lastRunStatus div.
- 1.2.1 Fixes
- Fix JVTag to work on both PHP 5.3 and 5.4, not just 5.4… doh.
- Fix silent failure of Rsync Test button when plan is unpublished.
- Fix table filter message appearing for RunOnly users.
1.2.0 Release Friday, 23 May 2014 0830
- 1.2.0 Additions
- Add Joomal 3.3+ support.
- Add more robust Database Conection test.
- Add 'WARNING' class to warning messages.
- Add <br>'s to output for strings that no longer have them in language file.
- Add a general helper to getJoomlaVersionTag().
- Add ability to append system messages rather than over writting.
- Add dummy SQL to set schema to the right version number.
- Add J3 style icon to EasyStaging Manager title.
- Add J3 Templates
- Add Joomla 3 support for Plan screen.
- Add tooltip to Plan link in Plan Manager.
- 1.2.0 Changes
- Change install script to move version specific /cli script.
- Change tooltip language file keys to end with _TT
- Exclude testing buttons for RunOnly users.
- Improve new tables found message by removing repeated sentence fragment.
- Move 'How it Works' to sub-tmpl.
- Move end of line breaks out of translatable strings.
- Move Run layout to version specific naming.
- Move tmpl to version specific naming.
- Remove temporary variables.
- Remove unused CSS selector that will conflict with J3
- Remove unused help button from toolbar.
- Rename /cli script due to unavoidable difference in Joomla Framework versions (aka Platform).
- Replace deprecated JUtility::getToken() call.
- Replace JPackageManifest call getXML call which didn't disappear from the J3 classes.
- Report uncaught step failure in CLI
- Simplify getJoomlaVersionTag() method.
- Sort Language file.
- Use Legacy naming convention.
- 1.2.0 Fixes
- Fix 'strict' warning for function signature.
- Fix "strict" warnings causing plan reporting to fail.
- Fix Action buttons not working because of string to number comparisons after "use strict"
- Fix cases where "Plan must be saved" warnings are immediately overwritten by filter messages.
- Fix column widths etc.
- Fix disable state for Plan Action buttons.
- Fix duplicate DOM name for "Test Rsync" button.
- Fix duplicate ID's in table filter buttons.
- Fix formatting of Plans list on mobile devices.
- Fix missing link for Plans that user can RunOnly.
- Fix more JSHint issues.
- Fix php file flag setting being ignored. Simplify by using standard Yes/No values in form.
- Fix quoting issues.
- Fix RunOnly Access check for Plan view.
- Fix small jump in Filters box and reveal of buttons.
- Fix table actions filter broken by "use strict"
- Fix table name filter not showing all tables when cleared of text.
- Fix tables not copying on initial plan run if remote database has no tables.
- Fix tmpl's not loading.
- Fix typo in language key.
1.1.4 Release Monday, 31 March 2014 1351
- 1.1.4 Additions
- Add 'onError' handler for transient server issues.
- Add error suppression work around for SiteGround servers that throw a warning when JAppicationCLI tries to __destruct() a non-existent JSession when exiting.
- Add removal of script time_limit to help with large plans.
- Add workaround for Hive servers that aren't returning results from exec().
- 1.1.4 Changes
- Move file and rsync methods to runHelper.
- 1.1.4 Fixes
- Fix default port to check for remote DB to MySQL 3306.
- Fix missing sprintf parameter for logging of steps that could cause some servers to abort the CLI.
- Fix stupid status bug in contactHost() when response is really quick, sub 1ms.
1.1.3 Release Monday, 9 December 2013 1948
- 1.1.3 Additions
- Added additional setting for remote host in preparation for 1.3 and connection testing.
- Add Database connection and File Copy Action testing.
- 1.1.3 Fixes
- Fix excessive blank lines in logs.
- Fix 'Undefined variable' warning on Checked-out plans.
- Fix layout of filter box in tables tab.
- Fix strict error under PHP5.4
1.1.2 Release Friday, 6 September 2013 2206
- 1.1.2 Fixes
- Add missing "Steps" table to update SQL files.
- Re-add 1.1.0 update SQL due to missing ; in first statement causing update to fail.
1.1.1 Release Tuesday, 3 September 2013 2030
- 1.1.1 Additions
- Add a more robust method of getting our RunTicket argument (helpful when 'at' is badly setup).
- Add an option to capture any PHP output from PlanRunner when launched by AT (handy if you don't have enough RAM allocated to PHP).
- Add check for a runticket (as well as a runDirectory) when write out to the log file.
- Add CLI files and System language file to exclusions.
- Add EasyStaging's /media directory to default exclusions (apparently some odd distros of rsync are broken).
- Add extra details in feedback from calling '_runScriptInBackground()' (useful for finding out when you're in the 'at.deny' file)
- Add logging to _runScriptInBackground() if JDEBUG is true (handy when your host has no idea, again why are you running on a hosting service?).
- Add missing strings for plan runner launching.
- Add option to execute Plan Runner via AT or directly through shell_exec()
- Add params for PHP switches -q 'quiet' and -f 'file' (handy for some broken CentOS PHP combinations).
- 1.1.1 Changes
- Change installer script "update from x to y" string to JText.
- Change message response to provide more details about what was launched and how.
- Change PlanRunner output to a global function '_write_pr_log()' for those cases where everything goes wrong.
- Change script to be consistent with config.xml value.
- Change version meta for 1.1.1 Release.
- 1.1.1 Fixes
- Fix launch message for 'AT' so the job number is returned. (Handy when you find an AT queue with hundreds of other jobs stalled in it.)
- Fix sequence of version in Minimum PHP error message.
- Fix timer still running after 'runEnded()' called in some situations.
- Fix undefined strict error when updating but `path_to_php` is set.
- Fix undefined variable error — whoops.
- Remove $_SERVER check for those people that won't listen, this is only helpful for those that insist on runing EasyStaging on a hosting service — get a VM people!
- White space.
1.1.0 Release Sunday, 18 August 2013 14:30
- 1.1.0 Additions
- Add `#__easystaging_rsyncs` to uninstall SQL.
- Add missing "from" to cli cleanup message.
- Add removal of plan runner file from /cli to uninstall().
- Add setting of the path to the PHP binary in the postflight of the install script.
- 1.1.0 Changes
- Change plan.json to use the path to the PHP binary as defined in component params.
- Change uninstall message.
- 1.1.0 Fixes
- Fixed typo in rsync description.
- Fix JS in `plan.js` from left-over morphing line.
- Fix undefined property in uninstall() method.
1.1.0RC2 Released Monday, 05 August 2013 10:00
- 1.1.0RC2 Additions
- Add Checked_out status to Plans view.
- Add missing 'when' to description text for 'Default Table Added Action' in Preferences.
- Add relative date information to last run message in Plans view.
- Add Check-in strings for Plans.
- 1.1.0RC2 Changes
- Change password fields to password types.
- Change PHP minimum to 5.3.10
- Change state to default to "Not Published" for new Plans.
- 1.1.0RC2 Fixes
- Fix display of Plan Description for RunOnly users.
- Fix JS error for new Plans that are "published" but aren't actually saved yet.
- Fix JS error in Joomla.submit() for RunOnly users when cancelling/closing the Plan.
- Fix JText key for PHP Version check.
- Fix the multiple message bars appearing when using the table filter buttons.
1.1.0RC1 Released Wednesday, 31 July 2013 15:07
- 1.1.0RC1 Additions
- Add — Use the Max Packet size setting from Preferences.
- Add '.DS_Store' to default exclusions.
- Add 'status' flag for situations where we encounter a serious error in a step.
- Add 'Table Copy Replace' to table action options.
- Add 'table-settings' class to table rows for the filtering JS.
- Add "Helpful Notes" to explain table actions and rsync usage.
- Add (move) getTokenSegment() from plan.js
- Add a check() method to the tables table so that merge actions only apply to tables with a Primary Key.
- Add a filterTableActions() call to the domready() to prefilter the table view to show those tables with actions by default.
- Add a global preference for default table actions on new plan or new tables for existing plan.
- Add a hide/show toggle to table filtering UI.
- Add a method to return the JTable of a specific step.
- Add a reference to password-less rsync to remote path tooltip.
- Add a utility function to add <br> tags to the end of each line of log text being sent back to the browser.
- Add a utility function to centralise logging and updating step details for the browser status updates.
- Add a utility method to gather profile data about the current steps table.
- Add addMessages() to allow additional messages to be displayed without clearing existing.
- Add advanced Global preferences tab.
- Add basic object and array comparison functions.
- Add basic structure to performTableMerge()
- Add basics of Steps table.
- Add CLI folder to manifest.
- Add copying of plan_runner to preflight method of install 'script.php'
- Add current version to #howitworks panel.
- Add descriptions for MOVE file action.
- Add detection of tables with invalid column names as determined by Joomla!
- Add DisableToolbarBtns() functionality. Hide secondary tabs (to disable access) during a plan run.
- Add docblock to getPlan().
- Add emptyTable() method for target table.
- Add filtering of tables by name.
- Add filtering to Tables tab.
- Add getPlan() to helper.
- Add helper for plan runs.
- Add helpers to build a profile a given table.
- Add Icon and CSS to experimental features testing button.
- Add in new AJAX scripts to support new plan runner mechanism.
- Add language strings for new global preferences.
- Add Lockout to the Plan run buttons if the plan isn't clean.
- Add logic to create and run new style fileCopyActions (rsyncs).
- Add method to check if a process $pid is running.
- Add method to return a file name for rsync output.
- Add method to run a script via shell. i.e. in background.
- Add methods to handle merging records back from remote table.
- Add missing blank index.html and gpl.txt
- Add missing installer strings.
- Add missing language keys for getTableProfile()
- Add missing scope and static declarations which break json output on 'strict' servers.
- Add new AJAX entry point and status response structure for launching Plan Runner.
- Add preference for AJAX check interval.
- Add progress reporting for steps.
- Add refresh() for long running jobs.
- Add Rsync function to PlanRunner.
- Add Rsyncs table.
- Add SQL update files.
- Add table filter for tables with an action (i.e. NOT skipped)
- Add the copy back action to action routing.
- Add UI and logic for adding and removing file actions (rsyncs).
- Add valid response for tables with no records.
- 1.1.0RC1 Changes
- Change — Alpha sort language files.
- Change — Dry exclusion file handling.
- Change — Rename createTableExportFile() to make function clearer in preparation for upcoming mergeTable export methods.
- Change — Rename function to be clearer about the export type.
- Change — Rename local and remote to 'source' and 'target' respectively, to reflect new actions.
- Change — Replace depreciated JRequest with JInput
- Change — Replace depreciated key_exists() call.
- Change — Replace with call to table->save()
- Change 'config.xml' to use JText keys.
- Change "Helpful Notes" layout to be clearer about table action types.
- Change "Plan Runner" message to include the `at` result via sprintf.
- Change `steps` table to size action column better.
- Change Action6 to "Replace" to make it clearer.
- Change appendTextToCurrentStatus() to allow caller to define the text between current status and new text.
- Change component version check in preflight to ignore the build/commit hash.
- Change copy of CLI file to a move.
- Change createTableExportFile() to use a supplied DB connection.
- Change creation of rsync step so JSON elements match naming of form.
- Change echo of error messages to JError's (echo's will not be seen).
- Change filter label to the right global JText token.
- Change isRunTicketValid() for the requirements of the Plan Runner.
- Change JText key names to match use.
- Change JText::sprintf strings to be tokenised for positional use in other languages.
- Change language strings and make keys more consistent.
- Change method name to make it clearer.
- Change report status to only report when a response is different from the previous one.
- Change runTableExport() to target supplied database connection.
- Change SwapDBs() into a swap Source and Target method.
- Change table export functions back to using the objects DB's by implementing a simple function to swap the source and target DB's for copy backs.
- Change the name filter to kick in after 3 or more characters are entered.
- Change to return scheduled message from `at` as we can't get the PID for an indeterminate amount of time.
- Improve format of CSS for easier readability.
- Improve structure of Action menu for tables.
- Improved structure of Action6 description.
- Make prefix swapping method more flexible for pull back table actions.
- Make version_compare calls operator style consistent.
- Migrate table functions to table actions in plan_runner.
- Move and update _get_run_directory() to RunHelper.
- Move background high-light colour to `payattention` CSS class.
- Move retrieval of plan_id and site objects to start of run and attach to this.
- Move table actiontype to a custom field.
- Remove left-over testing condition.
- Remove legacy functions.
- Remove old rsync methods.
- Remove references to "Pro" version from branding, headers etc.
- Remove unused method _rsync_output_file_name().
- Remove unused variables.
- Structure CSS in a more logical order.
- Update status checking mechanism.
- Wrap the planrunner run loop in a check for the odd condition where the plan's source and target sites couldn't be retreived.
- 1.1.0RC1 Fixes
- Fix — Prevent Un-published Plans from being run.
- Fix action_type switching in performTableMerge()
- Fix broken exclusion file for rsync call.
- Fix broken layout for "Unpublished" plans.
- Fix class name for Rsyncs table class.
- Fix docblock to hlep show correct type in IDE.
- Fix infinite loop in getPIDForName()...
- Fix issues with MySQL going away on some hosts in doMergeRecords().
- Fix JText tokens in install 'script.php'.
- Fix lockOutBtns() for dirty plans so that tabs are still available.
- Fix message reporting by refreshing the step object first.
- Fix object compare function.
- Fix occassional NaN messages in the table filtering methods.
- Fix passing of array instead of first element.
- Fix plan not finishing in edge cases where a plan only has 1 table but no export file is created.
- Fix quoting on SQL
- Fix quoting, remove escaping (WTF?)
- Fix response when plan runner couldn't be launched.
- Fix situations where an exclusion line is an inclusion (i.e. starts with a +)
- Fix SQL for create statement for Steps table.
- Fix Table copying stage string literal.
- Fix table name in export exposed by new copy back usage.
- Fix the counting of tables to process vs actually processed.
- Fix updating of filter message so that it occurs only after all rows are processed, not once per row.
1.0.0 Released Tuesday, 12 June 2012
- 1.0.0 Initial Release