I would like to know when Drupal clears the cache (or rebuilds it in more recent versions of Drupal). Does anyone know how I can get Drupal to record an entry in a log, whenever it clears the cache? At the risk of sounding like a complete idiot, does Drupal use Drush to rebuild the cache when it does it by itself (on schedule)? Or, is Drush just for the dumb human to use?
As a first step, try using hook_cache_flush or hook_rebuild in a custom module and check the results.
As far as I know any rebuild/cache clear will go through these hooks.
Related
I installed reCaptcha in the Drupal 7 module in hopes that it would work on the contact form, but it never did. So I did a really dumb thing and deleted the reCaptcha from Google and forgetting that connection to it was in the module.
It turns out that the reCaptcha did work but only on the admin login screen. Now that I am locked out, does anyone have a really brilliant idea for someone who made a really bad move?
I finally found the answer and I want to post it in case anyone else runs into a problem with any module in Drupal, not just with reCaptcha.
The main steps I used were found on this website: Disabling or enabling a module
All I did was make a backup of the db. Determined what the module name was that I was needing to disable:
SELECT name,status FROM system WHERE type='module' AND status='1'
Then change the status to '0' using of the actual module name I needed to disable:
UPDATE system SET status='0' WHERE name='module_name'
At this point I thought it was done, but because Drupal keeps a cached copy of it enabled in the db you still have to delete the cache:
DELETE FROM cache_bootstrap WHERE cid='system_list'
I logged in to the company's Drupal (7.19) site and noticed a lot of recommended updates.
There is a security update available for your version of Drupal. To ensure the security of your server, you should update immediately!
See the available updates page for more information and to install your missing updates.
There are security updates available for one or more of your modules or themes. To ensure the security of your server, you should update immediately!
See the available updates page for more information and to install your missing updates.
I chose to download the updates. I then proceeded to update, Drupal suggested I'd do this in maintenance mode.
Upon proceeding I was greeted by a long message, telling me that all updates had failed because the directories could not be removed.
nodeaccesskeys
Error installing / updating
File Transfer failed, reason: Cannot remove directory
Your modules have been downloaded and updated.
Run database updates
When visiting:
admin/config/development/maintenance
the box that says “Put site into maintenance mode” is not checked, yet the site still remains in maintenance mode when I visit it in another browser (so that I’m not viewing it while being logged in as the administrator.)
I feel both things are related seeing as I had no issues before I tried to update the modules in question.
I'm not entirely sure what to do here. Is there a way to fix this preferably without resorting to code? I'm not too familiar with Drupal. I just wanted to update out of date modules.
At this point I don't really care about not being able to update, I'd just like the site to not be in maintenance mode anymore.
Thanks in advance.
You might need to clear the cache on /admin/config/development/performance
Recently I got to know that my Wordpress site is automatically updating itself when a new version of Wordpress is available. I know that this automatic feature is available in
Wordpress since sometimes back. But I have some questions about this
1) Can this be risky in any case?
2) Doesn't it a matter the way how we have installed Wordpress? (e.g plugins and security settings)
3) Does Wordpress have a way to recover our website if anything happen?
4) Don't they keep any backup before do the update?
Could you please give me your answers to the above?
I'll answer each of your questions to the best of my knowledge:
1) Can this be risky in any case?
The automatic updates are mostly security updates. Though you can never be 100% sure it doesn't break anything, security updates don't deprecate functions or change much on how the CMS works. This means that nearly every plugin and theme can still use the same functions without issue.
2) Doesn't it a matter the way how we have installed Wordpress? (e.g plugins and security settings)
This ofcourse matters, to some extend. But if a site is working in Wordpress 3.8.3, it will still work in Wordpress 3.8.4. If a site however uses functions that will be deprecated, you might have problems when upgrading from 3.8 to 3.9. However, major updates aren't done automatically, and still need to be done manually, giving you the opportunity to make a backup beforehand.
3) Does Wordpress have a way to recover our website if anything happen?
No, it doesn't. You CAN however turn of the automatic updates. But, as stated at question 1, the risks aren't very big with the security updates.
4) Don't they keep any backup before do the update?
No they don't. It is your own responsibility to keep backups of your website.
I hope this answers your questions. If something is unclear, please let me know in the comments, and I'll look into it for you.
If your themes and plugins use functions from Codex then I think your are much safer. Make sure the plugins and themes are using functions to get directories and URI's through functions defined by Codex, what I mean to say is:
use: get_template_directory_uri();
instead of xyz.com/wp-content/themes or even home_url('/wp-content/themes'); and other things like that.
yes sometime it can create a mess and it won't allow to admin to login.
most command questions asked are
Can't login after automatic update
login failed after wordpress update.
here is a very quick fix for all of them.
http://onl9class.com/solved-cant-login-after-wordpress-update/
Here is all answer of your questions, please check below:
1. Can this be risky in any case?
The automatic updates are good for security purpose but some times it will break our function work in website because some plugin developer will not update own code according to wp updates so it would be good you can manually updates all things after checking plug-ins compatibility with new version.
2. Doesn't it a matter the way how we have installed Wordpress?
No it always matter, because some times wordpress core developer changes the function and they will be depreciate in new version so it would be good, always take backup of website and manually do the updates.
3. Does Wordpress have a way to recover our website if anything happen?
No, but you can install wp plugin and schedule it to take backup in each week.so you can at-least get the latest backup of website. I always use the back up plugin in my websites.
4. Don't they keep any backup before do the update?
No they don't take backup of website. but wp always show notification when you start update please take backup.
Thanks
My client has 1000 WordPress blogs hosted on a server for customers. Each one is in its own domain through cpanel and SuPHP, running in CGI mode on Apache2.2. Now he wants me (I'm the PHP programmer) to get WP-Cache loaded out on each of these blogs and not just activated, but enabled. He also wants the timeout value set to 2 days instead of the default setting.
I have root on LAMP.
What is the preferred way to roll out an update to each blog such that on a page view, it sees if WP-Cache is enabled or not. If not, it needs to copy it out from a central source, activate it, and then enable it along with the different timeout value being used.
A way, maybe not the best way, is to write a script to copy the wp-cache plugin to every wp-content/pulugins folder. Then run another script that will go and modify every DB entry for it enabling it.
If not done correctly this can be devastating as it hits customer db's.
However, one thing to note is wp-cache has a history of killing other plugins. So, if you go in and add this plugin to everyone's wordpress it might hurt there experience if it hurts another plugin they have installed thus increasing support costs as people might be emailing trying to figure out what broke.
I take it this is being done to work on performance issues. Is it possible to maybe do some type of server caching outside of wordpress?
edit: after reading Joes comment I concur with him. Didn't even cross my mind.
I have chosen XMLSiteMap module from the most popular usage statistics on Drupal site,
so I assume the module is not too buggy. But the map file is absent.
I've installed this module on my Windows machine into drupal/sites/default/modules.
I've activated all the submodules of XMLSiteMap in admin menu.
Per docs, I've also run cron.php manually to create sitemap.xml in drupal/sites/default/files - but it's just not present there even when second re-install.
How can I force to create sitemap.xml?
(also tried with and w/o clean URLs - still no help).
Also, if there any good reliable alternative for this module?
Are you sure you've installed it properly? Please check the Status report (admin/logs/status in Drupal 5, admin/reports/status in Drupal 6) to ensure that you've got everything right.
It's possible that you haven't set the permissions of sites/default/files properly yet for example.
I'm not sure if this will help you, but if you are looking for an actual created sitemap.xml file rather than navigating to it in the browser I don't believe one is created by the module. I think the module creates a menu callback to create the sitemap file, so a request for sitemap.xml is handled by Drupal's menu system, rather than creating an actual file. There will however be a cached version in sites/default/files/xmlsitemap.
Apologies if this is an oversimplification of the question asked.
I have not had any problems with the reliability of the module myself.
Also make sure you have the latest version installed, it just came out yesterday:
http://drupal.org/project/xmlsitemap
Also, see this issue, seems related to your problem:
http://drupal.org/node/458546
I'd probably recommend trying the 6.x-2.x branch which I've been rewriting to kind of solve all the annoying bugs and architectural problems of the 6.x-1.x branch. It's currently incomplete, but it works for nodes and menu items currently. Taxonomy terms and user profiles will be added soon.
You can find the link to it on the project page. Sorry I can't link since I'm a new user. :)
Running the CRON worked for me:
/admin/reports/status/run-cron