Drupal search module - rendered pages instead of nodes? - drupal

Is there a module for Drupal that searches the final versions of the rendered pages (in the same way that Google would, for example) instead of all the nodes? The way I have set up my site involves views that display several nodes depending on what the page is. I don't want to search through each of the little boxes, but the finished version of the page instead.

For clarification, you are searching for a way to index the dynamic view content, and keep the search index out of the individual nodes?
I think your best bet is https://drupal.org/project/search_config
A lot has been added to Drupal 7 core, so that many 'search restrict' modules are now obsolete.
If this is still not what you are looking for, and you feel a bit adventurous, you can find various guides from before this was incorporated, and go the way of custom code. http://www.lullabot.com/articles/hiding-content-drupals-search-system
http://www.acquia.com/blog/drupal-search-how-indexing-works
If it is slick and stable, submit it back to the drupal community. They will be your friends.

Related

Simple search on dynamic web app content

I'm looking to implement search functionality in an ASP.NET MVC site.
The site is driven by a CMS. The users can add widgets to the page with meetings, documents, etc.
So the whole site is fully dynamic.
As I see it, there are 2 options:
Search all possible content directly, and then figure out what results are coupled to pages. Or the other way around, figure out what the content of a page is.
Load or construct all available pages, and make sure the content can be searched. So, basically crawling and indexing my own content.
Maybe other?
I'm not sure what the best implementation would be, all experiences and directions are welcome!
I'm not really looking for Solr or Lucene based solutions. This needs to be a simple implementation, just running a LIKE on the correct rows of the DB is suffictient.

Ways to share a "Top X" list between two Drupal websites?

I'm trying to come up with some easy methods to share data between two Drupal websites. Here's my situation: Two websites both want a Top X Music listing with images, audio and data. One website is already creating and updating this list, and since they both use the same list the other website wants to straight up "steal" the first list, content, style and all. They want to take advantage of the work done to create the list on the other website. Their websites are structurally similar, and we control both sites. Audio is made playable using SWF tools.
Domain isn't really an appropriate solution here as the two sites share nothing besides the Top X Music list. I am able to create a view on the original site to feed the data in any format I want.
Some solutions I've been considering are:
Feed the data from one site to the other, hard link back to the other
site for audio/images.
iFrame the data on the site that is "stealing"
the list. (easy but seems too crude!)
jQuery AJAX load the data on the "stealing" site.
Basically I'm looking for suggestions of how you might handle this if they were your Drupal websites. I am familiar with Feeds, but would need to write a parser specifically for this feed, which seems like overkill for something so simple. Thanks! :)
You don't mention what version of Drupal you're using on the two sites. Assuming it's Drupal 6, you may want to check out the Web Widgets module and/or the Embed widgets module.
If you're just after a list of content from SiteA you could add a display to a given view and get RSS output. The ViewsRSS module gives you more control over what is returned.
If you're looking for more of a widget approach then I'd start looking at the Web widgets or Embed widgets modules. They're ok for basic functionality, but if you're looking to want more functionality I'd consider either embedding the content in an iframe (quick and dirty) or reviewing the services module(s) - although this may be overkill for your needs.
HTH.

Migating from CakePHP to Drupal, functionality question

(I've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.

Drupal Hierarchical Content

I am currently looking at using either the Taxonomy or CCK module on my Drupal site as a means to create a hierarchical system. However, I'm a little confused on which one would best suit my needs, or if there is something else that would work better.
Basically, there will be probably 70 or so "mini-sites" on the website I'm working on, each with a landing page and about 5 sub-pages of detailed information. I need a way to mark those sub-pages as being sub-pages of their parent page, as well as create a menu system to navigate between them.
What is the best way this could be done? Thanks for your input!
Have you tried using the Book module? It might take a bit of theme-adjusting to get it to look right it seems to be how most people settle on displaying this type of page structure.
Depending on your needs, Organic Groups and/or Spaces can be a good alternatives, since it'd allow you to easily control themes, permissions and other settings in a mini-site basis.
Each Mini-site would be an OG node and/or a space, and subpages could be organized in tree structure as well, using Book module from Drupal Core.
The best option is the book module. It gives a way to organise hierarchical content in a book manner. There are 2 blocks generated automatically: the book navigation and the book outline which gives, for each page, a link to the previous and the next content.
For more information drupal handbook: http://drupal.org/handbook/modules/book

Possible pitfalls on a multilingual Drupal site?

I'm about to embark on a journey to build a multilingual Drupal site, where I will most likely have to use Views, Panels and Taxonomy pretty heaily. I am a bit worried about the new-node-for-every-language approach, especially using Panels.
So far I've gotten it to work similarly to what I want by not having multilingual support for the Panels content-type, and fetching content that is from Current language and language neutral . This seem to work as expected, but I'm seeing some problems with it. There might be the occasion that I will have to have a language specific Panel (not published in English for example). If I need to have all my Panels multilingual, there seems to be alot of work to place the nodes for every column in every page in every language. I'm thinking I could possibly solve this by fetching the content with some kind of view with arguments, but this will most likely also lead to alot of work.
Is there some proper way of doing what I'm attempting to describe, or do I have alot of seemingly unnecessary work to expect?
I assume you have i18n module (http://drupal.org/project/i18n) and Views module installed. Then you can create a view for each language - one can choose language in "Filter" section of the view definition.
Once you have views, then you can link them to menus or blocks. The problem is you must have a separate version of block or menu for every language, with a proper view associated - Drupal is choosing proper language version itself according to the configuration (typically content type set in a browser). I haven't found any easier way of doing that.
Fortunately preparing multilingual content is not that hard thanks to the "transalte" functionality for nodes after enabling i18n module, so new node for every page is something one can live with.
BTW you are right that the way Drupal is doing i18n is not the best solution one can think of. I am having hard time with it sometimes.
Well there are some serious issues with views over translating taxonomy terms or vocabs names. This could be resolved with some extra modules or / and custom PHP code inside views fields. Usually 70% of modules does not support translation, then you need to patch them to support it. While others does have translation possibility, but it could be two possible ways: uses variables table to hold different translations UI dependent (need to switch to other language to find a string) or uses translation field tables to utilize "translation interface" from admin menu.
So far that's it :)
I wish you luck!

Resources