drupal.com.au

On a recent project I required a way to bind ctools handlers to their respective links dynamically. The project had the links being displayed using ajax based on user input, and so the handlers would have to be bound to the new links (and unbound for the links that disappeared) without the page being reloaded.

Searching online for a solution did not turn up any useful results. Digging into the ctools module code, there didn't seem to be any easy way to accomplish this. The handlers are bound on page load, using Drupal behaviours.

Out of the box, Drupal is pretty good at handling files. It has support for subdirectories, and a wide range of tokens which gives you a flexible, easy-to-set-up system for organizing files uploaded by your users. Sometimes though, pretty good isn’t good enough, and we need something more. That’s why Drupal is built the way it is—modular and extensible. The module we need in this case is Storage API.

The fear of writing your own code

We’ve all heard the term Not Invented Here (NIH) thrown around. It refers to a phobia of using technologies that weren’t developed in-house. What some of us might be a little less familiar with is its opposite, Invented Here (IH), which occurs when people are uncomfortable innovating in-house or developing anything for themselves.

IH is a huge problem in the Drupal world.

Why Drupal specifically?

Drupal spreads IH just because Drupal can do so much with so little code (see more about this in my Golden Handcuffs post). Need a customized listing of content with filters? Use Views with exposed filters in the GUI! Need a custom page build with blocks and menus and random crap in a specific layout? Use Panels' page builder in the GUI! The list goes on.

So people see all of these cool things you can do without coding anything yourself, and they hear things like "there's a module for that!" constantly, and they start thinking in terms of contrib instead of in terms of code. The go-to mindset of a lot of Drupal developers, when presented with a problem, is "what combination of contrib modules could do this for me?" instead of "what's the best way to make this, whether it uses contrib or not?"

Why is this bad?

This mindset is harmful because it removes "what is the cleanest/best way to do this" from the list of questions that developers ask, leading to kludged together solutions within a bunch of unnecessary contrib modules that do a lot of stuff you don't want or need.

Let's take a specific example. Say that you need to display a listing of nodes in three columns and you need to add a taxonomy term filter at the top. That's simple enough using a Views with a grid format and an exposed filter for the term reference field. Now say that the filter needs to be checkboxes instead of a select dropdown, but to prevent a wall of checkboxes showing up you have to limit it only to taxonomy terms which have their own "Featured?" checkbox field checked. So you add a new exposed filter and add the Better Exposed Filters module to output it as checkboxes. Then you try to add a relationship to the taxonomy term to add a filter for the Featured field but the client complains that that also filters the nodes returned which is wrong. So you'll have to undo that and dive into the Views API and hook into the exposed filters and make that happen. And then the client comes back and says that she wants the number of columns to change depending on how many results there are. So now you'll either have to override a template or hook into the view rendering and change the number of columns setting on the fly based on the number of results. This is the part where you quit your dreams of web development and go to clown college or apply at Subway. And you haven't even seen what was coming up in the next phase.

So you started with an accepted contrib module and added more and more crap on top of it until it became a big unmaintainable mess. We've all been in situations like this where a contrib module works except for this one thing or that other thing that you have to override or hack or add another module for, and you end up with a solution that you're not proud of and that you dread having to maintain, all because it seemed easiest to start with contrib.

What's the alternative?

It's simple, code it yourself. In the example above, make a custom menu callback that runs an EFQ for the nodes and spits them out in a custom template, and build your own form to do the filtering. It's no more work than a couple hours, probably less time than you would have spent screwing around in the Views API trying to get it to obey you, and you get a solution that you have full control over and that you don't have to be embarrassed by.

Another classic example is breadcrumbs. You can either dig into one of the many breadcrumbs modules (Hansel, Custom Breadcrumbs, Menu Breadcrumb, Crumbs, etc.) and try to find some combination that fills whatever bizarre requirements have been thrown at you. Or you can use drupal_set_breadcrumb() in your hook_node_view()'s and hook_taxonomy_term_view()'s and wherever to do exactly what you need with a few lines of code while avoiding the thousands of lines you'd be adding with any of those modules.

Reinventing the wheel

For some people, leaving behind all of those contrib modules is a tough sell, because contrib is really one of the great things about Drupal. If you're going to reinvent the wheel on CMS features and just use it like a framework instead of like a CMS, they say, then why not just use Django or Rails? My answer to that is that you're still getting the best out of Drupal, you're just getting it from a different place. Instead of milking Views and Panels and Hansel and Context for all that they're worth, you instead milk entities and permissions the Bean module and EFQ and FAPI and DBTNG and fields and hooks for all that they're worth. Django and Rails just don't have equivalents for a lot of that.

Plus it's not like you have to ignore contrib completely. You still have amazing things like Drupal Commerce and OpenLayers at your fingertips, and you're still open to use Views and Panels and whatever else when it makes sense. It's still Drupal.

In the end, it all comes down to two things: building things quickly and buildling things well, and if rolling your own features in some cases means that you don't sacrifice on time and you get a bit of a boost in quality then I don't understand the hesitation there just because you're ignoring some modules in the process.

Update and responses

Wow, this post has generated some great discussions. Besides the comments below, also check out the short Reddit thread and the Google+ comments for some really good insight. I wanted to respond to a few common ones:

You're not taking maintenance into account, Mike! If you custom code things, you have to maintain that, and if you use contrib, somebody else does it for you.

I can't argue with the fact that custom code requires maintenance, but I wholeheartedly disagree that using contrib requires little to no maintenance. I've spent way too many hours fighting upgrades that break dependencies or modules that depend on buggy .dev versions of other modules or tracking down an issue for a bug (that may or may not have a patch which may or may not be current or even work) to agree with that statement.

It's technical debt either way, and if you're worried about technical debt that you own then I think you should be just as worried about technical debt that some other unknown dev or perhaps even no one owns.

It's not black and white, you can use contrib where appropriate and use custom code where appropriate.

This is true, and I apologize if my post came across like it wasn't. If you find a solid, well built and maintained contrib module that does what you want well then you'd be a dummy not to use it.

My point is that this mindset of having to use contrib ("there's a module for that!") is dangerous. If you find yourself struggling to find a way to implement a feature with contrib or stretching modules past what they're made for or mushing different modules together in a way that makes you queasy, then that's an opportunity to ask yourself why you aren't just coding it yourself.

Custom code boxes you in. A good contrib module integrates with Views, Services, Rules, etc.

Ask yourself if you really need integration with this stuff. If you do, then ask yourself how much it time it would take to integrate that stuff into your custom module vs. how much time it would take to extend/override a contrib module (which already has support for that stuff) to fit your specs. And then ask yourself how gross the implementation will be either way. At this point you should have a pretty clear picture of what to do--basically go with the one that scares you the least.

Custom code takes longer than using contrib. Think of the budgets!

This is true sometimes, and in cases where this is true I'd probably advise you to use contrib. This post is about cases where it's not true--where extending and overriding contrib takes more time than custom building. I've found that if you really think about it, this happens more often than you'd like to admit.

The rapid pace of open source adoption in the enterprise continues. There’s more at stake for project teams within the enterprise. Projects are bigger than ever before. Here at Blink we continue to engage in larger and more strategic builds - true enterprise scale stuff. Enterprises are prioritizing open source solutions front and center of mission critical business process and for good reason. Open source is obviously license free and incredibly flexible. You also get the power of the “community” at your disposal.

Drupal and howto.

The Date Picker widget, when using webforms, defaultly appears in American form (Month, Day, Year). For UK sites this isn't often desirable. Doing a quick google and I stumbled upon James Davidson's blog post on how to re-theme the element from earlier this year. I thought it was certainly one approach, but felt there must have been a neater alternative. So here is my approach:

In this article I am going to show you how to query for information in a database other than the default one you set up when you installed Drupal. There are 2 main ways to do this properly and choosing one over the other depends of course on your needs.

When people ask you about big projects done with Drupal, what's the second item on your list? I know the first one is WhiteHouse.gov - that's not Drupal's foot in the door, it's the foot that broke the door.

I'd like to share with you the second item on our list. Harvard. Seriously. If it's the first time you hear that Harvard is using Drupal, or that they have an amazing distribution they work on called Harvard OpenScholar, or that they have a team of five developers along with two developers from Gizra and a many others working on it full time, or you are not aware to the amount of contributions given back to the community... You do now.

Continue reading…

In my last post, I discussed my new photography site I'm building and theming with Drupal. The site is responsive and I've been searching for an ideal responsive touch friendly multi-level menu. I looked at and tried several jQuery plugins, CSS3 styles and a few Drupal Modules but nothing was quite right.

The Issue

Part of the issue is that I need multi-level menus that are touch friendly, but many of the menus I looked at had severe UX drawbacks. It's confusing to click (touch) on a menu item, have it expand and then make it go to a link all at the same time. FlexNav, a jQuery menu plugin written by Jason Weaver solves this where it separates a linked menu item from navigation through the DOM itself.

Implementation

So FlexNav checks all the boxes on my touch friendly multi-level menu wish list. This is most of the task but the tricky part is dovetailing this into my Drupal theme. Part of the difficulty when digging into the Drupal API is fully understanding what's going on with the menu and how to alter it, of course without hacking core.

Digging into Drupal's API

I checked out all the documentation of menus within the Drupal API and looked at the code in the core file menu.inc but came up empty with adding an ID, class and attributes to the top level <ul> menu item but not any <ul> tags below it. I figured I could do this with jQuery and it's pretty trivial actually but by doing so the menu was just plain buggy. So that left me with the tried and true preprocess function, the bane of any Themer's existence.

A Solution

In my research, I found lots of people asking how to do this very same task in forum posts on drupal.org and Drupal Answers on Stack Exchange but as is often the case, there were varied and confusing suggestions. Finally I was looking at how the Drupal Bootstrap Theme implements its main menu and bingo, I found a solution that I could trivially implement into my own custom Unsemantic Framework based Drupal Theme. Note that I didn't use Bootstrap's actual menu as I don't like the way it prevents clicking on a top level menu item if it has sub-menu items.

API Functions

We'll be leveraging a few bits from the Drupal API here:

• function menu_tree - To render the full menu tree
• function drupal_render - To attach classes, attributes only to the main <ul> wrapper and not to its children.
• function menu_configure - To build the links and specify the menu we want to theme for FlexNav. (In our case, the Main Menu.)
• function hook_css_alter - This is just for good measure to unset the nasty system.menu.css file that plagues all themers.

The Code

The first bit of code goes into a preprocess_page function in your theme's template.php file.

function MYTHEME_preprocess_page(&$vars, $hook) {
// Primary nav.
$vars['primary_nav'] = FALSE;
if ($vars['main_menu']) {
// Build links.
  $vars['primary_nav'] = menu_tree(variable_get('menu_main_links_source', 'main-menu'));
// Provide default theme wrapper function.
  $vars['primary_nav']['#theme_wrappers'] = array('menu_tree__primary');
}
}

Essentially the above grabs the links tree from the main menu and then creates a wrapper that we can then leverage with function menu_tree as such:

/**
* Theme wrapper function for the primary menu links
*/
function MYTHEME_menu_tree__primary(&$vars) {
  return '<ul class="flexnav" data-breakpoint="769">' . $vars['tree'] . '</ul>';
}

Note the custom class and data attribute here, this is the key to the entire exercise. The beauty in this is, it only gets added to the top level <ul> tag in our menu because we specified #theme_wrappers above. That's crucial for getting this all to work. For good measure, I unset system.menu.css using a hook_css_alter function but that's optional, you just might need to do a few CSS overrides if you don't do this.

Finally in the theme's page.tpl.php file, we render the menu:

 <div class="menu-button">Menu</div>
  <nav class="menu-navigation">
    <?php if (!empty($primary_nav)): ?>
    <?php print render($primary_nav); ?>
  <?php endif; ?>

As always, I learned an incredible amount of knowledge on this after working on this specific problem over the course of a few weeks and I'll be contributing back a lot of this code for some feature requests I have for my theme, Bamboo.

Tags: 

• Drupal
• JQuery
• CSS
• Responsive Design
• Drupal Planet

Resources FlexNavfunction drupal_renderfunction menu_treefunction menu_configurefunction hook_css_alterDrupal Bamboo on dupal.orgDrupal Theming and Design: A Minimalistic Approach[Drupal] BootstrapUnsemanticJason Weaver

This month's Central Denver meetup varied slightly from the normal format. The focus on the meetup was discussing our experiences and thoughts from Drupalcon Portland. As such, the main introduction question was, "Did you attend Drupalcon Portland?" It was nice to see that roughly seventy-five percent of audience had attended, as it left a lot to discuss. We once again provided collaborative notes for members to contribute to and we certainly had a lot more participation than last month. Thanks to whoever created the fun ASCII art at the bottom of the notes.

So here are some sessions that various members found most important and/or exciting to discuss. John Fiala brought up a keynote for this year's Drupalcon, Thriving In A World Of Change: Future-Friendly Content With Drupal, wherein Karen McGrane addresses the very important distinction between storing data and presenting data, and demonstrates how WYSIWYG editing is a relic of the age of publishing; the antithesis of mentioned distinction.

Someone then mentioned Sam Richard and Mason Wendell's session titled Managing Responsive Web Design with Sass and Breakpoint. It's great to see SASS mature into a standard front-end tool, especially when RWD is only becoming more important with time.

Rick Manelius was excited to talk about the Drupal 8 configuration management initiative and all of the fun we'll soon be having with YAML. All of this was discussed at length during Greg Dunlap's session, Using The Drupal 8 Configuration System. This is a huge step in the right direction, and the pains that we've experienced using features and other tools that convert configuration into code will largely become a relic of the past. While this is great for the future, someone mentioned using a settings.local.php to alleviate some of this pain now.

Carl Wiedemann talked potential problems with Drupal 8's architecture, pointing to Mark Sonnabaum's core conversation titled We're Getting OOP Wrong and There's Still Time to Fix it.

And finally, Scott Reynen and I made mention of a couple sessions in that are listed in our Favorite Moments in Portland.

Whew, that was a lot to talk about. Fortunately we also had time to do something a little out of the ordinary. Normally we have a general question and answer portion of the meetup, but this time we asked if someone was willing to have the community help them work through the given problem in real time. We adopted this idea from the South Denver Drupal Meetup and it went surprisingly well. Maida Scott was able to resolve the problem of creating a subtheme out of the Marinelli base theme. It was great seeing the community's collective debuggin mind asking the question, "Why?" and identifying problems before making conclusions. Pro-tip: Drupal's theme and module registry gets confused if it encounters multiple .info files with the same name.

This was proceeded by many hurrahs; some were cheers over food and drink at Interstate Kitchen and Bar.

• drupal 7.x
• planet drupal
• actions
• triggers

To receive an e-mail notification when a new comment is posted, try this (you won't even need to write one line of code):

In this tutorial we would be looking at how to install and configure the timelineJs module/tool in our drupal website. The TimelineJs is an open source tools used for building beautiful and visually rich timelines. You can use it within your drupal website for building content timelines. This module comes with a timelinejs date content type and a preconfigured view for displaying the content type's timeline. It can be used displaying things such as an events timeline, timeline for a countries history, someones musics career and much more. 

Download the timelinejs library from github

The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, since the last Drupal 7 bug fix release was only two months ago and there haven't been many changes added to the 7.x development version since then, there won't be a release this week.

Upcoming release windows include:

• Wednesday, June 19 (security release window)
• Wednesday, July 3 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Field collections are at the same time one of my most favorite and least favorite aspects of working with Drupal 7. Since they are entities they can be extremely powerful and flexible site building tools, and I see lots of unrealized potential in that, on the other hand theming can be tricky and, for lack of better word, generally feels “icky.” There is little documentation online about best practices with almost all links pointing back to this thread on how to theme field collections. The proposed solutions in this thread are a mixed bag — mostly bad — but some that may work, but they certianly don’t follow any best practices in drupal theming. I’ll admit I have shipped field collection theming that, while working, did make me feel “dirty.” Below was a clean solution that — while simple — is maintainable and, hopefully easy to follow.

I created a quick function that pulled out the themed items from the field collection and organized them into an easy to theme array. The theming then felt a lot more natural, like working with a views rows template.

<?php /** * Creates a simple text rows array from a field collections, to be used in a * field_preprocess function. * * @param $vars * An array of variables to pass to the theme template. * * @param $field_name * The name of the field being altered. * * @param $field_array * Array of fields to be turned into rows in the field collection. */   function rows_from_field_collection(&$vars, $field_name, $field_array) { $vars['rows'] = array(); foreach($vars['element']['#items'] as $key => $item) { $entity_id = $item['value']; $entity = field_collection_item_load($entity_id); $wrapper = entity_metadata_wrapper('field_collection_item', $entity); $row = array(); foreach($field_array as $field){ $row[$field] = $wrapper->$field->value(); } $vars['rows'][] = $row; } } }

In this function we pull in the “variables” array from the field template, the field name and an array of fields that we want to extract, and then load them into our own rows array which gets attached to the variables array for use in our template. It uses the entity_metadata_wrapper that is like a swiss army knife of sanity and clean code for Drupal 7. If you aren’t familar with it, start with this documentation page about entity metadata wrappers, and follow up with some quick googling. It’ll make you and your code happy.

Below is the function being called and our custom field template being established. One thing that keeps our code simple is that all fields in the field collection are required eliminating the need to check for the variables existence in the template.

<?php function THEME_preprocess_field(&$vars, $hook){ if ($vars['element']['#field_name'] == 'field_achievements') { $vars['theme_hook_suggestions'][] = 'field__achievements_collected';   $field_array = array('field_award', 'field_award_presenter','field_year'); rows_from_field_collection($vars, 'field_achievements', $field_array); } }

Finally below is the field template.

<?php /** * Field formatter for the field_achievements field collection. */ ?> <dl> <?php foreach($rows as $row): ?> <dt><?php print $row['field_award']; ?></dt> <dd><?php print $row['field_award_presenter']; ?></dd> <dd><?php print $row['field_year']; ?></dd> <?php endforeach; ?> </dl>

We had a number of fields that were just sets of text data that needed to be output in definition lists. The function could be easily modifed to render the fields instead of just the values by using entity_view(). Next steps for this approach would be to refactor to use entity info to get the fields so that it can be generic and would no longer require the need to pass in the fields that you want.

There is hope for theming within the module itself. There is a promising issue in the queue that looks like it makes the native theming more sane. Since it’s such a big change it doesn’t look likely that it’ll make it into the 1.0 branch, so we may need to wait for the next version before it drops. Perhaps there is space for an add-on contrib module that cleans up the theming.

I'm not going to lie  - sending out nearly a million emails announcing that you've had a security issue is no fun. Honestly, it's one of the worst things I have ever had to do in my professional life. It's true that cyber-crime is growing fast, and we are not the only organization to face this dilemma, but this isn't the kind of club membership you want to keep.

Personal blog tags: drupal.orgcommunity

Last week, 17 Forum One developers and strategists joined 3,300 other Drupalers in Portland, Oregon, for the biggest DrupalCon conference ever. We had a “Nodetorious-ly” good time, convening with the Drupal community, learning about the future of Drupal, and exploring Portland.

Many of the session videos are available online. But to save you time, we’ve compiled our top 10 key takeaways from the DrupalCon 2013 conference:   1. Drupal 8! Drupal 8! Drupal 8!  It was amazing to see the progress that has been made on Drupal 8 and the direction it is going. Infused in every session, from Dries Buytaert’s opening keynote, to the breakouts, to the Birds of a Feather discussions, to the happy hours, was excitement and anticipation for the next major release. While much of the front-end appears the same, nearly everything in the back-end has changed (for the better, in our opinion). Using the new APIs and object-oriented code, we’ll be able to accomplish previously difficult changes much more quickly and cleanly. On the administration side, Drupal 8 is making progress as a content distribution tool with digital output services built in. Because Drupal 8 is a far more advanced publishing tool, marketers and web managers will have access to component levels, layouts, and more with Drupal 8.   2. Know Your Content & Context The future will be filled with more devices in different contexts, outside, inside, on-the-go. As Karen McGrane talked about in her keynote, it’s all about how the content is “chunked” in ways that we can push it to our multitude of devices in optimized formats and contexts that are relevant to the users. As much as there is talk about mobile, mobile is just one use case, albeit the predominant one now. Who knows what will happen in the next few years? Voice-activated interfaces will get really good? Smart watches? Drupal 8+ is well positioned to take advantage of this future through its flexibility.   3. Explore Fast, Light Prototyping Through the user experience tracks, we saw that web teams are shifting away from pixel-perfect, static, “heavy” deliverables to lightweight, easily modifiable deliverables. We’ll see more tools for HTML-based, clickable, and interactive experiences over Omnigraffle or Visio wireframes. Speaking of which, Forum One has built a popular interactive prototyping tool for this purpose. Check out Proty.   4. Drupal Isn’t for Everything Obvious? Yes. But we gained a deeper understanding of that statement during the event. It is easy to think of yourself as a “Drupal shop” and forget that other tools may do things easier and faster. Many of the sessions focused on whether or not Drupal is a CMS or a content publishing tool. Informal break-out conversations and other side conversations focused on NodeJS, REST, WordPress, and other lightweight options that only provide content management and user management frameworks. These were great reminders that Drupal isn't for everything.   5. More Tools for Multilingual Translations Because many of our clients have an international focus, we learned about the many new tools and modules that aid in building multilingual sites. We’ve built many multilingual sites, and shed some blood and tears in the process. Thankfully, many more tools are emerging to make the job easier. A great session on multilingual in Drupal 7 pointed me to a bevy of Drupal modules that make the process a lot easier and more user-friendly.   6. Know Your Content Strategy Several sessions mentioned NPR’s COPE (Create Once Publish Everywhere) strategy. It’s again about making content publishing future-proof and device-accessible. Drupal’s future will look like a system that allows site-builders to model all different types of content, users, and context. Representing these three things accurately will allow organizations to serve their content to the right people, in the right way, at the right time. Creating websites/pages will always be a core “feature” of Drupal, and most people will probably just use it to do that, but those who understand content strategy will really be able to harness Drupal’s abilities in a powerful way.   7. Drupal 8 Will Be Object-Oriented

Drupal 8 represents the single largest change to the code-base ever, restructuring Drupal to use object-oriented practices. This will change the project entirely moving forward. Although this is a programming change, the outcome will be sites that perform better and have shorter development cycles. Using more sophisticated design patterns, developers can more cleanly extend almost any part of the system without having to duplicate functionality. As we continue down this path, we foresee Drupal becoming more modular to allow the system to function more efficiently based on the types of requests being made, rather than loading the entire code-base into memory for even basic JSON requests. 

8. Drupal 8 Will Be More Accessible  Major improvements are coming in Drupal 8 for accessibility. In a perfect world, websites would be just as accessible by sound as they are by sight. Drupal takes us part of the way there with some new amazing tools. The foundational HTML markup is being expanded into APIs that make it easy to express the state of page components, not just their properties. They will be available in contrib and some in core as well.   9. Drush 6 Will Be (Even) Easier for Standard Tasks Drush 6, a command line shell and scripting interface for Drupal 8, is going to really help developers execute complex or repetitive tasks. New features in Drush will allow developers to edit views and other configuration directly through Drush. In addition, many standard tasks, such as setting up test environments, will be quicker and less costly. These updates will make developers happier and reduce the time (and costs) for many activities.   10. A More REST-ful Drupal Will Lead to More Data Sharing
Drupal 8 will ship with a powerful REST-ful interface. REST, which stands for representational state transfer, is a predominant method for enabling programmers to move content between sites and services. Making Drupal more “REST-ful” is huge, as it will allow sitebuilders to expose any Drupal data they’d like onto web apps, mobile apps, and any other device that can consume RESTful data over the internet. Drupal 8 will help push Drupal from being just a simple CMS that pushes HTML to a browser to a powerful platform that can push data to interactive web apps and mobile apps. Organizations with interesting data stored and managed in Drupal can more easily share that data to today’s devices and applications, as well as to those that haven’t been invented yet!

What is your favorite DrupalCon take-away? Share it in the comments. Interested in working with Drupal for organizations doing good work in the world? Join our team. 

Last week, 17 Forum One developers and strategists joined 3,300 other Drupalers in Portland, Oregon, for the biggest DrupalCon conference ever. We had a “Nodetorious-ly” good time, convening with the Drupal community, learning about the future of Drupal, and exploring Portland.

LESS is a CSS preprocessor language that extends your stylesheets with dynamic features. It was developed by Alexis Sellier with the main goal to make coding of stylesheets more efficient and to avoid code redundancy. The open source language can be seen as a superset of CSS as it uses the existing CSS syntax. Therefore valid CSS is also valid LESS code. The most crucial benefits LESS provides you with are variables, nesting, mixins, operators and functions.

Catch my post on tuning Slow queries over at the MPR developer blog:

http://blogs.mpr.org/developer/2013/06/using-mysqls-slow-query-log-to-pi...

Categories: Drupal

For sites that publish long form content, social sharing poses a problem. While users can easily link to a node's full page, linking to a specific chunk of text in that node's body is usually impossible. You could have authors add manual anchor tags throughout each article and give users visible links to each paragraph… Or, you could install the Emphasis module.

Ways to Protect Your Websites

Any website can be vulnerable to a variety of security problems, regardless of its underlying web technologies, including Drupal. Yet the most common type of attack involves a visitor injecting ill-intentioned code that is presumed to be regular text. For instance, an attacker might submit a comment to a blog post, but instead of providing only innocuous text, he includes malicious JavaScript code, hoping that it will be rendered by the web browser of anyone later viewing that page. Another attack vector, known as SQL injection, works by submitting through a form field some SQL code that, if not handled properly, ends up as part of a database query, intended to execute an unauthorized statement, such as truncating or dropping tables within the database, setting passwords to known values, or stealing user sessions.

That latter type of foul play is well addressed by Drupal's database API layer, which, if used properly and consistently in one's custom code, can negate the risk of an SQL injection breaching one's defenses. Consequently, Drupal developers and administrators will more likely encounter the former type of attack.

Broadly speaking, there are two schools of thought regarding how best to avoid falling victim to any online miscreant attempting to force his code to be displayed in your pages' contents or URLs. It might seem that the safest defense is to never allow unvetted content into the website's database. This process of sanitizing all text beforehand could be thought of as "pre-filtering". Drupal generally takes the opposite approach ("post-filtering") — namely, allowing all submitted content into the database, but always sanitizing it on output.

Author Michael J. Ross

As an experienced web developer, Michael J. Ross creates custom websites for businesses and non-profits, using Drupal and other leading technologies. He writes articles and book reviews, of which more than 500 have been published in print and online.

To get a better website performance you can tell apache where to find your websites .htaccess files instead of letting apache search for them recursively ..

First find the location of these .htaccess files on your web server ..

@paulbooker:/var/www/vhosts/paulbooker.co.uk/public# find . -name .htaccess ./.htaccess ./sites/default/files/.htaccess

.. and then add a directory block for each in your domains apache configuration file ..

# Admin email, Server Name (domain name) and any aliases ServerAdmin webmaster@paulbooker.co.uk ServerName paulbooker.co.uk ServerAlias www.paulbooker.co.uk # Index file and Document Root (where the public files are located) DirectoryIndex index.php DocumentRoot /var/www/vhosts/paulbooker.co.uk/public Options -Indexes -FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all Include /var/www/vhosts/paulbooker.co.uk/public/.htaccess Include /var/www/vhosts/paulbooker.co.uk/public/sites/default/files/.htaccess # Custom log file locations LogLevel warn ErrorLog /var/www/vhosts/paulbooker.co.uk/log/error.log CustomLog /var/www/vhosts/paulbooker.co.uk/log/access.log combined

You will need to reload apache for these changes to take effect ..

service apache2 reload

A further improvement would be to put all the directives that are inside the .htaccess file into your domains apache configuration file. You would then however need to look for and manually bring over any changes that come from upsteam.

Tags: apachehtaccessdrupalplanet Tweet