I've got Drupal working on a shared host, and I uploaded some modules from my home system successfully, but I've got the message that there is a security update for my version, and I should update immediately.
I'm not sure how I'm supposed to do that. It seems like the update is an entire new installation. I originally installed it using the hosting company's installer, Fantastico. Should I simply over-write the existing installation with the new files? Or ignore the message? I realize I shouldn't over-write the sites folder, or anything I've modified.
The instructions that come with the download seem to be for a major version upgrade, and are way too much trouble for frequent security updates. Searching Drupal's site shows many other methods, but no indication of anything official. And some were ridiculously error-prone, and not really useful.
I don't have shell access to the hosting site, although I can pay extra to get it if I really need to. Or, maybe I can clone the site on my local Linux system, do the update using a script, then upload the whole thing.
Does anyone have experience with this situation?
With only FTP access you should:
Download and extract the new Drupal version.
Delete the sites folder (in the downloaded Drupal), this is very important.
Put your site in maintainance mode.
Upload the content of the new Drupal (not the sites folder). This should give you a new version of all the Drupal core files, but leave the sites folder intact where you have your custom and contrib modules, your settings.php file and your uploaded files.
Run update.php as user 1.
Lastly put your site in online mode again.
Related
I just recently started by creating a EC2 instance on AWS. I used the Amazon Linux package. I changed the PHP settings to include the ability to upload files larger than 200MB. Got phpinfo.php working. Installed phpMyAdmin. Everything looked good.
Next, I installed Wordpress. It worked great. Then I tried installing a theme. Worked great. Then I started installing some plugins for that theme. Something made the site crash. I tried a few things, but since I couldn't go to the sites Wordpress Admin panel, it seemed hopeless. So I decided to start from scratch. I deleted the html directory (including wp-content) and dropped all the wordpress tables. I moved a fresh copy of Wordpress into the html directory, reconfigured the config.php file, and it recreated the Wordpress tables in the database. Seems to work great. When I try to upload a theme, it says:
Connection Information
To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.
I noticed that wp-content didn't have a uploads directory, so I created one. That seemed to let me upload the theme, but it showed up as a media file. I moved it to the theme directory and that worked. But when I tried to upload a plugin, I got the same message as a above.
What happened when I deleted everything? Or rather, where was information stored that when I reinstalled Wordpress, it didn't create a uploads directory? I am fine with reinstalling Wordpress from scratch, but I don't want to reinstall the whole LAMP stack or redo the AWS instance. Any thoughts?
The issue is that your web server doesn't have the proper permissions to write to your content directory.
The WordPress Codex has some good info for proper file and directory permissions. Ideally, all files should have 644 permissions, and all directories should be 755 (no higher).
If you're still running into issues adding plugins and updating WordPress, you should heed the advice of the following (so that you don't have to enter FTP details into WordPress each time):
Any file that needs write access from WordPress should be writable by the web server. If your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process.
I'd like to add a installation of a Wordpress site to version control. After researching a little bit, I found some files/folders that should be ignore, like sitemap.xml and cache folders.
Every single one of them say I shouldn't ignore wp-content/plugins/, which is a reasonable advice at first. The question is: How should I deal with plugins that alter the database?
I can see two scenarios:
If the plugin has to add some tables on installation, this trigger would be lost since it would already be "installed" after uploading the files to the server.
If I must access the installation screen on production, then there's no reason to version control these files.
I would suggest to take a look at this great presentation. It's the most complete I saw yet.
http://stevegrunwell.github.io/wordpress-git
You should have your plugins directory in there too since you do want to track plugin files. As for the database, that's another subject completely. Take a look at the development of VersionPress, it should be out at the end of the year.
Ok, so I'm familiar with creating local Wordpress builds, and have been chugging along happily with the technique outlined in Smashing's MAMP-based article. My question goes a step beyond this.
The article is great for developing generic themes, but when developing sites (not necessarily blogs) based in Wordpress, for me at least, it's a little painful come launch day.
I have to go back in and reconfigure the server's Wordpress to match what I've already done locally. Settings have to be entered again, plugins need be installed again, menus recreated, and css will have to be altered to reference the unique classes/id's Wordpress generates for posts/pages/custom taxonomies…sometimes things are missed in the process. What I want to know is this:
Is there an easy way to automate cloning or mirroring the build on my local machine to the remote server?
Even if you have to just LMGTFY me, that would help. I don't exactly know what I should be searching for. Searches dealing with 'mirroring wordpress configuration' and 'cloning wordpress configuration' returns tutorials on moving content, which I know how to do.
If it helps, I'm running OSX 10.6.8 with xcode dev tools, git, ruby, node, and homebrew. All of my live servers have ssh access as well as ftp, and I build with the most current versions of Wordpress.
Here are some easy steps to follow:
Download and install the WP Migrate DB plugin.
Go to Tools > WP Migrate DB and fill-in the blank fields(New address (URL), New file path and optionally check/uncheck the other options). Click on Export Database and save the export file to your computer.
Make a .zip archive with ALL of your files(the /wp-admin, /wp-content, /wp-includes directories and all files in the root directory).
Upload that file to your production server, where you want your WordPress site to reside.
Go to your cPanel(or use the unzip command through SSH) File Manager(or any other alternative that you might have) and unzip the file that you just uploaded.
If you don't already have a Database set-up on your production server - create one through the hosting control panel(for cPanel, it would be Creating a mySQL database in cPanel, for plesk it would be Plesk 7 Tutorial: Creating a database, for anything else, just google it up, or try your hosting's FAQ). Remember/write-down your Database Name, Database User and Password.
Edit the wp-config.php file and change the values for the DB_NAME, DB_USER, DB_PASSWORD and optionally DB_HOST - but this is usually localhost - if that doesn't work try asking your web host, or if you have phpMyAdmin, log-in to it and look at the very top of the page - in this case the DB_HOST would be localhost.
After you've done all of that, log-in to your DB administration tool(most of the time this would be phpMyAdmin, but it could be something else as well) and upload the database export file that you save to your computer in step 2. Note: If your hosting hasn't provided you with a DB administration tool, I would suggest that you upload the phpMiniAdmin(click on the "Download latest version" link and save the file to your computer) script to your production server. Then go to that script(if your website is located at http://example.com/, go to http://example.com/phpminiadmin.php) and enter your DB details. On top of that page, you will see an import link. Click on it and upload your DB export file. Note 2: phpMiniAdmin doesn't support gzip-compressed files, so if you did check the Compress file with gzip option in step 2, you will have to re-do that step with this option unchecked.
Log-in to your site and go to Settings > Permalinks in order to update your permalink structure.
Check the permissions of the /wp-content/uploads and /wp-content/plugins directories - make sure that you will be able to upload images and plugins without any problems.
That's pretty much it. It might seem like a lot, but I follow this process for almost every site that I upload to production servers and it can take me as less as a bit under 10 minutes to do all of that(considering that I usually use custom MySQL commands, instead of the WP Migrate DB plugin - I should probably start using it :) ). Once you get used to the process and you don't encounter any low-quality web hostings, you should be perfectly fine with these steps.
Note: Since you used ssh as one of your tags, I assume that you usually have ssh access to the production server. If you don't I'm still assuming that you have a cPanel access(if that's not true and you can't unzip files on the server, then upload all files manually via FTP client, instead of doing steps 3 and 4).
I guess the only way is to copy the database or part of it.
What I do is to copy the relevant tables and modify manually the site URLs in table options. There are only 2. There is also a nice plugin velvet-blues-update-urls to modify all links, after the site URLs are set manually to be able to access the backend, in case posts are also copied.
Next, copy all theme directory files to the same directory in the site, assuming you are using the same theme.
Both processes can be automated with a PHP script.
I am not sure this is what you want, but hope this helps.
Not sure that this is exactly what you need, but to move a site you can use the built in Wordpress "export" and "import" options. As far as I remember there was an option when importing to change URL's and the import would change a few things for you.
Even if this does not answer your exact question, hope it helps.
I am having a website redesigned. The designers plan to use Wordpress as the CMS and want a development copy to work with. Thing is, I now have Wordpress installed to run a blog (only) on a subdirectory of my current site.
Soooo...question is: Can I create a subdomain, install Wordpress on there, point it at a separate (new) schema on MySQL and have them use that for the development work? I know I can physically do this, but will anything about running the the WP install scripts on the subdomain screw up the existing production install on the main domain?
The install itself should not create any problems. Personally, I always develop WP sites in their own subdomain, allowing me to do away with the wordpress/ subdirectory.
The most significant hurdle will come when you are ready to move the development site to a new domain and/or place in the directory hierarchy. Although the theme files and their associated CSS, JS, etc., files should be using relative-path references, the database itself may contain hundreds of fully qualified URLs that reference the development domain and/or directory.
There are a number of WordPress plugins that address this problems. The one I am most familiar with is BackupBuddy from ithemes.com. (I'm not a shill, just a satisfied customer.) BB is useful both for performing scheduled backups (full or database-only), but it is also very useful during development and during deployment. There is an included script, importbuddy.php, than can not only take a .zip of a full backup and restore the site, it can also move the site from one directory and/or domain to another.
Note: BackupBuddy is not free, but it is released under GPLv2. You are paying for the support necessary to keep it tracking changes in the WP ecosystem. If you are doing any serious WP work then it is money well-spent. You might suggest this to your designers.
Yes you can do it. It doesn't matter. You can install your new blogs to any directory or subdomain (actually they're directories, too). Also you can use new MySQL databases for them, or you can use same database for your all WP installations (by editing wp-config.php manually), thereby you'll have same content for your all WP blogs.
Technically, yes you can do it.
However, if you have a live domain with public people using it, you are best not developing on either the same domain or server, because:
Mistakes happen. You can break the database or other code.
While you develop, you can affect performance of the server.
Develop on a local machine, or a completely different server, and when you are happy with it, push the code live onto the production server.
if you are planning to make a test copy of the current install on a subdomain which includes separate source code and database the answer is NO it will not affect your current installation.
I run my blog using Wordpress and all too recently became a big believer in SCM. I really want to put my site into subversion (that's what I'm using right now, maybe git will come later) but I can't think of the correct way to do it yet. Basically, my repository is set up currently with an 'implementation' directory and a 'resources' directory, with implementation holding what will eventually be published to the live site. I want to be able to preview my site locally without having to upload to the server for obvious reasons. However, to do this I found that I needed to actually install Wordpress locally (not just copy the remote site down to my local box). This was told to me over at Wordpress.org.
This brings up the problem of being able to use SCM with the install because I need to upgrade my local site every now and then but this generates inconsistencies with subversion because it can’t track what’s going on because an external system is messing with it’s repository structure. That just won’t work.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
Anyway, I’m sure other people have tackled this and the solution is probably applicable to many apps similar to Wordpress (Drupal, phpBB, phpMyAdmin, etc.). So, how do you do it?
It's actually not that hard to do, but I'll break it down into a few suggestions here. What you're describing is more or less a "vendor drop" directory. This is basically where you maintain the code in SVN, but replace the contents with the newer stuff as it comes out.
What you should start with is an empty directory. Set up an SVN repository, and then do an SVN checkout into the empty directory (it will still be empty, except it will get a hidden .svn directory added). Next, install wordpress here normally, and then add its files to svn. You can probably just "svn add *" but be careful, and remove anything you don't want versioned (uploads/temp/cache directories, if applicable). You can also use the svn:ignore property to tell it to ignore certain directories or file types, if you'd like. Run "svn stat" to show you what is going to be checked in, etc, and once all is good, commit it (svn commit) and start working from there. Now you have a base installation of wordpress in SVN.
As you work and make changes, commit them.
When it comes time to upgrade, simply replace wordpress over top of what you have. Make sure when you replace directories, you replace the contents, and not the whole directory itself. You don't want to lose the hidden .svn folder in every folder because that is what will mess subversion up. Do an svn stat and/or svn diff to figure out what's changed, if anything, and mostly what's newly-added. At this point, you can commit again.
To deploy on your production site, you can do an svn export, or do a regular checkout into the web directory. If you do a checkout, be sure to only update when you are ready to deploy.
This is the method I'm testing. It takes some time to setup but you should then (in theory) have a future-proof install:
Installing WordPress The Right Way
Also look at svn:externals for pulling in plugin updates:
Use svn:externals to install WordPress plugins
I think the upgrade part can even be a little easier than that; I do this with the most current version of both 2.5 and 2.6, as well as bleeding-edge trunk revision of WP.
Since Wordpress offers all of their stuff as subversion repositories, getting the current rev of a stable tag is as easy as making the blog directory and then
# svn co http://svn.automattic.com/wordpress/tags/2.6.2/ (replace the current rev here for the first check out).
When an upgrade is available, simply navigate to your blog directory and run
#svn sw http://svn.automattic.com/wordpress/tags/2.6.3/ (or whatever wordpress rev you're updating to)
Then releasing to your production site is just an export, as gregmac mentions
However, I don't think this answers your actual question, which I interpret as "How do I keep my custom stuff in SCM while being able to upgrade Wordpress". Your instainct about what directories to tack is pretty much on target (your own personal blog's stuff - themes, pplugins - will be in wp-content, so you should only need to put that into subversion) but I'm not proficient enough with subversion to tell you how to place the directory into your own repository while still being able to rely on Wordpress's repo for upgrades. My "SCM" for those files on my site is an off-server copy of the wp-content directory.
Maybe from that standpoint gregmac's answer works better for you.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
That's exactly how I version control my blog. I've found that it works great. Generally, if you're editing WordPress' files, you're doing it wrong and will be in for misery when it's time to upgrade.
To simplify this, I use TortoiseSVN. I navigated to my /wp-content/themes/ directory in Windows Explorer, right clicked on my custom theme's directory, and chose import from the context menu. After importing all of the existing files, I performed a checkout on that directory and everything was set.