questions
How to encourage readers to share content?
I am creating a new site whose topic will encourage readers to "share" specific pages' content with other people, by means such as:
* forwarding the page content to others
* pasting the page content into email (or into other sites' forums, comments, etc.)
* pasting the page URL into email (or into other sites' forums, comments, etc.)
I'll also encourage readers to leave comments on pages.
That's all nothing special so far, and nothing that a reader can't do from any generic Drupal page.
Click here and read more!I've only got a start at answers, and would love to see more ideas. Interactivity is what many sites are all about; how to implement interactive features in Drupal is no mean question for us developers!
My desired interactive links, in order:
1. "Forward this page" link
For now, I'm cheating. I have a "share content" block appear on pages of the node type which I want users to share. In that block, I have a "forward this page" item which links to #forward-form . That's simply the anchor link to the "forward this page" form provided by the Forward module; a user click, and jumps down the page to the form (which he might otherwise not immediately see, if the page is long).
It's not the same as a link that jumps to a "forward this page" form on a new page, but it works for now.
2. Copy this page's content (for pasting elsewhere)
No go. A little research shows there are solutions that work for some browsers, but I see no universal solution. Further, the business of tinkering with users' clipboards touches on security issues; wiser users may purposely block such tricks by web sites. I think I'll give up on this.
3. Copy this page's URL (for pasting elsewhere)
Same as above.
4. Add a comment
Similar to 1) above, I've simply added a link to the comments section's anchor at the bottom of the page, which is #comments . The user clicks, and jumps down the page to the comment input form. Good enough.
So. There are some cheap'n'quick means for making "interactivity" links more readily accessible to users via a block that gathers them together. I'd love to hear more ideas on this topic!
What are general methods to enable fields for input by visitors?
Drupal's many node types are great for making all kinds of content, and CCK multiplies the possibilities many times over.
One thing I can't quite grasp, though: Is there some general, built-in method for enabling individual fields that allow visitors to input data?
To clarify that, let me first note what I'm not talking about:
Click here and read more!How to display message (NDA, warning, etc.) before content can be viewed?
Say a user wishes to view a certain piece of sensitive content. How can we have the site first respond with a notice, before the content can be viewed?
Specifically, I'm looking to have the site respond with a simple NDA (Non-Disclosure Agreement) before displaying certain nodes (and even then, only to registered users, of course). But I can imagine many more uses: displaying conditions and terms related to the content, displaying an age warning for... er, more delicate content, and so on.
Click here and read more!What options to check when exporting database from phpMyAdmin?
Benevolent correspondent Jason asks:
Which is appropriate to be 'checked' under "structure", when backing up a Drupal database in phpMyAdmin, from the options below?
-Add DROP TABLE
-Add IF NOT EXISTS
-Add AUTO_INCREMENT value
-Enclose table and field names with backquotes
-Add CREATE PROCEDURE / FUNCTION
The procedure I use to back up a database is the Export function in phpMyAdmin: export the whole online database to a single compressed file, and when/if the database needs to be restored, import that saved file back into the online database. The whole procedure wasn't immediately clear to the phpMyAdmin newbie I was at first – and to be honest, I haven't learned a heck of a lot about phpMyAdmin in the meantime – but a little poking around showed the export procedure to be easy.
Here's my export page:
In response to the question, I've always had three of the "Structure" options checked by default when I've exported databases, and never had trouble exporting or importing (despite heavy use of contrib modules).
The three checked options, as shown in the image:
-Add IF NOT EXISTS
-Add AUTO_INCREMENT value
-Enclose table and field names with backquotes
Left unchecked:
-Add DROP TABLE
-Add CREATE PROCEDURE / FUNCTION
I don't know of specific circumstances that would require me to change the Structure selections – or anything else under "Options" – so I've never touched them. I just make one vital click: "Select all", under "Export", so all of my database's tables get exported.
Moving on to the bottom of the page:

I click "Save as file", select a form of compression (the exported files can be too big to re-import, otherwise!), and hit "Go". That's it: one backup file saved to disk, to be squirreled away (and studiously backed up again to an external drive!).
The above works for me. Backups are dead serious stuff, so be sure to experiment, and consult with a phpMyAdmin expert if possible, to see whether the right procedure for you calls for some changes.
Why doesn't Google web search work?
(I asked and answered this question elsewhere on my site, before creating the Question Bank. I'll repeat it here in the Bank for completeness.)
Recap
As described earlier, I've placed many a Google web search block into Drupal sites, using Google AdSense for Search.
https://www.google.com/adsense/search-settings
All to a single end: the blocks don't work. (Hey, consistency counts for something, right?)
As I detailed, both Google and Drupal (even with clean URLs implemented) want to use q in the search parameters toward conflicting ends, resulting in goofiness. One suggested solution is to replace the problematic q in the search code with as_q, something Google and Drupal will both accept but not fight over. (Saintly correspondent jGirlyGirl informs me that query works as well.)
Alas, my problems only half-disappeared: with the code tweak, on-site searches worked fine, but web searches would only return "Your search... did not match any documents."
Hacking...
I hacked much yesterday, trying all sorts of little tweaks to the search code. I then came up with the brilliant strategy I should have thought of weeks ago, which was to check out some sites with working Google search blocks. I even hit upon the perfect candidate: the excellicious 43 Folders site by burgeoning Internet hero Merlin Mann.
That site not only employs an AdSense for Search block for both on-site and web searches, but it's a Drupal site as well! (Let 43 Folders, not The Onion, be our new poster child for Drupal sites.)
With that specimen laid out before me, I sought to employ the single most valuable technique known to me as a programmer. That's right: copying other people's code.
I viewed the source code for 43 Folders' search results page, and compared with my own. Hmm, 43 keeps the unadorned q in its search parameters; apparently, Merlin solved that problem at the .htaccess level or elsewhere. Yet as_q should still work for me, as it has for many others. I see, too, that 43's code specifies its search results page with a trailing "/", while my code does not. Was that the problem? No, tacking a slash onto the end of the page URL in my code didn't fix things (in action, the slash just gets stripped out of the resulting URL anyway).
And so on. I noted every difference I could find. I even went as far as nabbing 43's search code wholesale and pasting it into my Drupalace search block, changing only the obvious particulars like my domain, my search result page URL, etc. But every variation I tried resulted in some error: either a "Your search... did not match any documents" result or a "page not found" result, for on-site search, web search, or both.
"Why will this same code work for him, but not for me? Aaaarrgggghhh!!!!"
See progress (if not quite a solution) here.





Thank you for including my blog post.
Geshan
...
thanks for the link.
حلول
...This is a fantastic resource and obviously a lot of work - thank you very much indeed!
It looks to me as if #1 and #2 are handled by general Drupal permission features. #3 should be...