I've problem with the search module in drupal. When I do a seach, it return 0 results even-though there are patterns matching. I ran the cron manually and flushed the cache. Now, the search module works fine.
I wanna know whether I should do this procedure regularly for the search module to work?
thanks.
clearing cache is not need, running cron is main
read here how to do: http://drupal.org/cron
Related
I wounder how and when wordpress starts the auto-update process (if configured). I think on a (hosted) Webserver you cannot create a task for checking and starting updates for your website. Also, wordpress uses auto-updates out of the box without additional configuration.
So how does it work? When and how does wordpress check if there is a new version available? Does this happen when anybody visits your website and the update-function is started or are there other possabilities e.g. the webserver always runs an open thread for checking for updates and processing them.
I hope you understand my question.
Firstly, you can create a task for checking and starting updates, most commonly used is a cron job.
In wordpress 3.7 the automatic updates feature was added.
To enable it you add this to wp-config.php:
define('WP_AUTO_UPDATE_CORE', true);
In default-filters.php you will find add_action( 'init', 'wp_cron' );
It runs wp-includes/cron.php on every page load from a user, which will auto-update it.
So long answer short it checks whenever a user loads the webpage.
I believe it uses a cron job to perform this. The only restriction is that these jobs can only be run when the website is accessed from the server ie. when people are visiting it.
I've noticed this a few times with local copies, that whenever I open them up to browse them (after not viewing them for a while), I get a local email saying my Wordpress installation has automatically been upgraded.
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.
I am new with drupal. I have installed ultimate cron in Drupal 7. now I have created a php script to be a mycron.php, my problem is that I don't know where can I insert my cron job in my Drupal's ultimate cron.
I am looking where can I insert mycron.php to ultimate cron module page but I failed.
I also look to the site where i downloaded it but it is not there. http://drupal.org/project/ultimate_cron
Does anyone have an idea how to solve my problem?
Usually you don't add custom cron scripts (full .php files) but defining the job that needs to be done using hook_cron()
If you create a module with "myname" as the name and you can now define a function like
function myname_cron(){
//do stuff here
}
You can use full Drupal functions here as a fully boostrapped Drupal instance available for you. and Ultimate Cron (or other cron-related modules) can take care of load balancing now.
So I've been trying to make several changes to a custom WordPress theme which introduces an entire overhaul of the Dashboard. I keep finding little issues with the original theme that I need to fix (not properly checking for duplicate posts when you import new ones, post metadata not getting stored correctly, posts not getting sorted into their proper categories, etc.)
As I've been working with this I've needed to look at and modify the database countless times to either see what the theme is doing to the database or fix things it screwed up. Unfortunately I was unable to install phpMyAdmin so I've been making changes by directly typing SQL and inserting it into the theme in appropriate places, then having the script die() so I can see the output of my SQL.
Suddenly it hit me that I could find a plugin which integrates phpMyAdmin functionality into WordPress. So I installed wp-phpMyAdmin.
Everything seems to be going well until I try to actually DO anything. I can view the tables, view the rows, and look at everything. But when I try to edit a row or delete a row I get redirected to a 404 error, saying that whichever part of phpMyAdmin I happened to be accessing (for example, tbl_row_action.php) doesn't exist. If I go directly to these pages without submitting the form to edit or delete a row then they work just fine and I receive an error message that my SQL query was blank.
Has anyone else experienced this? I really can't figure out exactly why or where it's sending a 404. It's absolutely ridiculous.
EDIT - A little further information:
I've learned that I only get a 404 error when phpMyAdmin calls sql.php with the sql_query parameter set
EDIT (again) - One further update:
I only get the 404 error when sql_query contains a valid query. Looking through sql.php (I haven't spent TOO much time looking, mind you) I do notice that it seems to parse the query and determine if you're SELECTing, DROPing, DELETEing, etc. so they can check your user permissions. It may be related to this parsing code.
The following queries did not give me a 404:
test
SELECT test
SELECT test FROM test
SELECT test FROM post_meta
DELETE
DROP
DROP test
The following gave me a 404:
SELECT * FROM test
SELECT * FROM post_meta
DELETE FROM
DELETE FROM test
DELETE FROM post_meta
DROP TABLE
DROP TABLE test
MORE EDITS -
So at the very top of sql.php I placed this line of code:
die("Test");
It doesn't die when I make the bad queries listed above. It goes straight to the 404 message. Clearly this is something to do with WordPress's redirect script and not with phpMyAdmin
FINAL EDITS -
I've done a lot more research and been grep'ing the heck out of WordPress.
I highly suspect that I am having this issue as the result of some new WordPress security feature. Older versions of WordPress apparently used to allow SQL to be input into URL's, which posed a HUGE security risk. As a result it's understandable that they wouldn't allow SQL to be passed through URL's now. Just before the template the value of is_404() is being set to true. It's being set within WP::parse_request() (which is called by WP::main() which is called by wp() which is called within wp-blog-header.php)
Any time there is a suspected SQL query ANYWHERE in the requested URI, I get kicked to a 404 page. I would like to change this behavior while making as few modifications to WordPress core as possible. I need someone who is really good with WordPress to help me here. I presume an answer exists involving the $wp_rewrite variable, which contains a multitude of URL rewrite rules.
PROBLEM FINALLY DISCOVERED -
For anyone interested who finds this post or was following it or simply had similar issues, I finally located the source of the 404 errors. It didn't lie with WordPress at all. The problem fell to mod_security, an Apache module which prevents any requests that look suspicious (including those with SQL in the request URI)
Always remember to set your mod_security settings properly.
WordPress shouldn't be interfering with phpMyAdmin, since the plugin loads it in a isolated iframe.
As one of his specifications for the project he wants ONLY WordPress installed on his server...
The plugin is, nonetheless, still phpMyAdmin (albeit 'wrapped' in the WordPress UI). In other words, you've already installed it ;)
...to avoid the hassle of updating and maintaining other software...
'Software' can be a dangerous term when talking web-apps - that's not to say don't use it at all, but for some it can conjure up thoughts of blue screens and runtime errors ;)
In other words, just stress that PMA is simply a collection of files on the server - it has no database of it's own, it's effectively stateless, and removal is as simple as RMD /phpmyadmin.
...he wants to be able to make all necessary administrative changes from the WordPress Dashboard
Despite the points I've already made, if it is absolutely essential that there is database management access within the dashboard, I'm about to write a quick alternative that uses phpMiniAdmin instead (that's how I stumbled on this question oddly!), and I'd be happy to share it for you to try out.
As #molnarm pointed out in the comments, why not just removed phpMyAdmin and connect to MySQL over SSH, using something like MySQL Workbench or Sequel Pro.
You would have a much easier and faster way to interact with MySQL and could delete the nightmare that is phpMyAdmin.
I've got a localhost implementation of WordPress using xampplite for Windows.
I'd like to reset my site back to the way it was when I first installed wordpress (no posts, no settings, etc).
I need to do this so that I can test a base install against my wordpress theme updates.
Any help, much appreciated!
Perhaps i can just reset the options table?
Drop all of your WP tables, IMO. If you export them first you can restore the settings. Or you can edit your WP configuration and change the table prefix.
The simplest way to get an installation that will be exactly like the first time you installed would be to... re-install ; from the start -- which means with an empty database.
This will make sure everything is deleted : settings, posts, ... nothing will survive, if you drop all tables from your database.
That's what I generally do, in this kind of situation (Even if it's generally not with wordpress, but with other software).
And if you really want to be 100% sure, you could also delete all the source files ; and re-download them -- to be sure there is nothing left from the previous installation.
There's also a WordPress plugin for that...
The WordPress SQL Executioner #
http://justinsomnia.org/2008/02/the-wordpress-sql-executioner/