Installation on WordPress 3.8 #14
Comments
|
I tried Lucasno's fork of this project, and it seemed to work out of the box on WP3.8.1, except for one tiny change: |
|
Ah ha...good find. I will see if I can get lucasno's changes pulled in and Thanks for your support
|
ghost
assigned
|
I was a bit premature in stating Lucanso's fork worked pretty much out of the box. I apologize for posting the issue here, but I don't see a place to do it on the fork's page. (The errors also affected this version.) It appears in 3.8 that the 'usermeta' table is not copied to each of the multisite/network installed blogs. Multisite websites can be snapshotted, but the deployment feature does not work. The database complains about a nonexistent "wp_X_usermeta" table in the temporary database. I was able to create the wp_X_usermeta table in the temporary database, then the deployment worked ... mostly (I'll get to that.) The main WP database is named "example" and the temporary database is named "deploymint_example." Once that had been done, the "Deploy Snapshot" feature worked, almost. In WP3.8, the blogs.dir directory has been eliminated. Instead, the "wp-content/uploads/sites/SITENUMBER/" structure is used, which can be worked around by a symbolic link or two from the WP install directory: After the symbolic links were put into place, it seemed to work. Note on the first symbolic link: it may just be my install, but apparently the first blog on a multisite/network install uses the typical wp-content path as normal (domain.com/wp-content/2014/01/blah.jpg), but each site in the network uses wp-content/uploads/sites/SITENUMBER/2014/01/blah.jpg path for storage. Err.. not "sitenumber," but $blogId I'll have to explain this a little better another way... I haven't spent a whole lot of time looking at the script; just enough to recognize potential path errors and webserver error logs. I will continue looking at it. As a note, removing the usermeta table from $wpTables did not work, as there is also a check in the getTablesToDeploy() function which quashes activity on the usermeta (and "user") tables... Sigh [Edit: I'm sorry for changing this report a lot, perhaps I'll just try a base install of Network/MultiSite, and see where files are stored for both the main site and the subsites.] |
|
After some testing, I've figured out that the main site's uploaded media is stored simply in year/month folders in wp-content. With the default install of 3.8.1 and only multisite enabled, media uploaded to the main site appeared elsewhere than media uploaded to the subsite. The main site's (blogId = 1) media upload path was: ~/public_html/wp-content/uploads/2014/01/blah.jpg The sub-site's media upload path was: ~/public_html/wp-content/uploads/sites/2/2014/01/blah2.jpg No more ~/public_html/wp-content/blogs.dir or ~/public_html/wp-content/uploads/sites/1/, unless symlinks are used. The paths for rsync and git should be looked at. If need be, try using symlinks to recreate the paths of 3.8.1 to the older version... |
|
Sorry for the blabbing. Okay, so I got lucanso's script working, as far as I can tell, in its entirety. (Snapshots and Deployments work flawlessly each and every time.) The first step was to prepare the multisite install for backward compatibility. This can take place either before any content or media is uploaded, or afterward. If the uploads/sites/ directory already exists because media has been uploaded, then remove that step from the process below: cd ~/public_html/wp-content
mkdir -p uploads/sites
ln -s uploads/sites/ blogs.dir
cd uploads/sites
ln -s ../ 1The second step, which has already been committed here: 01becff Then the third step, which was commenting a piece of code that tries to copy stuff to a sub-site's version of the usermeta table. I just quickly put an if-statement around the offending code to only execute if WP is in single-site mode. It doesn't seem like that would be the best course of action simply because in multisite deployments, I would think stuff can change in the usermeta table. Hmm... --- a/DeployMintAbstract.php
+++ b/DeployMintAbstract.php
@@ -1148,13 +1148,15 @@ abstract class DeployMintAbstract implements DeployMintInterface
if (mysql_error($dbh)) {
throw new Exception("A database error occured: " . substr(mysql_error($dbh), 0, 200));
}
-
- // Update wp_usermeta.meta_key replacing source prefix with destination prefix
- mysql_query("UPDATE {$sourceTablePrefix}usermeta SET meta_key=REPLACE(meta_key, '$sourceTablePrefix', '$destTablePrefix')
- WHERE meta_key LIKE '{$sourceTablePrefix}%'", $dbh);
- if (mysql_error($dbh)) {
- throw new Exception("A database error occured: " . substr(mysql_error($dbh), 0, 200));
- }
+
+ if (!is_multisite()) {
+ // Update wp_usermeta.meta_key replacing source prefix with destination prefix
+ mysql_query("UPDATE {$sourceTablePrefix}usermeta SET meta_key=REPLACE(meta_key, '$sourceTablePrefix', '$destTablePrefix')
+ WHERE meta_key LIKE '{$sourceTablePrefix}%'", $dbh);
+ if (mysql_error($dbh)) {
+ throw new Exception("A database error occured: " . substr(mysql_error($dbh), 0, 200));
+ }
+ }
mysql_query("UPDATE {$temporaryDatabase}.{$sourceTablePrefix}options SET option_name='{$destTablePrefix}user_roles' WHERE option_name='{$sourceTablePrefix}user_roles'",
if (mysql_error($dbh)) {
@@ -1667,4 +1669,4 @@ abstract class DeployMintAbstract implements DeployMintInterface
return $prefix . $value;
}, $this->wpTables);
}
-}
\ No newline at end of file |
First, I would like to thank both you and Mr. Maunder for an excellent product. However, it doesn't seem to want to work on a fresh install of WP 3.8.1 :) I used it years ago and remember having to make one or two small changes to the way the blog prefix was chosen to get it to work, but that was so long ago...
I recently started working on sites again and wanted to use DeployMint in an upcoming project because it's one of those "must haves" for staging projects.
I'll give a quick rundown of the things I've done:
The following errors appeared in the webserver's error log. (I had literally clicked on "Network Activate," then on "DeployMint" (in the menu), then filled in the config and clicked "Save." Before clicking anything else, I checked the error log:
There are more errors after this, as I believe this one solves itself eventually. (Perhaps it re-checks if the table exists when a project is created or something.)
I click on "Manage Projects," and create a new one by just filling out the name of the project. (No additional tables, no git origin.)
In the error log were more errors:
The blog names (where to add a blog to a project), under the newly created project, are blank. The drop-down is there, with the appropriate number of blogs created in system, but it does not give a domain or a name or any identifying information for each blog selection option.
I will continue to tinker with it and see if I can get it to work...
The text was updated successfully, but these errors were encountered: