MySQL

Create RSS Feeds of Search Results with Views 2

Varun — Mon, 09 Nov 2009 17:07:39 -0500

Recently, while working at requirements for a Government client I was tasked with finding a way to create rss feeds for site wide searches. Here, I've decided to share this solution with the wider community.

Being able to subscribe to search results with RSS is useful to sites such as twitter.com where there is a large amount of content or frequently updated information. When a user may only be interested in a small sub-set of all this information, it may be useful to offer them an RSS feed. RSS feeds help to make it more convenient for people to stay up to date with changes to content on a website.

To accomplish this, I've used Views 2 to create a new search page for performing a site wide search. In addition to views, the following modules also had to be enabled: PHP input filter, Search, and Views UI. In this example, I've used the devel generate module to generate a large set of nodes on which to test my search.

Step 1. Build the page view

The page view will replace the core search module's search block and page. Begin by creating a new page view. As fields, add "Node: Title" and "Node: Teaser". As filters, use "Node: Published" and the important one, "Search: Search Terms". This search filter hooks into the drupal core search and must be exposed to allow users to enter search terms. I've set the path as 'search-site'. It is also advisable to turn the pager on(It comes in handy later).

Add "Search: Score" under sort criteria and ensure it is set to descending.

Note that search results are only indexed when CRON is run. If you are not seeing any results, please run cron.

Since we want to direct users to our new search page, the core search block should be disabled.

Step 2. Build the rss view

Next, we add a feed display to the view. Most of the settings will be the same as those of the page view, however, in addition, we must also set "RSS Feed" as the Style and "Node" as the Row Style(under basic settings). I've set this path as 'search-rss'.

Step 3. The PHP used to tie them together.

So at this point we have two pages we can look at, YOURDOMAIN/search-site and YOURDOMAIN/search-rss. Both of their content changes based on text which is passed in through the URL where "keys" is set as some text after the ? in the URL.

To put these two pages together we must create a link from the 'search-site' page to the 'search-rss' page so that variables that are being passed in through the URL are preserved. To do this I've added the following PHP to the header of the views page that was set up.

<?php

$view = views_get_current_view();

$rss_url = 'search-rss?keys='.$view->exposed_input['keys'];
$rss_icon = theme_feed_icon( $rss_url , $view->exposed_input['keys']);
echo "<div>";
echo "<p>Current search yields ".$view->total_rows ." results. " ."<br/>Save your search and get periodic updates ".$rss_icon ;
echo '<span><a href="http://www.whatisrss.com"> [What is this?]</a></span></p>';
echo "</div>";

?>

The code simply grabs the current view's exposed input ("keys") and creates a link to the rss page. theme_feed_icon() creates that nice orange RSS symbol for me.

The variable $view->total_rows is only available when pagination is enabled.

The result is a new search page for the site that will also give you an rss feed based on the terms that were searched for.

An export of the view is here.

Here are two more screenshots:

Splitting up Unweildy Database Dumps/Exports

ethan — Tue, 23 Oct 2007 13:26:11 -0400

I recently found myself in possession of a huge (~1.5GB) MySQL dump that I needed to restore after a system reinstall. When a text file gets this large, it is very difficult to edit or even view, as text editors simply can't handle the size. Fortunately, I figured out a simple way of separating the single file into separate databases that could be viewed or imported individually. It works because a typical database dump first creates the database, then the tables, then inserts the data into those tables. It does this sequentially, for one database at a time. My solution simply uses the csplit (Standard in GNU/Linux, OS X) and a regular expression searching for lines starting with "CREATE DATABASE".

csplit -k -f db -n 2 dump.sql '/^CREATE DATABASE.*$/' {50}

The arguments are well documented, but the important one is the regular expression, '/^CREATE DATABASE.*$/'. You'll see a number of files titled db00, db01, etc. which contain the SQL queries required to restore one complete database.

You can then use phpMyAdmin or the mysql command-line to individually import each database. If these prove unsuccessful, a php script named BigDump might be of use.

Troubleshooting MySQL Dumps and Imports

stevem — Thu, 28 Sep 2006 17:42:46 -0400

The various versions of MySQL are more or less compatible with one another, but problems arise pretty regularly, especially when it comes to moving between versions of MySQL. Here are some notes about common MySQL dumping and importing issues, particularly those relevant to Back-End, Drupal, and CiviCRM.

Reserved words

Reserved words can change from release to release. Problems with reserved words in table and field names (BE has a few) can be solved by adding --quote-names to the mysqldump command:

mysqldump --opt --all-databases --quote-names -u username -p > dump_file_name

InnoDB problems

Problems also arise with older versions of mysqldump when there are InnoDB tables with foreign keys (as in the case of CiviCRM). The problem is that the foreign key must exist and be indexed, which might not yet be the case on an import. The MySQL manual notes that if mysql dump doesn't include a statement disabling foreign key checking, then it can be done manually from the mysql CLI as follows:

mysql> SET FOREIGN_KEY_CHECKS = 0;
mysql> SOURCE dump_file_name;
mysql> SET FOREIGN_KEY_CHECKS = 1;

Upgrades

The above steps will already help with this, but importing data from an older version of MySQL into a newer requires using some additional tools to make sure the tables are correctly updated to the new specs. The latest versions of MySQL (5.0.19+) offer the mysql_upgrade command that does this. If it's not available (as was recently the case on MySQL 5.0.18 on SUSE 10.1), run these commands:

mysqlcheck --check --all-databases --auto-repair
mysql_fix_privilege_tables

Auto increment

Apparently the versions of mysqldump included with MySQL versions 3.23 and 4.0 don't properly mark autoincrement fields, which can wreak havok with Drupal installs. Fortunately, there is a simple fix for this problem in Drupal here: http://drupal.org/node/65665.

Another autoincrement problem arises when the value '0' (zero) is inserted into an autoincrement field; by default, MySQL attempts to set this field to '1' (one), which can cause problems if a subsequent statement also tries to insert that value. The workaround for this is to temporarily turn off MySQL's usual handling of autoinsert fields with the statement SET sql_mode='NO_AUTO_VALUE_ON_ZERO'.

I recently combined this with the above fix for foreign key checking as follows:

mysql -u root -p -e "SET SESSION sql_mode='NO_AUTO_VALUE_ON_ZERO'; SET FOREIGN_KEY_CHECKS = 0; SOURCE /home/stevem/mysql_all.sql; SET FOREIGN_KEY_CHECKS = 1;"

Passing the SESSION keyword makes it explicit that the sql_mode is set only for this one client connection.