Planet Drupal

I also thought of calling this episode of our Four Freedoms podcast series "The interesting journey of a company producing proprietary software being involved in an open source project," ... not so catchy. Or maybe "Why business and openness do not have to be enemies." The point is that on February 12, 2013, Opera Software announced that it was dropping its own, proprietary rendering engine in favour of the open source WebKit engine. I wanted to know more about that decision and the consequences going forward. What I discovered is a company with a commitment to open standards, knowledge sharing, liberal licensing, and a long-term history of actions to back those claims up.

opera_webkit_mwc13.mp3

We want to open source the backend for Walkthrough.it and turn it into an open source Drupal distribution that makes it really simple to start your own WalkHub where people can create and collaborate on interactive tutorials for software that runs in a browser. Yesterday I blogged about the YAML export we want to create for Tour module, together with the open source backend we believe this project could become a key addition to your Drupal project toolset, especially for Drupal 8.

I've been on the road a lot lately, touting the opportunities that Drupal offers to workforce and economic development efforts of regions and states. Thing is, before we can get to all the advantages for regions to develop a Drupal-talented workforce, we have to educate a lot of government leaders, commissions and committees on what Drupal is and does.

-->

read more

We all know about coding standards, but for some, they're an afterthought, not a way of life. Here's how to change that.

Writing standards-compliant code in Drupal 7 doesn't have to be hard! Using the power of a modern IDE, it can help to show you where you're going wrong, and ensure that all your code is standards-compliant. Here, we'll take a look at setting up JetBrains PhpStorm (our favourite IDE) to show you coding standards problems, but any IDE with CodeSniffer support will be able to do this, so it's likely Eclipse, NetBeans, and others will also help you out in the same way.

Blogs: Drupal PlanetTags: CMSDrupalDrupal DevelopmentPHPTiger FishTigerfishWeb DevelopmentWebsite

Completed Drupal site or project URL:  https://www.prestocentre.org

PrestoCentre is a non-profit, membership driven organization that serves an international community of stakeholders in audiovisual digitisation and digital preservation.

Menu block provides your Drupal site with configurable blocks of menu trees that start from and go down to any hierarchical level you want. Menu Tag works nicely with Menu block and allows you to create tags to filter the display of individual menu items in the block.

To start, I am going to make a bold suggestion – you are lazy!

No, I’m not trying to make enemies.

But I am pointing out that you, like many others, probably like to get your work done with the optimal amount of effort vs. outcome.

There are three compelling reasons for Drupal developers to embrace dependencies in the modules that you write.

In this article, I’ll take some time to guide you through these three reasons.

Dependencies save developers’ time

You are likely to consider using a dependency when the module that you want to depend on implements some or most of the features that you need in your own module.

Whilst you may find that there is a learning curve inherent in learning to build on a new module, doing so will almost always take less time than if you’d done the work yourself.

In addition, if this is a community module, any support and bug fixes for those features will generally be handled by the other module too.

Dependencies enable a better quality product

Drupal modules are better when they are written by specialists.

Dependencies enable you to focus on the problem that you needed to solve, without being bogged down in side features or tedious tasks.

Likewise, the dependency module will have been written by people who are themselves specialist in that topic.

A good example is providing PDF copies of a page on your website.  You could either code this yourself, or use the Print module. Are you really going to be able to code a PDF better than they can?

Another example of the quality benefits comes from your users seeing a unified experience across their website. Taking the example of PDF printing again, it is better user experience for a site visitor to be able to see any PDF print in the same way, rather than each developer doing it in their own way.

Dependencies give potential for greater scope

Finally, as well as allowing you to build a better product (and in less time), dependencies mean that your module is likely to be an easier building block for others to extend.

It is this ability to extend and reuse code that makes Open Source modules much more worthwhile.

Conclusion

It’s for the reasons above, that when porting the Project Management module to Drupal 7, we’re moving from a "everything needs to be built in" mindset to a "do as little as possible ourselves" mindset. Part of this is enabled by Fields in Core, but it also utilises modules such as Print that are likely to remain separate.

I wasn’t always in favour of dependencies, and suspect some of you are equally hesitant even now.

There are also of course plenty of arguments that people use against dependencies, and I’d be pleased to refute these in the comments.

Category: WebsitesTags: DrupalDrupal PlanetDrupal module dependenciesdeveloping Drupal modules

Test Driven Development has certainly stood the test of time, the process has been around for decades with NASA's Project Mercury perhaps being the earliest recorded use of TDD/test first techniques in software development. In more recent history we've seen it emerging prominently up and out of the eXtreme Programming movement of the late 90's, championed by Kent Beck and others.

So what is TDD?

Put simply, it's the software development process of writing a test first, followed by just enough code to satisfy the test, then a final but important step of re-factoring.

Not only does this process prove that the emerging code correctly satisfies tests (essentially that the code is fit for purpose) but it aids developers in thinking about the design of the code they write. It keeps the focus on small iterative steps that collectively build solid functionality and ultimately result in working software.

In addition, tests by their very nature, provide valuable documentation. The tests grow to form a catalogue of how the software should behave and also capture the intent of the developer. Add to this the bonus that tests travel with the software providing invaluable regression feedback during subsequent phases of development or maintenance and TDD certainly stacks up as a convincing recipe for success.

These benefits and more, are well documented in white papers such as IBM's study into its own sustained use of the process over a 5 year period[1] which concluded that any perceived productivity loss (the additional time taken to write the tests) was far outweighed by improved software quality. The report stops short of an absolute claim of improved code maintainability over its lifetime but it certainly alludes to it - add to this the plethora of blog posts (this one included!), podcasts and numerous books extolling the virtues of TDD and it's hard to imagine why it's not simply the ubiquitous modus operandi!

Hold on a minute, is TDD always appropriate?

OK, so before we get carried away in a naive flush of enthusiasm and broad brush strokes, when is TDD not appropriate? In my opinion, it boils down to a single important point:

Always use the right engineering process for the thing you're doing.

Are you building a disposable prototype in rapid short iterations for some quick feedback? Some would argue that tests would still be useful but clearly you're not going to get all the benefit, your prototype will be discarded, you won't have ongoing maintenance where a suite of tests would prove invaluable against regression.

Building a complex product that will likely be years in development and will go on to be maintained by numerous developers in the future?

Building a popup site that'll only be live for a week?

Clearly, different tasks and projects call for different approaches and we must remain flexible, there's no room for a one size fits all mentality in software development!

I sense the aspiration...

When I talk to developers who have yet to try TDD, I sense the aspiration is there. Ask anyone who cares about what they do for a living if they'd like to improve the result of their work and you will most definitely hear an affirmative response. On the other hand, there are always those who feel they don't need Test Driven Development, "It's a waste of time, I don't need tests to prove my code works, I'm a professional, I've been doing this years...". On balance, I genuinely believe no-one sits down with the intent of writing rubbish, hard to understand, spaghetti or broken code (unless they're practicing MDD - Mortgage Driven Development). It just happens, line by line, day by day, bug fix by bug fix. It happens... a lot. And it's called entropy.

I recently stumbled across a recording of Kent Beck's keynote address at RailsConf 2008, he told a series of three stories, three stories about "ideas with impact" he'd played a part in over the previous 20 years, he introduced the section about TDD in this way:

"[developing testing is about] developers taking responsibility for the quality of their code, testing really isn't the point, the point here is about responsibility, when you say it's done... is it done? Can you go to sleep at night knowing the software that you've finished today works and will help and isn't going to take anything away from people, that's the point of developer testing..."

I found something about the frankness here engaging, it certainly makes me want to become a better developer.

Is the business convinced?

I've already touched on the perceived productivity loss incurred by adopting TDD, reluctance might stem from purely financial considerations because time, after all, is money.

There are also without doubt, development companies and clients alike who firmly believe that clicking around a site or desktop/mobile application is sufficient testing in itself!

Whilst it can be hard challenging entrenched opinions and long established ways of working, we are fortunate to have at hand the historical data of those who've trodden the path before us, those who have gone to great lengths to capture the detail and measure the success or otherwise of this process.

Microsoft for example, concluded a study into three of its development teams with the following opening paragraph:

"Our experiences and distilled lessons learned, all point to the fact that TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team. Additionally, since an important aspect of TDD is the creation of test assets—unit, functional, and integration tests. Future releases of these products, as they continue using TDD, will also experience low defect densities due to the use of these test assets"[2]

Hard evidence is hard to ignore.

Perhaps you've already weighed the evidence and feel it's time to introduce TDD to your development teams or maybe you're a freelance developer who's wanting to step up! In subsequent blog posts I'll be offering tips and advice on how you can get started, I'll also be sharing how we use TDD techniques at Code Enigma!

Footnotes

1. "On the Sustained Use of a Test-Driven Development Practice at IBM" was published in 2007, it reports on IBM's case study into TDD whilst developing JavaPOS device drivers - http://agile2007.agilealliance.org/downloads/proceedings/006_On%20the%20...

2. "Realizing quality improvement through test driven development: results and experiences of four industrial teams" was published in 2008, it reports on TDD practices used by three teams at Microsoft whilst developing Windows, MSN and Visual Studio and also makes reference to the IBM case study previously mentioned - http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

Related Service Areas: DevelopmentTeaser: In this, the first in a series of blog posts, Chris introduces the software development process known as Test Driven DevelopmentCategories: CommentConsultancyDevelopmentDrupal PlanetPrimary Category: DevelopmentTags: test driven developmentagiletestingsoftware qualitysoftware engineering

Did you know that there is a strong likelihood a Cross Site Scripting vulnerability exists on your site? Have you specifically tested your site for XSS or other vulnerabilities? Are you not sure what that even means?

Start:  2013-04-13 (All day) - 2013-04-14 (All day) Europe/London Drupalcamp or Regional Summit Organizers:  candiebandit kae76 elv WigglyKoala bertboerland sign woeldiche mortendk Event url: 

http://frontendunited.org

Frontend United, formerly known as Drupal Design Camp, is a yearly European conference that moves from country to country. Its aim is to bring front-end developers, designers and Drupal themers from all kinds of backgrounds closer together and share knowledge, experiences and ideas face-to-face.

In Drupal 7 you can query a database table in two ways; using a static query or a dynamic query. A static query is the simplest of the two, all you need to do is pass a query and arguments using the db_query function. Most of your queries should be a static query because they are the fastest and the simplest.

Dynamic queries on the other hand allow other modules to modify a query by implementing the hook_query_alteror hook_query_TAG_alter hook. But beware dynamic queries are slower than static queries.

I've been a longtime fan of Alfred App, an award-winning productivity application for Mac OS X.

They've just released Alfred v2 which is re-written from the ground up to be faster, more efficient and easier to use, as a powerpack user of V1 I've been beta testing it for several months now.

Alfred 2 has a new replacement for extensions called workflows and I have written a Drupal workflow that handles the Drupal API integration in a much faster way than the old Version 1 extension.

Along the way I found a bug in the api modules handling of function dumps which is now fixed and live on api.drupal.org thanks to jhodgdon, verified that this workflow causes less requests to api.drupal.org than the Alfred V1 extension, and generally had a lot of fun debugging things until it was working properly.

This workflow caches the Drupal api function list's locally and shows the variables that the function expects to receive as well, hitting enter opens the relevant page on api.drupal.org.

Usage

Drupal API lookup
d5 [substring_of-hook]  (cached for 90 days)
d6 [substring_of-hook]  (cached for 90 days)
d7 [substring_of-hook]  (cached for 30 days)
d8 [substring_of-hook]  (cached for 2 days)

g.d.o
dg [nid or group]

d.o
do [nid or project]

Search Drupal site network
ds [string to search]

Drupal user
du [user id or name]

Drush (drush as per Alfred v1 Drupal plugin)
dd d [command]  (a Drush alias with a Drush command command Action - Invokes Drush
dd o [command]  (a Drush alias Action - Opens the URI associated with the Drush alias in a browser)

Download the Advanced Drupal workflow now

See it in action Tags: drupal planetdrupalos x

This article provides a step-by-step tutorial for creating a custom, multistep registration form via the Ctools Form Wizard in Drupal 7. If you'd prefer to solely use the core Form API, take a look at Building a Multistep Registration Form in Drupal 7, a previous blog post. In the interest of saving time, I'm going to be lifting some text directly from that post, given that there are a number of overlapping tasks.

Why use the Chaos Tools module to build a multistep form? Well, Ctools offers a number of tools that build upon the core Form API, allowing you to create a multistep form faster. This includes providing a method for caching data in between steps, adding 'next' and 'back' buttons with associated callbacks, generating a form breadcrumb, etc.

The Tut

First things first— create a new, empty, custom module. In this example, the module will be named grasmash_registration. In the interest of reducing our bootstrapping footprint and keeping things organized, we're also going to create an include file. This will store the various construction and helper functions for our form. Let's name it grasmash_registration_ctools_wizard.inc.

We'll start by defining a "master" ctools form wizard callback. This will define all of the important aspects of our multistep form, such as the child form callbacks, titles, display settings, etc. Please take a look at the help document packaged with ctools in ctools/help/wizard.html for a full list of the available parameters.

/** * Create callback for standard ctools registration wizard. */ function grasmash_registration_ctools_wizard($step = 'register') { // Include required ctools files. ctools_include('wizard'); ctools_include('object-cache');   $form_info = array( // Specify unique form id for this form. 'id' => 'multistep_registration', //Specify the path for this form. It is important to include space for the $step argument to be passed. 'path' => "user/register/%step", // Show breadcrumb trail. 'show trail' => TRUE, 'show back' => FALSE, 'show return' => FALSE, // Callback to use when the 'next' button is clicked. 'next callback' => 'grasmash_registration_subtask_next', // Callback to use when entire form is completed. 'finish callback' => 'grasmash_registration_subtask_finish', // Callback to use when user clicks final submit button. 'return callback' => 'grasmash_registration_subtask_finish', // Callback to use when user cancels wizard. 'cancel callback' => 'grasmash_registration_subtask_cancel', // Specify the order that the child forms will appear in, as well as their page titles. 'order' => array( 'register' => t('Register'), 'groups' => t('Connect'), 'invite' => t('Invite'), ), // Define the child forms. Be sure to use the same keys here that were user in the 'order' section of this array. 'forms' => array( 'register' => array( 'form id' => 'user_register_form' ), 'groups' => array( 'form id' => 'grasmash_registration_group_info_form', // Be sure to load the required include file if the form callback is not defined in the .module file. 'include' => drupal_get_path('module', 'grasmash_registration') . '/grasmash_registration_groups_form.inc', ), 'invite' => array( 'form id' => 'grasmash_registration_invite_form', ), ), );   // Make cached data available within each step's $form_state array. $form_state['signup_object'] = grasmash_registration_get_page_cache('signup');   // Return the form as a Ctools multi-step form. $output = ctools_wizard_multistep_form($form_info, $step, $form_state);   return $output; }

As you can see, our registration form will have threes steps:

1. the default user registration form
2. the groups form
3. the invite form

These have been respectively titled "Register," "Connect," and "Invite."

You should also see that we have referenced a number of, as of yet, non-existent callback functions, as well as a cache retreival function. Let's talk about that cache function first, then look at the callbacks.

Data caching

Ctools provides a specialized Object Cache feature that allows us to store arbitrary, non-volatile data objects. We will use this feature to store user-submitted form values in between the form's multiple steps. Once the entire form has been completed, we will use that data for processing.

To efficiently utilize the Object cache, we will define a few wrapper functions. These wrapper function will be used to create, retreive, and destroy cache objects.

/** * Retreives an object from the cache. * * @param string $name * The name of the cached object to retreive. */ function grasmash_registration_get_page_cache($name) { ctools_include('object-cache'); $cache = ctools_object_cache_get('grasmash_registration', $name);   // If the cached object doesn't exist yet, create an empty object. if (!$cache) { $cache = new stdClass(); $cache->locked = ctools_object_cache_test('grasmash_registration', $name); }   return $cache; }   /** * Creates or updates an object in the cache. * * @param string $name * The name of the object to cache. * * @param object $data * The object to be cached. */ function grasmash_registration_set_page_cache($name, $data) { ctools_include('object-cache'); $cache = ctools_object_cache_set('grasmash_registration', $name, $data); }   /** * Removes an item from the object cache. * * @param string $name * The name of the object to destroy. */ function grasmash_registration_clear_page_cache($name) { ctools_include('object-cache'); ctools_object_cache_clear('grasmash_registration', $name); } Submit callbacks

Now, we will define the various callbacks that were referenced in our $form_info array. These callbacks are executed when a user clicks the 'next', 'cancel', or 'finish' buttons in the multi-step form.

/** * Callback executed when the 'next' button is clicked. */ function grasmash_registration_subtask_next(&$form_state) { // Store submitted data in a ctools cache object, namespaced 'signup'. grasmash_registration_set_page_cache('signup', $form_state['values']); }   /** * Callback executed when the 'cancel' button is clicked. */ function grasmash_registration_subtask_cancel(&$form_state) { // Clear our ctools cache object. It's good housekeeping. grasmash_registration_clear_page_cache('signup'); }   /** * Callback executed when the entire form submission is finished. */ function grasmash_registration_subtask_finish(&$form_state) { // Clear our Ctool cache object. grasmash_registration_clear_page_cache('signup');   // Redirect the user to the front page. drupal_goto('<front>'); } Child Form callbacks

These forms comprise the individual steps in the multistep form.

function grasmash_registration_group_info_form($form, &$form_state) { $form['item'] = array( '#markup' => t('This is step 2'), );   return $form; } function grasmash_registration_invite_form($form, &$form_state) { $form['item'] = array( '#markup' => t('This is step 3'), );   return $form; }

You can use all of the magic of the Form API with your child forms, including separate submit and validation handlers for each step.

Integration with Drupal core user registration form

Now for the tricky part— we're going to override the Drupal core user registration form with our multistep ctools form, makign user registration the first step.

We will do this by modifying the menu router item that controls the 'user/register' path via hook_menu_alter(). By default, the 'user/register' path calls drupal_get_form() to create the registration form. We're going to change that so that it calls our ctools multistep form callback instead.

/** * Implements hook_menu_alter(). */ function grasmash_registration_menu_alter(&$items) { // Ctools registration wizard for standard registration. // Overrides default router item defined by core user module. $items['user/register']['page callback'] = array('grasmash_registration_ctools_wizard'); // Pass the "first" step key to start the form on step 1 if no step has been specified. $items['user/register']['page arguments'] = array('register'); $items['user/register']['file path'] = drupal_get_path('module', 'grasmash_registration'); $items['user/register']['file'] = 'grasmash_registration_ctools_wizard.inc';   return $items; }

We will also need to define a new menu router item to handle the subsequent steps of our multistep form. E.g., user/register/%step:

/** * Implements hook_menu(). */ function grasmash_registration_menu() { $items['user/register/%'] = array( 'title' => 'Create new account', 'page callback' => 'grasmash_registration_ctools_wizard', 'page arguments' => array(2), 'access callback' => 'grasmash_registration_access', 'access arguments' => array(2), 'file' => 'grasmash_registration_ctools_wizard.inc', 'type' => MENU_CALLBACK, );   return $items; }

That's it! You should now be able to navigate to user/register and see the first step of your multistep form. Subsequent steps will take you to user/register/[step-name].

Now, for a bonus snippet snack, here's how you can take the first step of your form and put it into a block!

Displaying the first step of our form in a block /** * Implements hook_block_info(). */ function grasmash_registration_block_info() { $blocks['register_step1'] = array( 'info' => t('Grasmash Registration: Step 1'), 'cache' => DRUPAL_NO_CACHE, );   return $blocks; } /** * Implements hook_block_view(). * * This hook generates the contents of the blocks themselves. */ function grasmash_registration_block_view($delta = '') { switch ($delta) { case 'register_step1': $block['subject'] = 'Create an Account'; $block['content'] = grasmash_registration_block_contents($delta); break; } return $block; } /** * A module-defined block content function. */ function grasmash_registration_block_contents($which_block) { global $user; $content = ''; switch ($which_block) { case 'register_step1': if (!$user->uid) { module_load_include('inc', 'grasmash_registration', 'grasmash_registration_ctools_wizard'); return grasmash_registration_ctools_wizard('register'); } break; } }

Good luck!

7.x, drupal, multistep, form, fapi, ctools, registration, register

PhpStorm 6.0 came out yesterday, and it's very very nice. One of the cool new features is that it can connect to what it calls a "Generic" task server. This is for services that Jetbrains has not built service-specific integration for yet. Drupal.org definitely falls into this category. So without further adieu, I present the holy grail of IDE integration:

Mollom

If you would like to allow anonymous users to create an account, create content, or comment on your site, but don't want to leave it vulnerable to spam, you'll need to install some form of spam protection. Mollom is a third party service that has plugins and integration with a variety of software including Drupal, Wordpress, .NET, Ruby and a number of other systems. One of its most useful features is that, regardless of the platform it is implemented on, it references a central repository of known spam, and everyone who uses it can contribute to and benefit from that central repository.

This week has had a lot of interesting Drupal news. Maybe it was the recent events in Australia and London driving stories or perhaps just something in the air. Whatever the case, here's a brief roundup of what I thought were some of the more thought-provoking items.

MySQL co-founder David Axmark gives a warning to the Drupal community

This post by Darren Mothersele discussed an interview that David Axmark gave at the recent DrupalCamp in London. He shares some really valuable insights and warns against catering to large enterprises at the expense of your core user base. You can read Darren's excellent post or view the original interview below.

Drupal 8: Re-architecting for world domination

This article from ComputerWorld is a nice companion to the previous post and will provide some food for thought for many of you. The article discusses the upcoming release of Drupal 8 and doubles as an interview with Dries Buytaert.

Lots of talk here from Buytaert about the importance of enterprise clients, but I wish he'd occasionally talk up the importance of small companies. After all, most people working with Drupal don't work with large enterprises. They are small Drupal outfits that are providing services to other small organizations. This is something Axmark brought up in the video above, calling small Drupal companies the "base bone of the Drupal community". It was nice to hear. Contrast it with this quote from the ComputerWorld article:

Buytaert said his focus is now squarely on the enterprise and on competing with companies like Adobe and Sitecore.

"I think we do a lot of replacements from Vignette and Interwoven. We [also] compete a lot with Sitecore and Adobe CQ5 and we beat them. And sometimes we lose. It depends really. But I think with Drupal 8 we will close some of these gaps, and in [some] areas we'll leapfrog them even..."

The "sweet spot" for Drupal is larger sites rather than smaller ones. "I think when people think big websites, they usually think Drupal, and when they think small blogs or limited small websites in complexity then they think WordPress," Buytaert said.

"At Acquia we never compete with WordPress. We don't see them ever. I'm sure the smaller Drupal shops run into them, but in the enterprise we never run into WordPress."

"I think with small sites I'm not willing to give up on them but I think we just need to say we're more about big sites and less about small sites, but then the small sites are still very useful to get people into the community," Buytaert said.

Some good things here, but with so much talk about enterprises, what is the future of the Drupal community? How will it change? If you're always talking about Drupal for large enterprises and saying that it's mostly for big sites, what effect does that have on small organizations and even individuals who are considering getting involved? I can't imagine it's helpful.

I'm not saying that Drupal being an enterprise solution is a bad thing. Not at all. In fact, I think it's great. However, I would like the messaging about Drupal to be more inclusive and stress the flexibility of Drupal to accommodate all kinds of sites. It shouldn't just be tailored to suit Acquia or other large Drupal firms.

I certainly don't begrudge Buytaert promoting his company's interests, far from it. I do feel, though, that he has a very unique role in the community and should make more of an effort to speak as the community leader, not just CEO of Acquia.

Buytaert has also laid out a goal of Drupal powering 10% of all websites. This is a goal that is highly unlikely to be met solely by going after the big fish. So, maybe I'm missing something. Nevertheless, I worry sometimes about the future of Drupal for us small fish.

Banning Unethical Modules

I wonder how controversial this next post will be. In it, Yonas Yanfa poses the question of whether the Drupal community should allow possibly unethical modules like Death by Captcha to be hosted on Drupal.org. 

Being of a libertarian bent, I don't usually like the idea of imposing restrictions on people unless they are doing demonstrable harm to others. For me, if you are going to censor someone or impose a rule against them, what they are doing must be worse than merely being annoying. 

So the question is, does this module hurt others? Or is it just a nuisance? It's an interesting question. 

Continuing the Discussion

My last post turned out to be somewhat controversial as well and raised what I think are good questions to consider. In the latter part of my post I explained why I had chosen to disable comments on my site. It's a choice a growing number of sites are making because of the widespread prevalence of abusive comments and spam.

Well, it turned out my decision was against Drupal Planet rules and so a conversation got started. It touched on the importance of online discourse, privacy, the usefulness of social media to facilitate conversations and more. A consensus was reached to change the rules of Drupal Planet so that sites may optionally point readers to a discussion on Drupal Groups or some other location on Drupal.org. 

This change is something I feel OK with because although Drupal.org is technically anonymous, there is a well-established community and users must consider their reputations when making comments. Hopefully trolling, spamming and generally bad behavior in the comments will be avoided. The change also addresses the spirit of discourse the original rule intended to promote.

I must admit that some of the comments in that discussion moved my opinion a bit. But in the end, I think I still agree with another commenter when he said, "Good content is good content whether I can comment on it or not ... I think the current policy is outdated."

Regardless, in respect of the rule change, you're invited to leave any comments you have at this forum topic on Drupal.org.

On March 12, 2013, Google announced the retirement of the Google Reader service on July 1, 2013. Fortunately, Drupal 7 has a module that can handle this situation included in core - the Aggregator module. Google's Takeout service exports your list of feeds in OPML format and the Aggregator module can read it. I took some screenshots of my Reader export and import back into the deekayen.net aggregator.

Login to the Google Reader service from a traditional desktop/laptop environment. On the top right of the window, there's a settings cog where you'll find the link to Reader settings.

In the Settings area, click the Import/Export tab, then click the Download your data through Takeout link.

Clicking the CREATE ARCHIVE button queues the export of your feeds to a zip file.

The zip file contains some json files of your Reader followers, articles you liked, and stared, as well as a subscriptions.xml file in OPML format.

On your Drupal 7 site, activate the Aggregator module.

If you want to read your feed without having to be logged in, grant access to Anonymous User to View news feeds.

Go to the Feed aggregator configuration. It is located in the Web Services category of Drupal administration.

The top of the Feed aggregator configuration page has a link to Import OPML. Select the file from your Google Takeout export named subscriptions.xml.

If you have already populated your aggregator with some feeds, you can still import your OPML file with the duplicates. Drupal will recognize the duplicates and ignore them.

The feed depends on a regular cron process running on your Drupal site. It can update the articles in your feed, at most, as frequent as your cron job runs. That means if you have decided on a daily cron job for your website, you may want to change the cron to hourly or every 15 minutes. If you're an administrator of your server, your cron job might then look something like this for a cron every 15 minutes by editing through crontab -e.

*/15 * * * * wget -O - -q -t 1 https://deekayen.net/cron.php?cron_key=TOKEN_GOES_HERE

The common path to read your aggregator output is /aggregator. If you have a feed reader or mobile app that can still read direct from RSS feeds instead of Google Reader, add rss to the path, for /aggregator/rss.

Adding to iOS Home Screen

You don't need a feed reader app to read your aggregator feed. Load your aggregator page in Safari on your iPhone or iPad. Tap the share link and you can add your aggregator to as an app to your device from there.

Adding to the Android Home Screen

Adding the aggregator page to the home screen in Android takes a few more steps than iOS. This example is for Android 4.2.2 on a Nexus 4 using Chrome.

Add the aggregator page as a bookmark.

Open the list of bookmarks, locate the aggregator bookmark, and long tap on the bookmark.

The long tap on the bookmark should show the option for Add to home screen.

On newer Android installations, you can move icons into folders on the home screen. I moved mine into the News Feeds folder to replace EasyRSS.

P.S.

Also consider having search engines ignore your aggregator feed. It doesn't belong in search indexes. An option to explore for that change would be deleting your robots.txt file and using the RobotsTxt module.

Post categories Drupal

Earlier this week, we looked at changes in content editing for nodes and blocks. Today we'll be looking at the implementation of forms and views modules in the core of Drupal 8 as well as drawing some overall conclusions.

Built-in Contact Form

The 'Structure' page contained another item that really caught my attention: Contact form.  My first question was, 'Why not contact forms? Plural?'.  Every site I've ever built needed the webforms module, and the contact form administration pages look very similar.  I submitted an inquiry to the default form, and I didn't see anywhere on the admin pages to check for that submission.  It may be that this is an email only form, and nothing gets saved to the database.  Functionality continues to depart from what I'd expect when visiting the contact form configuration page.  You have the option to 'Add category' for the contact form.  But whereas I'd expect something resembling taxonomy for that, you actually create a new, separate form with unique recipients and/or fields.

Only one of the forms in the list can be 'selected' as the site-wide contact form.  Whichever form is selected now reserves the '/contact' path in the system.  There was also a 'Disable' link in the list of forms/categories that didn't function as I'd expect.  First off, isn't that a bit redundant when combined with the unique 'Selected' option? Secondly, clicking that link takes you to the editing page for the form, just like the 'Edit' option does. The whole setup confused me quite a bit, probably because I was wanting it to look like webforms.  If you're going to the trouble of adding a form builder at all, why not make it more generic and flexible.  Isn't that the Drupal way?

Let's Quit Messing Around.  What About Views?

I had been purposely avoiding views until I had a chance to check out what I've already discussed.  I knew that views in the core is the single most useful feature they'll be adding to Drupal 8.  I didn't want to get distracted by other new features once I started my investigation.  Visiting the views page looks much like we're used to seeing once the module is installed in Drupal 7.  The exact same list of disabled views are pre-populated, although there are two distinct list boxes now (enabled, disabled) rather than having a 'grayed out' style for disabled views at the bottom of the same list like we've seen in the past.

Creating a new view has the same initial interface that we've seen in Drupal 7, although the 'Create a page' box isn't checked by default now.  If you don't check boxes to create displays in the view, a 'Master' display is added that doesn't have a 'Machine Name' option and/or value under the 'Advanced' section.  Views in Drupal 7 functions the same way, although I had never tried it because I'm always creating a page or a block.

One of the features that I enjoy most about views is being able to add custom view templates to my theme.  It REALLY brings additional muscle and flexibility to Drupal. Upon expanding the familiar 'Advanced' section, I was initially confused.  What was previously 'Theme: Information' is now labeled 'Output: Templates'.  OK. That makes more sense, actually.  Moving on.  The list of template file name suggestions is now a bulleted list and MUCH easier to see the order of priority. 

BUG NOTE: Clicking on one of the output category links on this page didn't give me the default PHP code for the template file.  The resulting dialogue only provides a link back to the 'theming information', which seems inconsistent with the relabeling of this section.

A Fairly Substantial Bug

When I created my first Drupal 8 view, I wanted to keep it simple.  Aside from assigning the view name and selecting the option to create a page, I kept all of the defaults.  The result was a view that displays a list of teasers, but I inevitably want to define my own fields instead. I clicked the 'Content' link under the format section of the view settings and changed that to 'Fields'.  Once I clicked the apply button, I expected to start adding some fields to my view, or maybe to see the warning about how the format is fields but none are configured.  Instead, I was returned with the settings unchanged.  

I tried several iterations of different options, but that value couldn't be changed in the development release that I'm using.  I went a step further and created a new view without selecting the 'Create a page' option, and strangely enough 'Fields' is the default for the format in that instance.  I really didn't dig much deeper because it's obviously a work in progress.  I'd be surprised if I'm uncovering anything that the project team for this development release hasn't already figured out.

Conclusion: This sneak peek continues to fuel my enthusiasm for both Drupal and the Drupal.org community.

I've probably been a bit too critical by even pointing out the bugs and oddities that I noticed.  There's nobody out there suggesting that this release is ready for production websites yet, and I fully acknowledge that this is a work in progress.  That being said, cracking open the development code and looking around has me scrutinizing today's projects to see where the updates in Drupal 8 will be useful. 

I may revisit the development release occasionally this year just to see how the project team is addressing some of the things that confused me about what I'm seeing today.  Hopefully you've been wondering how things are looking as well, and I've just saved you the trouble of doing your own investigation.  Have a question that I didn't answer?  Feel free to comment below and I'll continue to pick apart my test website with your suggestions.

Do you get a lot of comment spam? I do. Spam prevention services like Akismet and Mollum do a great job at stopping a lot of the spam. But what happens if a user leaves a good, on topic comment and includes a link back to their site, or another site? By default, search engines like Google will treat that link as a vote towards the target site. As far as it is concerned, you added the link. This can be bad for a couple of reasons, the main one being what is known as a bad neighbourhood. If Google does not like the target site and you link to it, you can become part of its neighbourhood. You do not want that!

This is exactly what rel='nofollow' is for. It tells search engines that you do not necessarily trust that link and they should not count it when towards the popularity of the target website. In a HTML <a> element, rel is an attribute and nofollow is the value. It looks like this:

<a href="http://www.example.com/" rel="nofollow">Some text</a>

To start off with, let's add a link to a comment and see what happens. I have set plain text as the format for anonymous users.

When you inspect the link in the comment, you can see that Drupal has converted this to use <a> tags. It is a clean link, so Google will think you are vouching for the target site.

The solution

Fortunately the solutions is just a few clicks away. All you need to do is configure the text format correctly. Because I am using plain text for anonymous users, that is what I will configure here. But you could do this for any text format. Here are the steps.

Step One

Go to admin/config/content/formats/plain_text to configure the plain text format

Step Two

Tick Limit allowed HTML tags under Enabled filters

Step Three

Under Limit allowed HTML tags tab, tick Add re="nofollow" to all links.

Step Four

Under filter processing order, drag Limit allowed HTML tags so that it is after Convert URLs into links. The order of filters is very important, because Drupal will run all of them. If Limit allowed HTML tags is before Convert URLs into links, Drupal will try to add rel='nofollow' before it has converted the URL to a link, so it will not work.

Step Five

Refresh the page where you added the comment and inspect the HTML.

The rel attribute with a value of nofollow has been added. So now you are telling searching engines like Google that you do not vouch for the quality of the links, and Google should ignore them when evaluating the popularity of the target site.

More than just comments

You can use this for any user generated content, not just comments. You just need to configure the text format that the users have permission to use.

What about the homepage link?

You can allow users to add a link to their homepage when adding a comment. This will be used as a link around the users name. In the latest versions of Drupal 7, rel='nofollow' is automatically applied to these links.

Protect yourself

So there we have it. It is quick and easy to protect yourself against bad neighbourhoods and other SEO nastiness that comes from untrusted user generated links.

Tags: Drupal SEOPlanet Drupal

14 MarA distribution for Drupal User Groups IV

Thank you for showing up on the DUG distribution code sprint that we arranged for Drupal Sprint Weekend! We had lots of fun, but we also had serious progress in both the theme and feature development.

Read more