Daniel Wentsch

Granted, most stuff spread across various social networks doesn't seem important. But I must confess that, from time to time, I simply like scrolling through my timelines at Facebook, Twitter, Instagram and the like and I wouldn't find it too cool, if all that was gone. I don't want to talk about the actual risk of my data vanishing, rather thinking about alternatives. I remember ideas of online applications like Sweetcron, which had its primary focus on collecting the data you created across social networks and gather them in one place.

Why shouldn't we do it the other way around? Having you own self hosted platform for Tweets, Images, Blogposts, Links, Quotes – you name it. These would be translated to some basic content types, quite similar to Tumblr. And then simple publishing options checkboxes to decide, to which social stream(s) you want to share your update. Which fantastic open source software has most of the bits and pieces readily available for exactly that? Yep, that's Drupal.

At least to me a Social Media Hub Drupal Distribution seems really worth a shot. What do you think? Have there possibly even some efforts been made?

Fluxkraft is most definitely the project to watch when it comes to connecting various platforms and services.

Of course, thinking about mobile is crucial. Besides Drupal 8's native mobile efforts Drupad shows, that it's well possible to have a universal app to use with any kind of Drupal installation.

This is just some brainstroming, collecting ideas and possible tools. I'm just excited about going back to a more open and distributed web, keeping what's yours under your control while using existing networks for distribution and interaction. And yes, removing Facebook comments in favor of Drupal's own comment system is a step that's overdue for me here personally.

I'd be glad to hear some opinions.

Let's say you have a multisite installation with several (sub)domains pointing to the same document root. Now, you want to protect private.domain.com with ht-authentication while www.domain.com stays publicly available. Please welcome Apache's setEnvIf as your friend:

AuthName "Private" 
AuthType Basic 
AuthUserFile /var/www/.htpasswd
require valid-user

SetEnvIf Host private.domain.com secure_content

Order Allow,Deny
Allow from all
Deny from env=secure_content

Satisfy Any

Source: http://stackoverflow.com/a/6953716/93261

Enter the following code inside a terminal window and those annoying duplicates are gone!

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user

I guess most Drupal site builders have had issues with cron being stuck from time to time. On a recent project I again had this issue and it seemed to be really relunctant to go away by just deleting some cron_last entries. So I dug deeper and found the Cron Debug module. Cron Debug allows you to run each cron hook individually and track the time needed to execute each hook. This helped me to quickly identify the search index hook being the cause of my troubles, as it always caused an error 500.

So it seemed pretty obvious that some or several bad nodes were causing the problems. Thanks to this (blog post on tappetyclick)[http://tappetyclick.com/blog/2013/01/14/how-find-bad-node-makes-search-i...) I found the following snippet which simply writes a watchdog entry for every node being indexed. So when cron gets stuck, the last node mentioned in your log is highly probable to be some kind of problematic. For me it was a node that had some base64-encoded images inside a textarea. Probably some crazy CKeditor feature that tries to enable copy & paste for images, but that's a different story.

Anyways, here's the snippet for modules/node/node.module: Notice: you just have to add the line watchdog ('cron', "indexing node {$node -> nid}"); at the right place. Don't forget to revert your changes when you're done identifying your evil nodes!

/**
 * Implements hook_update_index().
 */
function node_update_index() {
  $limit = (int)variable_get('search_cron_limit', 100);

  $result = db_query_range("SELECT n.nid FROM {node} n LEFT JOIN {search_dataset} d ON d.type = 'node' AND d.sid = n.nid WHERE d.sid IS NULL OR d.reindex <> 0 ORDER BY d.reindex ASC, n.nid ASC", 0, $limit, array(), array('target' => 'slave'));

  foreach ($result as $node) {
    watchdog ('cron', "indexing node {$node -> nid}"); // ADD THIS LINE
    _node_index_node($node);
  }
}

Check if you've some max-width applied to all of your image tags and reset it for all images inside your maps wrapper! I just lost some hair trying to resolve this...

img { max-width: 100%; }
.geofieldMap {max-width: none; }

Using jQuery to determine if there's any element with a certain class on the current page:

    // check if an element with class 'footable' exists, then call footable() on it
    if($('.footable')[0]) {
      $('.footable').footable();
    }

Source: http://stackoverflow.com/a/5783355/93261

... you have a plethora of possible causes to check. One possible reason is wrongly encoded modules being present. As this wasn't the case I also checked the line endings of my modules – and found I had some custom modules written on windows and being set to DOS/Windows line endings. After I changed those files to LF/UNIX line endings Admin Menu seems to be around to stay. Hooray \o/

As announced in my previous entry I created a small module to provide Drupal integration for an awesome responsive lightbox script called Swipebox.

An early and unstable but basically working release can be found in my sandbox over at Drupal org. Most credit goes to the creaters of the great fancyBox module, and, of course, the author of Swipebox itself. I just glued it together to be easily used from within Drupal's field configuration.

Swipebox looks really sweet and works well on both classic computers and touch devices. I'm considering to give it a shot and maybe try to take the time to write a little Drupal module to provide field formatters for swipebox!

Features:

• Swipe gestures for mobile
• Keyboard Navigation for desktop
• CSS transitions with jQuery fallback
• Retina support for UI icons
• Easy CSS customization

http://brutaldesign.github.com/swipebox/

I just found myself with the task of excluding search robots from one site of a multisite Drupal installation while keeping the other site fully crawlable. As multisites share a single code base per definition there is obviously only one robots.txt for all sites inside a multisite installation. Eli suggested a great way of overcoming this problem by simply using a domain based rewrite rule. It takes not even a minute to implement and works smoothly \o/

RewriteCond %{HTTP_HOST}    domainone.com$ [NC]
RewriteRule ^robots.txt      robots_for_domainone.txt [L]

RewriteCond %{HTTP_HOST}    domaintwo.com$ [NC]
RewriteRule ^robots.txt      robots_for_domaintwo.txt [L]