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.
Related
I am working in a WordPress project that for some reason the plugins disappeared, the data still exits but neither the project owner or me know what plugins were installed. For example I knew contact form 7 was installed because it showed me [contact-form-7 id="424"] in the page, I installed it and I can see the plugin now
there are other plugins for user authentication, permissions, etc. But how could I know which were installed?
there are no plugins in the plugins page so I need to check in the db or anywhere else.
First of all, I would try and determine why all the plugins aren't showing up (perhaps the /wp-content/plugins/ folder got renamed? It's a common way to quickly disable all plugins for diagnostics)
Beyond that, if you go to your wp_options table, there is a an option called active_plugins that contains a serialized array of the active plugin files that looks like:
a:13:{i:0;s:29:"gravityforms/gravityforms.php";i:1;s:19:"akismet/akismet.php"; … }
It sounds like your database is fine, consider page content is unaffected, so this should suffice in getting you a list of active plugins, provided they haven't been registered as inactive due to the plugin files not being found - if so you'll probably want to dig through a database backup from when it was working (and if you have a "Full Backup" you may even be able to restore the plugin files from there)
Note: Serialized arrays can be a pain to read, you can either dump the unserialized value in your own script, or use an online tool like this or this to get a more readable format.
I noticed that on a wordpress site I'm going to take over the following scripts are found on multiple pages:
When the page is displayed here is what I see:
This seems incredibly scammy, does anyone know what this is?
I am going to delete all of those and restrict access to the website in the meantime
Thank you
One of two things likely happened. Either you are serving flash and have a really old version on your computer - OR - your website has been compromised and injected with some sort of malware.
Are the unusual scripts showing up in the content or the theme files? If they are showing up on the content, that means someone has added these scripts to the database, and it will require a bit of cleanup (or a restore to a previous version). If the scripts are showing up in actual .php files, then someone has gained access to the file system on the server.
You should re-install WordPress entirely to ensure all core files are clean, and then go through plugins and themes to ensure all malicious code has been removed.
Also, it would be good to find out how this happened, to attempt to stop it from happening again.
I got in charge of some small sites that are running on WP 3.5; they are all using the same theme (a customized version of Bones). I have only used Joomla some years ago so I have no idea if, after the upgrade, the theme will still be compatible. I want to upgrade my WP version because the current one is vulnerable: I keep getting spam links into my articles that are placed inside hidden divs.
How can I know if the template is compatible or how can I fix the security issue. Any of these will do great.
Thanks!
WordPress does a very good job of changing very little with regards to theme tags in a core update. That said, we have no idea how your theme(s) have been made, or what functions they use.
The best, and probably only realistic option here, is to create a test site (a duplicate) and update that site first, then test to make sure all is working as it should.
As for the vulnerability, this is likely due to an insecure admin password or an insecure plugin. You should ensure all your plugins are up to date and that your admin panel is suitably secure.
When you update wordpress, it will not affect the wp-content folder which is having themes and plugins. So, don't worry update it. But for the secure updation, please take the backup of whole website first. Take backup of database and all files before doing any update.
WP 4 hasn't been out that long. I'd hold off on the upgrade unless you absolutely have to, until you know that all of the plugins used on the sites are compatible w/ WP 4.
Try to install the site on your PC creating a local copy using XAMP (for Windows).
In this way, you can:
download the MySQL database to have all the information of the
website locally;
install the latest wordpress platform locally (on your PC);
test the website thorugh common browsers.
At the end, you'll be sure about the compatibility and you can update the main site.
I have built my own theme with the Artisteer software; then i modified many PHP file to manage the loop in some special ways; so, to be sure that everything is working after an update of the site Wordpress version, i test everything on my PC.
For the vulnerability, please verify your plugin and all your theme file.
In some experiences, there are some plugin or simply some codes place somewhere in your theme which can create something like this:
> <div id="headerblock"> <center> <div style="left: -2227px; position:
> absolute; top: -3337px">
The only thing to do is check all the theme file and plugin to see where this code is placed.
Please check here for more information.
If you only change your password, probably it will not solve you problem because the malicious code is already inside your system.
Sometimes the malicious code can be placed directly inside the MySQL database.
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.
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.