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).
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.
Unfortunately the 1.x version of Badbot only supported protecting the user registration form, and was not compatible with the dozens of other, equally vulnerable forms available for anonymous "consumption."
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.
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.
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.
Yesterday I got such functionality working by using the often-unknown custom_url_rewrite_outbound() function.
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/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!
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!
Let's start off by opening
template.php in your theme's folder. If you do not have this file you're probably using a theme that is not powered by the phpTemplate templating engine, and as such, this tutorial will not be of much use to you.
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.
Sometimes we need to have certain blocks to always appear above or below the content, so let's add a few new regions!
For Drupal 5.x:
template.php file in your theme's folder and add the following function:
- Page 1