Switching themes in Drupal without the web interface - php

I'm in the process of learning php and creating themes.
Unfortunately, while I was editing a theme that i was currently using in drupal, I made a mistake in the theme such that nothing shows up anymore, even if i were to hit drupal/index.php. I want to change my broken drupal theme to a working one but i'm unable to do so because I can't even view the administration section.

The How To reset your theme via the database page on Drupal.org has instructions for changing your theme directly from the SQL prompt.
It's not immediately clear whether this will work in the most recent version of Drupal, so back up your database before attempting this.

The easiest way to change your frontend theme is to set it in your sites/default/settings.php:
$conf['theme_default'] = 'minelli';

In terms of sorting your current problem, here's a simple way to do it that should work... Let's say your current theme is called "custom_theme".
Go to your theme directory ("sites/default/themes" probably)
Backup your development theme (i.e. move it elsewhere, if you're using Linux command line do something like "mv custom_theme custom_theme.bak")
Copy the garland theme to here and name it the same as your broken theme (if using LInux command line, something like this should work "cp -a ../../../themes/garland ./custom_theme"
Try viewing your site now. It should now use garland instead of your broken theme.
As others have said before, it's also highly recommended that you use a different theme for admins as you do for normal users (in case you break stuff). Select a safe admin theme (like garland) and then you can nearly always get to the admin interface if you're playing with theming.

Or if you are using Drupal 6, removing/moving the broken theme folder will make Drupal change the theme to the default theme (Garland).

Maybe using two themes in parallel will help.
Set one for the "user frontend" - the one you are developing at /admin/build/themes, another one standard, like garland, which you are NOT going to change, as a "administration backend": /admin/settings/admin.
If you happen to break the theme you're developing, you just go to the admin area (/admin), it will switch back to garland.

you can also insert a new login form in your theme by including this code:
`<?php
if(!user_is_logged_in() ){
print drupal_render(drupal_get_form('user_login'));
}else{
print "You are already logged in!";
}?>`
anywhere in the page.tpl.php file of your broken theme, then register with your admin credentials ;)

Please also see the following stack over flow issue.
it is related to them
Changing Drupal's theme and keeping Garland as the admin theme?
Changing the Admin Theme in Drupal 6 Directly in Database
Now here is solution :
Remove the files of the bad theme and clear the cache. After clearing the cache you will be able to login again.
The main difficulty is that you have to clear the cache without being logged in.
Try one of the methods for clearing the cache described in
Clearing Drupal's cache
IF Not then Try this one :
If you have drush, the command to type would be
drush vset theme_default garland
Either on the commandline, or via an administration interface (eg PHPMyAdmin) enter the following query
UPDATE system SET status=1 WHERE name = 'garland';
Then either:
UPDATE variable SET value='s:7:"garland"' WHERE name = 'theme_default';
TRUNCATE cache;
TRUNCATE cache_bootstrap;
TRUNCATE cache_block;
Note that 's:7' refers to the length of the following string. Modify as needed. This is database surgery, tricky stuff.
OR
If you are using per-user themes, and you've just messed it up for yourself as admin, try
UPDATE users SET theme='garland' WHERE uid = '1';
Be careful, as getting either of those lines wrong can mess things up just as badly.
Cheers!
Mudassar Ali

As far as I know, theme settings are stored in the database, as well for each individual user. The quickest way to get rid of a theme is probably removing it from the theme path.
Just move it onto your desktop and Drupal should be able to detect that your requested theme is missing and point you to the default instead.
Update: Tried this on my Drupal 5 installation, it turned out 'clean'. I suggest copying a working Drupal theme into your theme directory (make a copy first).

It's worth mentioning that if you're using the "Sections" module to apply different themes to different parts of the site, the instructions given on the Drupal site won't necessarily work — you may find that moving the problem theme directory out of the way is the only method of seeing the admin interface properly.

Related

WORDPRESS - Clone Website on a New Installation to Update It

We need to recreate our site from scratch. When I mean from scratch I mean we want to keep the same content (pages, articles, URLs and tons of media) and move it to a new WordPress installation with a different theme.
A brief background to try to understand what the underlying problem is. The current site (the one to be copied and transferred) is HUGE. It has more than 1500 pages and 3000 articles. It is currently running on an old version of WordPress and an outdated theme. We are deliberately not updating WordPress, theme and PHP so as not to risk crashing and being left without a site (this has already happened in the past with another installation).
What we have done is to create (on the same hosting) a new, updated installation of WordPress (on another directory). This will be the new and definitive one. Then – when all is said and done – we should use the name of the first installation (but this will be another issue to deal with at the end). We decided to operate in this way because we want everything to be done as safely as possible.
Some details:
Objective: SITE 1 -> SITE 2
SITE 1: Installation: domain.org/directory1 WordPress 5.2 PHP 7.1.33
Theme: Awaken
SITE 2: Installation: domain.org/directory2 WordPress 5.7.1 PHP
7.1.33 Theme: Divi Builder
At the moment, we have already installed the new theme in directory2 and created the home page that will host all the pages and articles from the old site. We are not interested in keeping the plugins. Our aim is for the new installation to be as “clean” as possible, without the risk of dragging around old problems.
What do you think is the correct way to proceed? Again, the most important thing is that the links are not changed (so that the URLs will still work once the change has been made; I mean: domain.org/directory1/perma/link/article-written-in-the past = domain.org/directory2/perma/link/article-written-in-the past
Could the export/import tool do this job? How should I proceed to make sure that I don’t affect the performance of the new site? Is it possible to carry out a test with a few pages to see if this can be done?
Thank you all!
The first step is to create a backup of the existing site. You can do this manually, you need all of the site files plus the database.
However, Duplicator is a great plugin that will create a backup package that includes everything for you. One thing to be aware of is the size of your site may cause issues for the plugin do to server load, but its the easiest method. There are other plugins as well to help with migration.
Once you have everything you can copy it to a new domaon like dev.website.com. The installer from Duplicator will help with the url updates, but its pretty easy to adjust in the config file and database options table. If you use relative urls most things wont be an issue, but a simple find and replace in the database will easy update any absolute urls.
Once you have made all your changes in dev you just reverse the process by writing over the live site and your set. This is safe beacuse you have a backup of the live site from step one in case you need to revert to the current state.

Is it OK to edit/update Wordpress theme files over FTP?

I'm working on developing my first Wordpress theme. As of now, I've just been coding the files, zipping my theme folder, and then uploading and activating the theme in my Wordpress Dashboard to test it.
However, this has become quite tedious, as I basically have to:
1) code a bit of my theme, zip into folder
2) deactivate/remove old version of theme in Wordpress dashboard
3) upload new version of theme, and activate
4) repeat...
I'd like to install Wordpress locally, but I don't quite understand how to do that yet, and I'm not familiar setting up a local webserver.
SO... rather than do it the tedious way that I have been, is it OK to just make sure my theme is activated, and then edit my files and overwrite/upload them to the wp themes folder over FTP using Filezilla?
I'm guessing it'd be considered bad practice, but for the time being would this work well enough until I learn a better way?
That's definitely okay.
You can modify the files locally and then upload the changes using FTP. Make sure you have backups so if you accidentally FTP the wrong changes you can easily revert them.
Yes you can absolutely download the uncompressed theme and modify and put it back using ftp.
Also, some themes support whats called a child theme. This allows you to override the theme with your changes, without changing the original source code. Which in turn gives you a better upgrade path from the original theme provider when they have updates.
I have actually had some weird formatting issues with WP after manually editing files, where they would no longer run, so I try to avoid it. But I have bad luck that time.

Wordpress Admin doesn't load css files and images

I'm having a serious problem. I have wordpress 3.9 installed on my server. the problem is that my website front end loads good, but my back end just loads text :
I have updated/reinstalled wordpress but nothing has happend. What should I do?
Thanks for help.
I'm 100% sure that if you simply do the following, you'll figure out what's wrong and fix it.
Deactivate all plugins without use of your WP-Admin.
Activate them, 2 or 3 at a time, and determine which plugin is the culprit
If none of these plugins are the culprit, go to the WordPress site and download WordPress. With an FTP utility such as FileZilla or another client if you already have one, then upload the entire wp-admin folder to your server, overwriting older files.
Your WordPress admin will be fine after these steps. And of course, never alter any core WordPress files -- ever. The only files you should ever tinker with are files in your child theme, which is something you should be using.
Would be great to have a bit more information about this topic. First of all: Is this a new problem respectively did the admin run without errors before? (3.9 sounds like the page is not a new clean install).
Usually I would start debugging the page via e.g. firebug => Check the Stats of the CSS-Files.
If they load correctly (200) check if they are empty or incomplete (Incompleteness can be checked via diff against the original file ... most IDEs will handle that for you)! If they aren't you have probably just diabled CSS in your browser for the URL of the admin-panel.
If they don't load, try to check why! If the files exist its most probably an error in your .htaccess (wrong rewrite, blocked directory, etc.).

Developing Wordpress theme on a live site

What's the best way to work on a WP theme on a live site? So that the users see the current theme and I can see the one I'm working on. I know WP has a preview theme option, which works, but it has a sidebar that lets you go back to the WP management page, which means when I try to inspect the source it has lots of extra stuff that the actual theme wouldn't have.
Any ideas? Thanks.
Working on a live site is not a good idea. All changes you make will be viewable to your users.
You have two options here. The first option is to create a subdomain like test.example.com and install wordpress there. From there you can do changes to the theme without worrying about the live site. Once done, you can just move your theme over to the live site.
The second and best option is to install wordpress locally on your pc. I use xammplite for that purpose. It works the same as a live install, but it is faster making changes to a theme. Also, if you make a mistake somewhere like a syntax error, you can correct it quickly, no need to ftp a file backwards and forwards between pc and live site.
If this doesn't cut it, your last least favored option is to download a maintanance plugin and put your site in maintainance mode. You will be able to see and test your site, and everyone else will see a maintainance notice

Magento custom category widget not appearing on stage server

I followed this (first comment),
magento - category name and image in static block? to create a simple widget to display the category image and title from a static block on a CMS page. It works fine on my local MAMP version of Magento Enterprise 1.13.0.2. It's not working however on the stage / test environment Magento 1.13.1.0. (ubuntu).
It doesn't error, it's as though it's ignoring the template file (info.phtml). When I reverted to the default theme I realised I had to copy the template files to the default enterprise folder to get it to work but it did (local version). I have made sure that the template folders are in each of the themes, base, enterprise (default), MyTheme (default (which is enterprise default) & (MyTheme / MyThemeVariant)).
The only setting / configuration that appears to be different between the local and the stage is that pretty url's aren't working on the local. I have looked into the htaccess and it still isn't resolved. On both versions the native Category link Widget isn't working but i'm not sure if that is relevant.
I have disabled any extensions turned the cache off and cleared the index. Still nothing.
I have been looking for the answer, retracing my steps, altering and changing back any setting(s) I think may be relevant for 3 days now so i'm well stuck. Anything anyone can offer to try I will give it a go.
So in Magento Enterprise there is also a full page cache that you can access via the Magento Admin here : System->Configuration->System->advanced->External full page cache settings.
On the page System->Cache management, as well as disabling all the caches you should flush the Magento Cache and the Cache Storage.
You might have a 'cache' called Redis or APC, but I don't think that affects .phtml output. and if you can access the Widget in the back end I don;t think those items are the problem.
Your webserver might have a full page cache such as Varnish but I don't know how to use it or turn it on or off.
Theoretically your webserver headers might be saying 'this page doesn't update so internet providers can store local copies in their caches' - but I would be astonished if that was the case (inspect your header and inspect the Cache-control Expires and Last-modifed headers if you want to eliminate this possibility).
Your browser might have it's own little cache (which you can clear from your browser settings).
If it isn't a cache problem, in my experience .phtml files get skipped if they have PHP errors in them but you have it working on your local dev server. Could it be a file permission issue? Could it be a setting in the widget on your server that is not handled by your widgets .phtml? As alast resort, try changing your widget .phtml to a really simple file like <?php echo('test PHP output'); ?> and see if that renders - try putting the widget on different pages (ie new pages that won't be cached anywhere) and see if that get's everything through.
Could you have a namespace conflict with another module? Eg an XML file is changing your widget block XML name that sets the .phtml template? Does your widget.xml file declare <supported_blocks>...</supported_blocks> which might be excluding the block into which you are trying to render the widget?
What else? You mentioned this widget displays category information: Are you referring to a category that exists on your staging server? It will probably have a different category ID than your dev server and / or check the category is visible in the website and store.
Okay, I think I am out of ideas now.
The problem was that "Block" php file's first letter was lowercase. I changed it from info.php to Info.php and now everything works as expected.
This has been the single most frustrating investigation yet into Magento. The only thing I hope is that it saves someone a whole load of pain.

Categories