Drupal: update filesystem path in the database - drupal

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..

Related

How to find if file has been imported in Access database or created within it?

In my access database there is a dataset which I need to know how it has been created. I tried to backtrack and reached to a table for which I am not able to find any source data. I am pretty much sure that it has been imported from some where. I checked in "View" option there is not "SQL" view for that table. It only has "Datasheet" view and "Design View".
In access database is there any way to check that whether a file has been imported or has been created using SQL query within access database? Is there any "flag" raised or something like that?
No. Once data is persisted in a table, that's it.
If you need further info, you can have a Timestamp field with a default value of:
Now()
or, if a higher resolution than one second is needed:
Date() + Timer() / 86400
or another custom field where you record session info as you like during the import or creation of data.

Wordpress admin suddenly not an admin

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.

Wordpress deleted file info "UPDATE wp_options SET option_value"

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

Preparation & Data Preservation For WordPress .gz rRestoration

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!

Store and retrieve images from file system instead of database

I need a place to store images. My first thought was to use the database, but many seems to recommend using the filesystem. This seems to fit my case, but how do I implement it?
The filenames need to be unique, how to do that. Should I use a guid?
How to retrieve the files, should I go directly to the database using the filename, make a aspx page and passing either filename or primary key as a querystring and then read the file.
What about client side caching, is that enabled when using a page like image.aspx?id=123 ?
How do I delete the files, when the associated record is deleted?
I guess there are many other things that I still haven't thought about.
Links, samples and guidelines are very welcome!
Uploading Files in ASP.NET 2.0
You seem up in the air about how to do this, so I'll give you a few ideas to get you going.
If you want to use a file system make sure you know the limit of how many files are permitted per directory, so you can set up a system that creates subdirectories. http://ask-leo.com/is_there_a_limit_to_what_a_single_folder_or_directory_can_hold.html
I would make a table something like this :
FileUpload
UploadID int identity/auto generate PK, used as FK in other tables
InternalFileName string
DisplayFileName string
Comment string
MimeType string
FileSizeBytes int
FileHash string MD5 Hash of a File
UploadUserID int FK to UserID
UploadDate date
You would include the UploadID in the table that "owns" this upload, like the Order associated with it, etc. You could add the InternalDirectory column, but I prefer to calculate this based on a constant Root value + some key specific value. For example, the complete file name and directory would be:
Constant_Root+'\'+OrderID+'\'+InternalFileName
You could make the InternalFileName be the UploadID and the file extension from the original file. That way it would be unique, but You'll have to insert the row as the first part of the process, and update it after after you know the file name and identity/auto generate row value. You could make the InternalFileName something like YYYMMDDhhmissmmm and the file extension from the original file, which may be unique enough based on how you use subdirectories.
I like to store a MD5 Hash of a File which makes detecting duplicates easy.
MimeType and FileSizeBytes can be found from the file system, but if you store them in the database, it makes some maintenance easier since you can query for large files or files of certain types.

Resources