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.
Related
I have searched for a while and still cannot find the correponding file which contains the table creation script in wordpress multinetwork environment.
Do you have any idea?
Thanks.
There is no table creation script, it just uses the database prefix + blog id + table name when creating tables for a particular site, for example if the prefix is wp_ for a regular WordPress install, it becomes wp_2_ for blog id 2, and so on...
The code that does this in the source is here http://core.trac.wordpress.org/browser/tags/3.5.1/wp-includes/wp-db.php#L670
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
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!
I have somewhat caused a weird issue.
I moved a client to a different server.
Upgraded wordpress + database.
Little did I know, I was actually updating the database on the previous server due to the config having a hardcoded mysql IP address.
So I resolved that in the config, then it asked to update the database.
Now it doesn't show posts / pages in admin but the counts still show up in the "All" "Published" links.
Is there a bit or "status" that didn't get set in the database update?
Something that is preventing these from showing in admin.
They show up fine on the front webpage.
Any help would be appreciated!
UPDATE:
Created a new post after upgrade and the count increased to 13 but still says "No Posts".
:-\
UPDATE:
Links & Comments both show up with a huge list.
Posts, Pages, and Media do not show up.
Maybe this has to do with the post_author index they WordPress added?
I verified the user existed with matching ID. :-\
We had exactly the same issue but only on the Pages in the website.
Steps to fix...
Edit wp-config.php to add
define('WP_ALLOW_REPAIR', true);
Hit the database repair URL
HOSTNAME/wp-admin/maint/repair.php
RESULT
My database was a bit messed up and so I got the following output...
wp_usermeta: 5 clients are using or haven't closed the table properly
wp_posts: 7 clients are using or haven't closed the table properly
wp_options: 8 clients are using or haven't closed the table properly
wp_postmeta: 7 clients are using or haven't closed the table properly
wp_terms: 1 client is using or hasn't closed the table properly
wp_term_taxonomy: 3 clients are using or haven't closed the table properly
wp_term_relationships: 3 clients are using or haven't closed the table properly
In my case, I was using Poly Lang and was selected the Arabic language to show only and after switching to all problem solved.
best thing to do, if its still possible, is on the old server,
do an export from within your tools admin menu,
on the new server do a fresh install, and do an import using the same method,
once wordpress downloads and activates the plugin for the import just upload your wordpress file, during the import assign the users to either current users or just re-create them, then tick the box to import all attachments...
I've had this happen a few times when trying to move servers, some things in the database just get mixed up, but from previous experience, doing the export/import saved a lot of time..
I had the same issue and it had to deal with the functions.php file. Make sure there are no mistakes there and try reuploading. You may also try using another theme to see if the problem persists.
It's the old standby, but deactivate your plugins one by one and see if the posts come back. It's such an odd problem that I couldn't imagine it was a plugin issue (posts disappearing in the admin?), but it was for me -- I discovered it after all sorts of database gymnastics, etc. My guess is the new server has a more recent version of php and that's what's causing the issue, but oddly it wasn't throwing a visible error (even in the logs).
In my case deactivating "WPML Media" plugin fixed the problem.
WordPress runs the following query to populate the post page in admin:
SELECT wp_posts.ID, wp_posts.post_parent FROM wp_posts
WHERE 1=1 AND wp_posts.post_type = 'article' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'virtual' OR wp_posts.post_status = 'future' OR wp_posts.post_status = 'draft' OR wp_posts.post_status = 'pending' OR wp_posts.post_status = 'private')
ORDER BY wp_posts.menu_order ASC, wp_posts.post_title ASC
I used this and found out during a data transfer that the post_status was set to 'published' instead of 'publish' which caused no articles to show despite showing a count.
I had this same problem, I read Travis's comment and starting looking through my functions.php. Turns out query_posts() was causing the issue. To fix this, I added wp_reset_query(); after I was done retrieving data from my query.
I had a similar issue and this is how I solved it:
in the wp_posts table, I found out that the colums
post_ENGINE and post_mime_ENGINE should rather be
post_type and post_mime_type.
I changed it and pages and posts are now showing in the admin panel. I don't know if my problem is the same but I hope it helps.
Instance where column names are post_ENGINE and post_mime_ENGINE
Instance where column names are changed to post_type and post_mime_type
When migrating a site to a new server, I used phpMyAdmin to export the db and import it on the new server. Some of the tables had date fields with a default value of 0000-00-00 00:00:00. Eventually I discovered that when those values were exported they caused import errors. In particular, adding a db index to the table failed because this is an invalid date-time. My fix / workaround was to edit the exported sql to change all instances of that string to 2001-01-01 00:00:01 (which was a date several years before any actual entries); delete (i.e. drop) all the tables on the new server, and reimport them. Then everything worked. The data imported, the indexes were created, and no blank pages or posts missing in the "all posts" edit.php page.
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..