Feed aggregator
baxwrds: Drupal 7 'Add to Cart' Rule for Ubercart
On a current site in development I am using Ubercart to provide a renewable subscription service. To make the user experience clean, I wanted to protect the user from going 'shopping' to add their subscription. To do this I decided to use a rule to add the product to the user cart when the user is created by an administrator or when the subscription is cancelled or fails payment. I tried the Ubercart Rules module, but this is mainly for dealing with orders and not carts, and did not contain the needed add to cart rule.
Makak Media: Free LiveChat and Drupal
I've been looking at various LiveChat modules for Drupal sites and after testing a number out I finally found one I liked, Zopim LiveChat.
It's slick, quick and provides all the basic requirements plus a few neat additional things such as user stats, history, visitor lists, customisable sounds. If you wanted you could have unlimited chats for $11.20 a month or the full version for only $20 a month!
Lullabot: Module Monday: Content Locking
Drupal's editorial experience has improved considerably over the past several realeases, and Drupal 8 promises to be even better. However, it's still easy for writers and editors to collide with each other when they collaborate. If two people edit the same piece of content at the same time, one user's changes are inevitably lost. Fortunately, the Content Locking module is ready to help.
OnePage Design
Drupal Association News: Guest post: Notes from DrupalCamp Gothenburg, Sweden
Adam Evertsson is the head honcho behind DrupalCamp Gothenburg two years in a row, member of the Swedish podcast Drupalsnack and always fond of the community, both locally and globally. He really came for the code and stayed for the community.
Personal blog tags: drupalcampsDeeson Online: Drupal, Drush aliases and how to use them
drush aliases allow you to run a drush commands on your local server but actually execute the command on a remote server. This is a real time saver when working locally and then you want to do something on the remote server. Your specific workflows will depend on your particular setup but, as an example on Acquia dev cloud, how about pushing code up to your remote dev server and running updatedb in two commands.
$ git push origin $ drush @site.dev updatedb -ySetting up your local computer to use an alias needs a little configuration. Alias configuration files can go into a .drush folder in your home directory. You can add as many alias files as you like here with the naming convention:
sitename.aliases.drushrc.phpEach file can contain any number of aliases descriptions which are just entries in a multi dimensional array, the key of which is the subitem for that alias. For example, an alias file called mysite.aliases.drushrc.php with one dev entry like this ...
$aliases['dev'] = array( 'parent' => '@parent', 'site' => 'mysite', 'env' => 'dev', 'root' => '/var/www/html/mysite.dev/docroot', 'remote-host' => 'example.myserver.com', 'remote-user' => 'mysite', );... gives one alias which is accessed via the @mysite.dev drush argument. For example,
drush @mysite.dev statusThere is also a drush command to get you started on producing an alias drushrc file:
drush sa [uri] Holy Cow! What else can I do with drush aliases?I am glad you asked. How about download the remote db in one command ...
drush @mysite.dev sql-dump > /tmp/dbdump.sqlNote: don't use --result-file here as that will put the sql file on the remote server!
How about bring all the remote files down to your local system? From the root of the site on your local install run ...
drush rsync @mysite.dev:sites/default/files/ sites/default/files/Note: Run drush help rsync for help with this one!
Notes on Acquia and Drush aliasesWe often use Acquia dev cloud to host our client's sites. On Acquia hosted sites setting up local drush aliases are made very simple. Under the cloud menu on the subscription tab there is a utility link which describes exactly how to add the alias files to your local computer.
Acquia executes drush commands using drush 4 by default. To use drush 5, you'll need to edit your alias files in the .drush folder and for each environment add a path-aliases entry which describes which drush script to execute. The precise syntax is shown below.
$aliases['dev'] = array( 'parent' => '@parent', 'site' => 'mysite', 'env' => 'dev', 'root' => '/var/www/html/mysite.dev/docroot', 'remote-host' => 'mysite.com', 'remote-user' => 'mysite', 'path-aliases' => array( '%drush-script' => 'drush5', ), ); Other readingThis link shows all the goodness that can be put into a sites drushrc file ... http://drush.ws/examples/example.aliases.drushrc.php
Read moreDrupal, Drush aliases and how to use themBy John Ennew | 10th June 2013drunken monkey: Search API Solr search is stable!
It sometimes seems to me, that there are two different types of Drupal module maintainers: the ones who create a stable 1.0 release as soon as any code is working; and those who leave their modules "unstable" for years until they finally pluck up the courage to go 1.0. (I guess there also have to be some with the right middle approach, but those propably just don't catch one's eye as much.) There are actually projects in the top 10 of contrib module usage without a stable 7.x release (although there may of course be good reasons for that).
Anyways, in that pattern I'm definitely one of the latter group. I have only recently gotten to eventually creating stable releases for a number of modules (though some of them already had several thousand users) – Search API Database search (over 11k users) and Search API Pages (almost 3k users) are still waiting – and the 1.0 release of the Search API itself also took extremely long (by which time it also already had over 2000 reported* users).
In that context, it is kind of a milestone that there is now finally a 1.0 release of the Search API Solr Search module. (If you are not familiar with it, it's pretty self-explanatory: it allows you to use Apache Solr with the Search API.) As with the other modules, it had already been production-ready for quite some time, and currently has almost 5000 users.
In the case of the Solr Search module, though, there were several good reasons to wait with a stable release – foremost, the Apache Solr Common Configurations project, though definitely a good thing, changed the configuration files quite drastically when the module was otherwise stable. We also managed to add numerous feature (like location search support) and fix a lot of bugs, but those would have probably worked as well in subsequent minor releases. There were some other major refactorings, though, (foremost the effort to get rid of the external library dependency) whose inclusion in the 1.0 release is definitely beneficial.
Additionally, for the Solr Search module the 1.0 stable release is also kind of a promise: with it, I'm saying that I'm now confident that no major changes to the config files will be necessary anymore, so that there won't be the necessity for re-indexing the content for future new (minor) releases. Time will tell whether I'll be able to keep that promise but, as said, I'm quite confident.
So, if you shied away from giving the module a spin in the past, due to its missing stable release: it has been ready for quite some time now, but now it's official!
For all existing users: upgrade to the new stable release and see if there are features or bug fixes that help you out (or, hopefully not, any bugs you can report)! Recent additions include support for SSL, field collapsing, Solr 4.x and location-based searches.
(Also, check out the new documentation, if you haven't done so already!)
* By the way, is there any data or estimations out there on what percentage of users the Drupal.org usage statistics actually capture?
Image credit: Sergey Melkonov
Tags: search api solrplanetMediacurrent: Preparing for a Drupal Website Redesign
When was the last time your website had a facelift or you audited your Drupal modules, site security, SEO, etc?
We believe website redesigns fundamentally fall into two categories: the right and the wrong.
The right way delivers true value to an organization and the wrong way just consumes time and money for window dressing—which does nothing for your bottom line.
Recently a few of our teammates gathered our thoughts around Drupal website redesigns. As we talked through the different areas we coach our customers on, we decided to put them into one eBook.
"Preparing for a Drupal Website Redesign" is a collection of important suggestions your organization should consider before embarking on your next website design. Suggestions such as:
Facebook Like Box For Jomsocial
AutoTweetNG for SobiPro
Share Buttons
Code Enigma: Getting started with Test Driven Development - Choosing a Test Harness
Following on from the first blog post in this series, An Introduction to Test Driven Development, Chris introduces the test harness so strap yourself in!
My first experience of work "in the real world" came through work experience. I was lucky enough to get one of only two placements with IBM at Havant and my assigment was to build to specification the wiring loom used to connect the IBM 3745/3746 communications controller to its test harness. These units had to be regularly and thoroughly tested throughout production and so periodically each unit was hooked up to a test harness by means of the aforementioned wiring loom so that a range of tests could be executed against the unit and pass/fail reports and data collated. My time at IBM provided a fabulous insight into engineering/testing and firmly cemented in my mind the concept of a test harness.
In software development, a test harness provides exactly the same functionality, it provides a means of executing tests against software and giving feedback on whether the software is behaving as expected.
The specific test harness you choose will likely vary from project to project and is dependant on a number of factors, the coding language of the project and experience of the developers and test engineers involved may have an impact on the decision making process, a Google search for "test harness for language x" will no doubt turn over a number of options for each language and whilst there’s no hard and fast rule that your test suite and project code language must match, the skillset of the team surely will play a part.
Another major consideration should be around the types of test you want to execute, (unit, integration, system, acceptance etc) as some test harness frameworks lend themselves more towards one or a subset of types. You can of course use more than one test harness if it makes sense for your project with each providing different elements of a test plan strategy: unit tests running on every build and full smoke and functional tests running on release for example.
Consideration also needs to be given to the development methodology being applied - perhaps PHPUnit is a best choice if a purely Test Driven approach is adopted, on the other hand, Behat is a clear winner for Behaviour Driven Development.
I'll leave the last key point for consideration till the end! First, let's briefly review 4 popular test frameworks.
SimpleTestFor those of us working with PHP (and specifically Drupal), there are a number of options. Coupled closely with Drupal is SimpleTest which was moved to core in Drupal 7. It's modeled on the open source SimpleTest unit test framework so those familar with its suite of assertions will be comfortable and will get the extra benefit of helper methods such as drupalLogin(), drupalLogout(), drupalCreateNode() and drupalCreateUser() for establishing fixture[1].
Here's an example of a user login test in SimpleTest taken from the user module and modified slightly for clarity:
<?php /** * User login test. */ class UserLoginTestCase extends DrupalWebTestCase { public static function getInfo() { return array( 'name' => 'User login', 'description' => 'Ensure that login works as expected.', 'group' => 'User', ); } /** * Test that a user can login. */ function testUserLogin() { $user = $this->drupalCreateUser(array()); $this->drupalLogin($user); } }As you can see, tests are expressed in PHP code and SimpleTest provides a number of assertions that can be used.
I won't go into much detail here about SimpleTest as many good blog posts already exist about its use and limitations (duration of test run being a major issue which SimpleTest Clone seeks to address, some have had success with switching to MyISAM for tests and others, along with Drupal Quality Assurance have adopted ramdisk with a mixed outcomes it seems.)
Code Enigma offers high performance Drupal hosting with built in support for running automated tests, see our http://hosting.codeenigma.com/faq for more information or get in touch if you'd like to talk it through.
PHPUnitPHPUnit is a popular open source PHP test framework created and maintained by Sebastian Bergmann which, from its name, is a good choice for unit testing although you can combine it with other libraries, Guzzle and Selenium Server for example enabling browser automation for functional and acceptance testing.
I personally find PHPUnit invaluable and use it on a daily basic, tests are easy to read, write and are quick to run if you're actually doing true unit testing. Of course, that in itself raises a challenge when working with Drupal where dependencies are commonly requested rather than injected. Drupal 8 is heading in the right direction with Mark Sonnabaum leading the introduction of PHPUnit tests in the upcoming release. I recommend watching the video of his recent Drupalcon Portland session on the subject.
A really basic example PHPUnit unit test:
<?php /** * Adds two numbers and returns the result. */ function add($a, $b) { return $a + $b; } class AddTest extends PHPUnit_Framework_TestCase { public function testadd() { $this->assertSame(3, add(1, 2)); } }Once again, tests are expressed in PHP code with PHPUnit providing perhaps a slightly richer set of assertions than you get with SimpleTest.
BehatCreated by Konstantin Kudryashov, Behat is the PHP Behaviour Driven Development enabler for PHP projects - it enables composition of human readable tests (in Gherkin) that Behat turns into executable acceptance tests. This is the beauty and strength of BDD (and Behat), together they provide a means whereby business owners, developers, project managers and testers can frame requirements in a common language, the language of the business domain and from there derive a suite of acceptance tests that indicate delivered value.
The DrupalExtension module provides additional step definitions for some of the basic operations normally performed on a Drupal site, in addition it provides support for regions defined in the theme layer for more accurate querying of the user interface.
I recently gave a talk about BDD and Behat at the North West Drupal user group - you may find my slides and code helpful.
An example feature and scenario:
Feature: Login As a visitor I want login So that I can manage my account Scenario: A user enters their credentials and logs in successfully Given I am on "/" And I fill in "admin" for "name" And I fill in "letmein" for "pass" When I press the "Log in" button Then I should see "My account"Expressed in a structured language called Gherkin, Behat along with the Mink extension can take this feature and turn it into an executable acceptance test without the need to write any PHP code.
CodeceptionCodeception is a PHP framework created and maintained by Michael Bodnarchuk. It enables acceptable, functional and unit testing which are created by expressing context, actions and expected behaviour in simple expressive PHP code.
At the time of writing, Codeception has switch on module support for a number of PHP projects such as Symfony, Laravel, Yii and ZF but unfortunately no-one has written the equivalent for Drupal yet. Keep an eye on Mike Bell and Paul Byrne who have both written very good blog posts about Codeception, Testing with Codeception and Drupal Projects and More testing with Codeception and Drupal projects
An example Codeception test:
<?php $I = new WebGuy($scenario); $I->wantTo('ensure that frontpage works'); $I->amOnPage('/'); $I->see('Home');Tests are composed in simple expressive PHP code.
ConclusionIt's perhaps now apparent that whichever test framework you choose, the end result is much the same: tests are executed either directly against code (unit testing) or against the site itself (functional/acceptance testing through browser automation) and the failures are reported in some way. The key variant these frameworks offer, and in my book, the most important element for consideration is the input. Answering the following pivotal question helps:
How best can tests be expressed for this project and the people involved in its delivery?
Although not explicit, you might want to include the client when you consider the people involved!
1. A fixture is a known application state which tests will run against, establishing a fixture is the work you do to get to that know state, perhaps the creation of a user for example.
Related Service Areas: DevelopmentCategories: CommentConsultancyDevelopmentDrupal PlanetPrimary Category: DevelopmentTags: test driven developmentagiletestingsoftware qualitysoftware engineeringKnackForge: Drupal 7 Form API - Using #states on #markup field
An essential feature of a dynamic site would be to let its users add some contents to it. Often this is done using HTML forms. Drupal offers a rich and relatively simple way to use API for building forms for its Developers. In Drupal parlance it is referred as Form API (or FAPI).
Google Plus One Linkedin Share Button Tweet Widget Facebook LikeWeb Omelette: Cool module: Responsive Navigation
Responsive Navigation is a cool Drupal module that incorporates the responsive-nav.js plugin into your site. In this article I am going to show you how to install and use this module.
