Within the Lift ecosystem, "contexts" can be thought of as pre-defined functionality that makes data available to the personalization tools, when that data exists in the current state (of the site/user/environment/whatever else).
Here's a handy tip to make Varnish ignore a subdomain and not cache its contents: modify your .vcl file to include the following:
sub vcl_recv {
if (req.http.Host == "sub.domain.com") {
return (pipe);
}
}
Creating an authentication system within a Single Page App (SAP) can be a bit tricky; hopefully this post will help alleviate some of the challenges. Before you begin, it's a good idea to set up your environment so as to decouple the front and backends. There's a good post explaining the process over at StackOverflow. (The StackOverflow answer deals with a Laravel backend, but the code is easily modified for any other backend service.)
Packt Publishing recently got in touch, asking me to review their new book, Learning Laravel 4 Application Development by Hardik Dangar. The timing was nice as I'm currently developing my first application on Laravel 4 (having had some light experience with Laravel 3), and more resources for documentation are never a bad thing.
I recently introduced the DevTools module, and today I'm going to show you one of my favourite components, dialog, which builds upon the Dialog module (fear not the 7.x-dev version, it's perfectly stable) and allows you to present single- or multi-state forms in a modal.
Dev Tools is a little-known module, which I published a little more than a year ago. As the description states, the module is a "collection of PHP classes and functions which help with and simplify Drupal module development." Sounds pretty vague, right? Hopefully this post will clear things up!
I've been developing with Drupal since the late 4.6 days (that's over seven years) and have been involved with hundreds of Drupal projects. Over this time I've been exposed to just about every type of project you can imagine, from mom & pop blogs, to government intranets, ecommerce sites, massive document libraries and social networks. While at the end of the day all projects got completed, some of them would have been much better-off being built on something other than Drupal.
Some time ago I released the Badbot module. This module introduced a new way of blocking spambots, and the community response has been incredbly positive. Quite simply: it works.
François Fortin's blog post rang true, so here's a few more cents...
Bad programmers aren't the root of all evil. Apathetic programmers are.
A few weeks ago I decided to rebuild this portfolio/blog site. The old site was running on Drupal 7, and I had long tired of the design; it was somewhat slow, too. Add to the mix a bit of boredom with the status quo and a desire to try something new and "lightweight," I downloaded the Laravel (v3) framework I'd been hearing so much about.
If you're getting the “Unable to send e-mail. Please contact the site administrator.” error on a Drupal site that's hosted on an Ubuntu server, there's a good chance you don't have postfix installed. Resolving this is quite simple:
sudo apt-get update
sudo apt-get install php-pear
sudo pear install mail
sudo pear install Net_SMTP
sudo pear install Auth_SASL
sudo pear install mail_mime
sudo apt-get install postfix
As part of converting my site from Drupal 7 to Drupal 8, I ran into an issue with the core CKEditor not supporting [code] tags. The tags display fine after the intial node save, but get filtered out on subsequent node edits, regardless of the "Limit allowed HTML tags" option in the text format settings. Google turned up various discussions dating back to Drupal 6 days with this very issue, with finger pointing between Drupal, CK Editor module, and the CK Editor library itself.
If you're used to relying on $_GET['q'] from Drupal 7 (& earlier), you might be in for a surprise with Drupal 8, as $_GET['q'] is no longer defined for any request. Instead, Drupal 8 ships with a series of helper functions:
current_path() - returns the internal Drupal path (ex. node/123)
request_path() - returns the alias (ex. blog/my-post)
base_path() - returns the base path for your Drupal site (ex. /mysite/, if your site is accessible at foo.com/mysite)
request_uri() - returns the full URI, including base path, alias, and any query arguments (ex. /mysite/blog/my-post?foo=bar)
Every webmaster has encountered spam; from account registrations, to contact form submissions, spam bots are constantly on the prowl for new targets. The usual approach to combating such bots is with one of the many available captcha tools, but they are all far from perfect, and with the abundance of services that have warehouses full of real people entering captchas all day (for spam bots to then use), they are often rendered useless. You can change the type of captcha used and you can add new ones every day, but that only leads to a game of cat and mouse with the spammers targeting your site, and wasted time on both sides, not to mention annoyed users. The simple fact is that captchas are not effective in combatting spam.
A few weeks ago I wrote a helper module which allows you to automatically export contexts created via the Context module into code, and then instantly provide them as default contexts. I've just released this module on Drupal.org.
It is a very common need to be able to enter a menu path similar to user/[uid]/profile in the Drupal menu system, ([uid] being a dynamic argument for the user's id) but that's not possible out of the box, and there are no modules which provide this functionality.
Domain Access is a module which allows you to simulate Drupal's internal multi-site functionality; it is easy to set up, and even easier to use. This is (by far) the simplest way of sharing content (and users) between multiple sites. One of DA's downfalls is that it does not work with subsites in subfolders, meaning the structure of site.com and site.com/subsite is not supported. Due to very specific client needs, my project required just that - subsites in subfolders. "Not supported" was not an acceptable answer, so... here is my solution:
I just encountered a strange issue while switching between two development branches of the same Drupal site. On branch A the site worked normally, but on branch B none of the forms contained any fields. After much hair pulling, I narrowed down the difference between the two branches to a drupal_rebuild_theme_registry(); call in my theme's template.php file on (the working) branch A, and realized what was going wrong.
Any seasoned Drupal developer has undoubtedly, at one point or another, come across the infamous "white screen of death" (WSOD) issue. While there are many documented (common) potential causes for this problem, today I encountered a new one, and just like all the ones before, it was a huge pain to find it!
This command will move all files & directories to the parent directory:
find . -maxdepth 1 -exec mv {} .. \;
... it will throw a warning when trying to move the current (.) directory:
mv: cannot move `.' to `../.': Device or resource busy
Every developer knows and loves GREP, the great search utility available on all Unix-based systems; while it does a great job searching, the options are a little lacking. One such option is restricting the search to only specific file types/extension. Luckily that functionality can be easily wrapped up in a handy script.
Today, while working on a new Drupal 7 site, I somehow managed to lock myself out. I knew the admin (UID=1) username, but could not for the life of me get the password right.
One of the most common questions on Drupal's theming forums is how to create an individual layout for a specific page or node. In this tutorial I'll show you how to do just that!
By default, Drupal comes with 5 content "regions": header, footer, left sidebar, right sidebar, and content. In many cases it is convenient to have several additional regions for more granular control over content location.