I have encountered a "problem" (fussy client) with a WordPress site and I will be restoring it back to a downloaded .gz database from two months ago. Now, in my work since then, I'd installed a new theme and created custom post types. The new theme has a number of custom CSS settings, and the custom post types have a number of files.
Since I'm doing a database restore to a snapshot before the new theme and custom post types existed, I have a few questions:
-Will this restore all setting to how it was configured at the time (general, reading, discussion)?
-Will the plugins that were added later just be deactivated?
-I'm guessing the new theme will still exist since its files are physically there. Will any settings on the new theme get erased with the database restore or will they stay and the theme just gets deactivated?
It's a messed-up situation and I basically want to restore back to August but archive my work on the new theme and custom posts if possible. Thanks!
If you restore the Wordpress database, you will change all of your settings back to the way they were at the time of the backup. The reason for this is the wp_options likely contains your theme options and definitely contains most Wordpress settings menu options (permalinks, reading, etc).
The plugins that were added later will be deactivated - there is a record in wp_options called active_plugins which is an array of your active plugin. Overwriting this value will disable new plugins, but as long as they are in the /wp-content/plugins directory, you can re-activate them, albeit with their settings missing. The same goes for your theme - as long as the files are there you can re-activate, but the missing options values will mean the settings are gone.
Now for something for helpful. First, definitely make a backup of your site as it exists now before you do anything else. Once you have a backup, rather than dropping the tables, etc, you can try renaming this schema so that it won't conflict, and then restore your backup to a new schema that contains the original name (the one Wordpress is configured to use now). With two schemas on the same server, you can now run queries to compare the current database values and the restored database values as well as insert them where necessary. Assume your restored schema is called restored and your current schema is called current, the following cross scheme query would show you any settings that don't exist in the restored schema:
SELECT co.option_id, co.option_name, co.option_value, co.autoload
FROM current.wp_options co
WHERE co.option_id NOT IN
(SELECT ro.option_id FROM restored.wp_options ro)
Add in some WHERE co.option_name LIKE 'key_% type queries to extract certain sets of values if you wanted to copy them into your restored schema. You might want to take a look at the wp_postmeta values in a similar way, or even compare values from the wp_options table where the ID/key exists, but the values don't match to see what changed.
Good luck!
Related
I was wondering if there is an activationdate stored somewhere. I searched for this in the database but cannot find it. I might make it through an option than but is there already something which I can use to determine on what date a theme ws activated?
Search your WordPress DB for theme_mods_ (in wp_options), there should be a timestamp (serialized) for each theme in there.
I have installed a template that I bought, and this template came with a SQL script to run. After I ran it everything works fine, except that the admin user now doesn't have permission to delete articles, media, and other stuff.
I have complete access to the server along with knowledge of PHP and SQL. How can I fix this?
Check the wp_user_level value in the wp_usermeta table of your database. It should probably be 10.
Found the solution.
The original WordPress installation used a prefix for all table names. Apparently, fields in wp_users, wp_options and wp_usermeta whose names begin with "wp_" are supposed to begin with the full prefix.
I changed the table names in the script, but not the actual field names.
Setting the names to the full prefix solved this.
example:
if the prefix is wp_f3refs then wp_user-settings should be wp_f3refs_user-settings.
Thanks everyone for your help.
I am trying to learn how to create a custom content type programmatically from within my module.
However, after uninstalling and reinstalling my module I was getting an error stating that one or more of the fields I was trying to create could not be created because they already exist.
So I went hacking through my databse, removing the content type and all tables that belonged to it.
Same result -- field already exists.
Next I went to the Drupal API website looking for ways to delete fields and field instances, and came across
field_delete_field()
and
field_delete_instance()
I made a php page to try to delete the fields that I had created, only to get an error stating that the table I was trying to delete does not exist.
So I'm kinda stuck -- I can't create the fields because they already exist, and I can't delete them because they don't exist!
BTW the code I was modeling my module after is the code found in the "node_example" section of the Drupal examples module.
Ouch, deleting the database tables manually is never a good idea - Drupal's not that forgiving :)
Just to address the code in your install/enable hook, wrap the field creation in:
if (!field_info_field('field_name')) {
field_create_field(...
}
That will stop the problem happening again. Or if you don't want to do that, make sure the field is deleted in the uninstall/disable hook. Obviously that method would potentially result in data loss.
To address the current problem, follow this process:
Completely uninstall (not just disable) your custom module. If it's in an inconsistent state, just delete its row in the system table.
Delete all traces of the field from the field_config and field_config_instance tables.
Truncate all the cache tables manually (any table beginning with cache_).
Not strictly necessary but clear up any lingering content:
$nids = db_query('SELECT nid FROM {node} WHERE type = :type', array(':type' => 'type'))->fetchCol();
node_delete_multiple($nids);
That ought to do it.
Any time you delete a field, through the UI or programatically you'll need to either run cron or call field_purge_batch() to 'hard' delete the fields as they're only marked for deletion in the first instance.
I am working on a forensics course, with which I have been looking into an attack on a blog server. I have found a number of deleted Wordpress files, and I have managed to figure out which ones contained blog posts.
The one file I cannot figure out contains information beginning with the following:
wordpress#UPDATE wp_options SET option_value = 'O:9:\"MagpieRSS\":19:{s:6:\"parser\";i:0;s:12:\"current_item\";a:0:{}s:5:\"items\";a:10:{i:0;a:9:{s:5:\"title\";s:37:\"India Vs Pakistan: Now Cyber Terror? \";s:6:\"author\";s:8:\"chinchak\";s:4:\"link\";s:59:\"http://feeds09.technorati.com/~r/trarticles/~3/sxlCqi2M9aE/\";s:4:\"guid\";s:74:\"http://technorati.com/politics/article/india-vs-pakistan-now-cyber-terror/\";s:11:\"description\";s:182:\"The India-Pakistan relations could very well be termed the greatest mystery ever of mankind.\";s:7:\"pubdate\";s:31:\"Tue, 21 Aug 2012 00:03:41 +0000\";s:8:\"category\";s:51:\"PoliticsAssam ViolenceCyber TerrorIndia Vs Pakistan\";s:10:\"feedburner\";a:1:{s:8:\"origlink\";s:74:\"http://technorati.com/politics/article/india-vs-pakistan-now-cyber-terror/\";}
It continues in this way for a while, but I haven't had too much luck trying to use Google to tell me what the "wp_options" means. It looks like someone was trying to spam the blog with commments but I can't be sure without a source which can confirm my view is correct. Can anybody help please?
The wp_option table stores key-value information in the columns option_name and option_value. When storing arrays they get serialized, to decode them you can use PHP's unserialize function. It looks like you're dealing with an SQL injection that tries to mess with Wordpress' user options. The purpose is not obvious, because they are rarely displayed. Just used internally. If there's a where clause somewhere in that SQL statement that tells you which option name it's trying to edit you could perhaps match it using this list:
http://codex.wordpress.org/Option_Reference
how can I change my Drupal filesystem root in the database ?
I moved Drupal to another path. I'm looking for this value to update in the database.
thanks
<EDIT>if you want to change it in the database (why?), you can do it by changing the value of file_directory_path in the variable table:
UPDATE variable SET file_directory_path = 's:5:"files";';
values in the variable table are stored as serialized php variables. the serialized value in the example above means file_directory_path is a string (s) of length 5 with the value files. you have to adapt this to your specific value.
also note that Drupal variables are cached (in the cache table, under the cid variables). for your change in the database to take effect, you have to clear that cache, like DELETE FROM cache WHERE cid = 'variables';.</EDIT>
if you mean the File system path: it's at Administer > Site configuration > File system, or http://yourdrupalsite.com/index.php?q=admin/settings/file-system.
You could also do the following:
//Get the path of the files folder (ex. sites/default/files)
$files_dir = variable_get('file_directory_path', '');
//To set a new path programmatically
variable_set('file_directory_path', 'sites/new-path/files');
Funny, I just had to do that yesterday.
Since i have phpmyadmin available to me, I used that to export the files table, then do some search/replace routines, then import the table, overwriting the data.
But had I not had phpmyadmin to help, I would have created an SQL query to replace the outdated paths...
Funny, I just moved my drupal to another folder, and it was working. Probably I didn't explain my question very well..