So, my Drupal site is not reflecting any CSS changes I make. I've tried doing a hard cache of the site, I've tried multiple browsers, I've checked the actual stylesheet on the server to make sure it's copying over (the stylesheet reflects the changes, but the actual site does not). I've, of course, gone to the clear cache section under configuration/performance on the admin panel. I have gone into the FTP and manually deleted the cache. I have cleared my own browsers' cache. The CSS files are going in the correct folder (I've checked that, too!). I have done literally everything I can think of. I have tried toggling the aggregate & compress css options on and off, clearing the cache in between. I inspected the page source, and it is definitely still presenting with the old CSS.
Every attempt at debugging has led me to believe that this has something to do with the DNS not refreshing. I read somewhere that someone made some kind of changes to the A Name Record. I've set the TTL to 1/2 hr, reset the A Name Record manually, and I removed the forwarding I had on the domain, just in case.
These are the things I have done. People of Stack Overflow, what am I missing? I've scoured the net for a solution, and nobody who's had this problem has found a solution. Has anyone had this problem and fixed it? What did you do? Any ideas?
::edit:: I just wanted to add that I'm using Skeleton Theme as a base.
::edit edit:: I've also used Devel to Rebuild the Theme Registry.
This was cross posted to the distribution's issue queue, but I don't think it has anything to do with the Community Media Starter Kit distribution itself.
First, you should rule out DNS by settings the DNS locally and/or clearing the DNS cache. These are the steps for OSX, but you can find the similar instructions for any OS...
Clearing local DNS cache
Mac OSX Lion DNS lookup order
Once you've determined that the site you are ftp'ing to is the same site, let's look at how the themes are being loaded by the distribution. With any Drupal distribution/install profile, you can override any module or theme included in profiles/[PROFILENAME]/modules or profiles/[PROFILENAME]/themes by placing a new/older/altered version in sites/all/modules or sites/all/themes. When moving modules that use Drupal's registry, you get a WSOD. This often requires using drush rr or manually clearing the cache tables]1 since the WSOD will stop all pages from loading including the Admin > Performance > Clear Cache. It is REALLY unlikely that would be required for a theme.
In this specific distribution, you can also use the CSS Injector module to make CSS changes without having to update the css files themselves. That css is stored in the database, so it will impact the site you are looking at.
Check that the theme .info file is named exactly the same as the theme directory in sites/all/themes/
If not, the theme showed up for me, but the .info file had no effect.
Changed both to be the same, and was confused to see multiple themes available under site appearance, one for each .info file. Activated the other theme and saw the changes. Just name the directory and the .info file exactly the same.
And, of course, clear the cache, turn off ccs aggregation.
I've never used the Skeleton base theme, but Omega has a theme settings under Appearance where you can enable and disable styles per theme. Maybe Skeleton has that same thing?
I am just starting in Drupal, so I may be totally of track with my answer, but I still tell you what I experienced the last days. So I installed Drupal Commerce Kickstart and made a child-theme of kickstart commerce. This I installed. And when I altered the CSS of it and uploaded it through the ftp client it took more than half an hour before the change took effect. So I searched and finally with Firebug I found out that Drupal makes it's own CSS of it and places it in sites/default/files/css. When I looked with Inspector which css file of these I needed to make the change I wanted, it took seconds, after reloading the changed css file in sites/default/files/css, for the change to see happen.
So apparently it takes these css files before the theme css files. Which for me I found stupid. I don't know if that can help you. Anyway I was wondering if creating these files in sites/default/files/css is really necessary. I deleted them for test but they come back. Don't know if there is a possibility to stop that process.
Pagespeed ( a site caching system ) from whois hosting was the cause of this for me. I logged in to the customer's hosting account and shut it off. The problem was resolved, but I also implemented this code, which allowed the theme registry to be rebuilt on every page load, and that made a huge difference.Now css changes are instant. Before the site goes live I will disable this code.
Are you sure you're not meaning to rebuild the theme registry instead?
To rebuild the theme registry and the theme .info file during development, add this to your theme's template.php file:
<?php
/**
* Auto-rebuild the theme registry during theme development.
*/
if (theme_get_setting('rebuild_registry') && !defined('MAINTENANCE_MODE')) {
// Rebuild .info data.
system_rebuild_theme_data();
// Rebuild theme registry.
drupal_theme_rebuild();
}
?>
And add this to your theme's theme-settings.php within your {themename}_form_system_theme_settings_alter(&$form, $form_state) function:
<?php
$form['rebuild_registry'] = array(
'#type' => 'checkbox',
'#title' => t('Rebuild theme registry on every page.'),
'#default_value' => theme_get_setting('rebuild_registry'),
'#description' => t('During theme development, it can be very useful to continuously rebuild the theme registry. WARNING: this is a huge performance penalty and must be turned off on production websites.', array('!link' => 'http://drupal.org/node/173880#theme-registry')),
);
?>
Related
I’m working on correcting a styling of an element on an WP-based eCommerce site.
The site has both SCSS and CSS files.
To make things quick, I edited the CSS via Appearance -> Customize -> Additional CSS.
However, when I was done and published my changes (and solved the issue), only those new to the website sees the difference.
Those who have visited the site prior to the deployment of the solution, still see the distorted number layout
I also suspected that the SCSS gets compiled every refresh but when I checked the File Manager (cPanel), only the CSS files get modified.
I’m feeling this might be a cache-related issue. I have already disabled a cache plugin (WP Rocket). However, the problem still persists.
What possible issue am I experiencing?
Edit: I did try to use Incognito and the change did reflect. However, the users of the site are non-techy people and don't know how to refresh.
The site is using GoDaddy as the host. Is it possible the issue is on that part?
Thank you
Backstory
We are using a LAMP stack (bitnami) to run a multisite Wordpress instance. This is the second time I have ran into a file that will not update when we push an update (We use git and pull the latest changes to the bitnami server).
We have noticed that when deleting (renaming for that matter) the file, it can still be retrieved by performing a GET on the resource (or the url in a browser). Also, if we were trying to make changes the changes do not come with the file - it is still the old file. Interestingly enough, the file is minified, which because of issues with this in the past we do not use any plugins that minify our CSS. So there should be no reason for it to be minified.
We have WP Total Cache - clearing all caches is successful but does not stop this from happening. (We used to use WP Super Cache, when this bug happened we decided to change plugins to WP Total Cache and purged the cache and it fixed the problem - but it is back and that no longer works).
I have also seen the trick where we can use a "?ver=###" query param on the url. This works but this would prevent us from using CloudFront for our files (currently disabled for all this testing so its not the problem either). Also I am not convinced it is a long term solution - or a solution at all since these minified files are being created and shouldnt be in the first place.
Additional information
It may not be helpful, but the files we have noticed this with are in a theme folder that is not technically an active theme. We just use the folder for additional resources that we have created ourselves. We reference them in the head of some pages.
Example:
/wp-content/themes/active-theme <- The active theme
/wp-content/themes/resources <- Our custom resources
Questions:
Where is this file being stored?
How can I delete it?
How can I prevent this from wasting our time ever again?
I found that the issue was with the bitnami server itself. The Apache2 module PageSpeed was causing the served files to be minified and cached resulting in the pages never updating no matter what we did on wordpress.
Apache:
To disable PageSpeed, comment out the following lines in your httpd.conf (/opt/bitnami/apache2/conf/httpd.conf)
#Include conf/pagespeed.conf
#Include conf/pagespeed_libraries.conf
Solution found here
I have buddypress 2.2.4 installed with wordpress 4.4.
Now issue I am facing is, I did some modification to buddypress plugin in plugin files it self. And its reverting back. Its changing my modified files to its original versions. even I try this in my local and same result.
I ask server guy but he told its buddypress issue.
When you modify a BP file, do you see changes in the browser? Or do the files revert to the original state instantly after closing them in a code editor? What are the file permission settings for the BP plugin files?
What files do you modify and with what changes?
Are you hitting update for the plugin? Plugin updates always overwrite local changes as new files are written over the old ones (unless you juggle with write-permissions for the files).
It is not a BuddyPress issue by itself (tried it myself and I could hack the plugin files just fine). It could be the server giving you the illusion of write-allowed files whilst keeping the files unchanged ("reverting"). Or then the plugins are updated constantly, undoing your changes.
The proper way to make modifications is to either use hooks in a plugin or a theme, or copy over the BuddyPress templates to your theme and make modifications there.
I didnt find any solution to that. but I keep my changes by adding a override files to child theme. because I tried everything and its not stopping reset plugin.
So finally making override of plugin in child theme solve this issue.
I got in charge of some small sites that are running on WP 3.5; they are all using the same theme (a customized version of Bones). I have only used Joomla some years ago so I have no idea if, after the upgrade, the theme will still be compatible. I want to upgrade my WP version because the current one is vulnerable: I keep getting spam links into my articles that are placed inside hidden divs.
How can I know if the template is compatible or how can I fix the security issue. Any of these will do great.
Thanks!
WordPress does a very good job of changing very little with regards to theme tags in a core update. That said, we have no idea how your theme(s) have been made, or what functions they use.
The best, and probably only realistic option here, is to create a test site (a duplicate) and update that site first, then test to make sure all is working as it should.
As for the vulnerability, this is likely due to an insecure admin password or an insecure plugin. You should ensure all your plugins are up to date and that your admin panel is suitably secure.
When you update wordpress, it will not affect the wp-content folder which is having themes and plugins. So, don't worry update it. But for the secure updation, please take the backup of whole website first. Take backup of database and all files before doing any update.
WP 4 hasn't been out that long. I'd hold off on the upgrade unless you absolutely have to, until you know that all of the plugins used on the sites are compatible w/ WP 4.
Try to install the site on your PC creating a local copy using XAMP (for Windows).
In this way, you can:
download the MySQL database to have all the information of the
website locally;
install the latest wordpress platform locally (on your PC);
test the website thorugh common browsers.
At the end, you'll be sure about the compatibility and you can update the main site.
I have built my own theme with the Artisteer software; then i modified many PHP file to manage the loop in some special ways; so, to be sure that everything is working after an update of the site Wordpress version, i test everything on my PC.
For the vulnerability, please verify your plugin and all your theme file.
In some experiences, there are some plugin or simply some codes place somewhere in your theme which can create something like this:
> <div id="headerblock"> <center> <div style="left: -2227px; position:
> absolute; top: -3337px">
The only thing to do is check all the theme file and plugin to see where this code is placed.
Please check here for more information.
If you only change your password, probably it will not solve you problem because the malicious code is already inside your system.
Sometimes the malicious code can be placed directly inside the MySQL database.
Greetings and thanks in advance for your feedback. Now I realize that this isn't GoDaddy tech support but I'm asking the question here before I step into those murky, black waters.
Scenario: I edit the CSS and various templates for the default template via Appearance > Editor. All looks and performs great. I hand off to my client. She reports back that after adding a new post the customizations are overwritten and the default theme files are restored! She claims that GoDaddy told her that its "on my end."
Nonsense, right? There is no relation between adding a post and updating theme files, right?
This is the second time this has occurred - the first time we assumed GoDaddy had backups of the customized files (not). At least with the second occurrence, I had a local backup.
Any ideas or suggestions?
either that or the wordpress install has been upgraded, if your theme folder is still using the default then it will be overwritten by wordpress on upgrade..
if so change your default theme folder to something else...
then edit the css file and give it a new name...
Use FTP and a text editor to edit the theme files directly and check their permissions. I think the changes are not taking effect because you've got file permission problems, and as soon as the client forces a reload of the site, she sees the unchanged files again.
And if you're using a Windows server, consider changing to Linux. GoDaddy has lots of problems with Wordpress on Windows, from permission problems to permalinks. You can change to a Linux server in a few hours: Switching Your Hosting Account Operating System - GoDaddy Help Center