Ok, let's say i'm a big newby on drupal, and that i want to load a theme (which actually should be enabled, and displaying - currently not). And that i don't have access to the admin part of the install (old site, etc… don't ask why).
Looking for someone to specify me the files to change in order to make this theme work.
Thanks
(We could talk about clearing the cache "manually" too… hate sometimes those all-in-the-admin stuffs, but well…)
To enable a theme 'manually' you'll need to visit the system table in your database and set the status column to 1 for the record with a type of 'theme' and a name matching the theme you want to enable.
Manually flushing caches is as simple as running a DELETE FROM table for all tables whose name begins with cache (e.g. cache, cache_block, cache_content, etc.).
None of what you're trying to find is located in files, almost all of Drupal's config is held in the database (those in settings.php excluded).
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 gave in to the nagging message from Jetpack last week to turn on "Protect" and the day after, I found myself unable to log in to the admin dashboard. (I'm not 100% certain that Jetpack is at fault here, but it's the most obvious thing that changed.)
Symptom is that wp-admin is not available for any of my sub-sites.
I've tried the usual things (IP whitelist, adding IP to the config file, disabling the suspicious plugin, disabling all the plugins) but the behavior remains the same.
Any login attempt will fail, and I'll see a redirect to the login page. Here's the URI pattern for the redirect:
http://myclientsite.domain.us/wp-login.php?redirect_to=http%3A%2F%myclientsite.domain.us%2Fwp-admin%2F&reauth=1
I thought to address it at the database level, but inspecting the database, I do not see any user table. (I'm led to believe that the user table should be global to the installation and contain user info for all sites)
So my two questions are:
How can I find the user table for my site? I've logged in to the database directly both with the wordpress user account and with the root account. Don't see the table in either case.
What can I change about the installation that would allow me to at least access the admin functions and disable the offending plugin?
To get into wp-admin, you can disable all plugins by renaming the plugins folder that is in the wp-content folder.
In this case, I finally stood up a new multisite instance and imported a safe backup (using Updraft Plus to backup and restore in this case).
I did not resolve the lockout issue, but I found the answer to another mystery I was wrestling with. The user table WAS present, but my superficial understanding of phpMyAdmin kept me from seeing it. (Shoulda used the mysql cli client)
It turns out that in the table browser on the left hand margin (navigation panel), the table list is paged, and I was looking only at the first page.
So each subordinate site has table name prefixes that look like wp_X_ where X is the subdomain index within the multisite structure. The "primary" site has data in tables that simply use wp_ and that's the one that hosts the user table.
For me then, the trick was to notice that in the phpMyAdmin navigation panel, I could page to the next set of tables and there was the table I needed.
I want to dispaly post of non ssl wordpress site to my ssl site but while displaying images it gives mix content warning in console.
How to solve it pls help.
Solution 1 :
This is the simplest fix. If an asset (image, script, etc.) is hard-coded into a plugin or theme, change it from http://example.com/assets/logo.png to https://example.com/assets/logo.png.
Typically, this is most useful when including assets from other servers, like Google scripts, API scripts, or iframes.
Before doing this, however, you need to make sure the HTTPS version is available. If loading an asset from a site that doesn't have HTTPS enabled, it's probably best to remove the reference entirely (i.e. comment out or delete) or to save the asset to your own server and change the source to load via your site instead.
Solution 2:
References to your images are stored in your database, both in the wp_posts and wp_postmeta tables (in a standard install. You might have given your tables a prefix, but locating them should in any case be doable).
Since you mentioned using phpMyAdmin I guessed you are able editing the contents of your database with this tool.
Via phpMyAdmin you could manually locate and change the urls pointing to your images (removing the 'wp' part). But as this might be quite a few database entries, replacing all in one go is a more convenient decision.
I myself have had satisfactory results by
exporting the complete database as a .sql file through the phpMyAdmin export option.
editing this file with a text editor (converting the incorrect urls to the correct ones, make a backup copy first in case anything goes wrong, never forget the backup!)
deleting all database tables (for the wp install you're trying to correct)
importing the edited .sql file
So i have recently tried to transfer my wordpress site to another server.
I have followed a few guides, but i definately seem to be missing a step.
Basically what i have done is:
export original database (phpMyAdmin)
Save all relevant files (ftp)
install fresh wordpress on new server. (wp backend)
'drop' all table fields in new wordpress (phpMyAdmin)
import original database to new location (phpMyAdmin)
transfer theme, plugins, uploads. (ftp)
activate theme, plugins. (wp backend)
update permalinks. (wp backend)
The problem is, i am left with a default looking wordpress installation, and not my orginal page-home.php and corresponding css.
Also, if i go to wordpress backend SETTINGS > READING > Frontpage:static; i only have the option of 'about', not home, i should have 'home'...
Sorry if i am vague, let me know if any screenshots are required.
We really need a little more info like:
when you say plain, do you mean just the theme is not set and you're on the default theme, or there is no theme, or do you mean even your content is not there?
the site you removed it from, where was the installation located? Was is in the public_html folder or a subfolder of that? Did you put it in the same place, ie not inadvertently put it in a different folder
(I've actually typed the bulk of the post and come back to the top for this one, but):
Are you sure you're checking the right site?
Have you kept the same domain name?
Has the domain name propagated to the new server?
Is the CSS being loaded from the correct domain (has anything been hardcoded to the old server)
Let's go through a few broader options:
1. Check how many WordPress installs are on your domain
First off, it sounds like you may have two WordPress installations. If you have the backend setup correctly with your themes but you're seeing a plain site, it sounds like you're looking at another install. I'm not saying you do have multiple installs, but it is a place to start looking.
A question to ask yourself here is: In this plain looking site, do you see your content, or the content of a default site? If you see your content, you may jump ahead to section 2.
If you're saying there is a home page but you're not seeing it as available under static pages, either:
You're looking at another site (but there should be a home page* even in a default setup—from memory), or
You're Home Page title may have changed, or have become "unpublished", ie reverted to a draft, or pending review. Check the page:
actually exists,
has the title you're looking for
the slug hasn't changed
(*note: although it could be a Welcome Page I'm thinking of here.)
Double check the database
The easiest way to do this is to go into your database and see how many WP databases there are. Check each database and look for the underlying table structure, it sounds like you should be able to identify it pretty easily. If it's not a multisite install, the table prefixes should be wp_ unless you changed them somewhere.
While you're playing around in the database, Take note of the database name and table prefix.
Double check the folder structure
Have a look for a second instance of your folder structure, maybe you dropped it into the wrong place).
2. Check the WordPress installation is actually connected to the database
Check the WordPress configuration file wp-config.php is connected to the database. Check wp-config.php sample from codex, you'll want to see the correct database name and table prefix in there.
From here you should also check the username has been setup correctly and is as you expect it. Remember, the database name will likely have a different prefix between hosting providers, unless you've managed to keep the same login name with each provider. ie, I'm talking about the database prefix here, not the table prefix.
(another note: most database connection issues will result in errors appearing on the page in lieu of your site, which leads me to believe it's at least partially setup correctly.)
TEST: What you can do is rename the old wp-config.php to something else and don't create a new one, then visit the website and it will lead you into setting it up again where you can enter the database details (your site info will still be intact, this will only reset your config file, not the database, although it could reset the connection between the filesystem and database).
3. Domain name propagation and DNS settings with your new host
As I mentioned previously, are you checking the right server? Are you sure the domain name has been propagated (if you're using the same domain name that is).
Check the IP address with your DNS provider (for your domain name) is correctly pointed to your new server
Then check that from your command line by typing ping {your-domain-name} and see that your IP address comes up
Check the DNS settings with your web host are setup correctly and that your domain name points to where you want it to point to (ie, public_html or the relevant subdirectory there-of). (This resally does come back to point one, which if you covered it, this shouldn't be an issue
Check that you dropped the files (and all the files) into the correct physical directory, ie public_html (or sub-dir)
If none of these help, please leave a comment with any further developments you've made and as much info as possible, and we can start looking in other areas.
*notes about the database name:
when playing with WordPress directly, ie in the configuration files or the backend administration settings, the database will include your {username}[underscore or hyphen]{database-name}
when playing in phpMyAdmin, they will already be included and you will just provide the {database-name}.
Fellow this steps
export your sql from cpanel---phpmyadmin
make zip of your files in cpanel
import the file in new domain and extract it
create a database link to the new domain
go to new database which you have reacted through phpmyadmin--delete all the tables which was installed by wordpress.
import that sql file which you have downloaded from old website
and in phpmyadmin change the url to new domain name
Regards
Follow these steps:
export database from phpmyadmin.
zip your WordPress project via c-panel.
upload zip file on new domain via c-panel.
extract zip file.
create new database and import old database in new phpmyadmin.
configure user name and password and database name.
change url in database table. from wp_operation table home_url and site_url
Thanks
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.