Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 1 hour 1 min ago

Sooper Drupal Themes: What's your opinion on "premium Drupal modules"

12 June 2015 - 9:45am

We had this discussion 4 years ago. Why bring it up again now? Because several big codecanyon projects are coming to Drupal soon and I think it will have an impact. One of them is Slider Revolution. Slider Revolution is an "All-purpose Slide Displaying Solution that allows for showing almost any kind of content with highly customizable transitions, effects and custom animations". With nearly 60.000 sales at 18 USD it's the second most popular Wordpress plugin on codecanyon. The number of sites using this module is much greater because hundreds of premium Wordpress themes ship with the slider built into the theme. Some of these themes like Avada (140.000 sales) are widespread and amplify the impact of paid plugins in Wordpress.

To refresh our memories here are some quotes from 2011:

the DrupalAppStore that killed drupal

MortenDK, http://morten.dk/blog/drupalappstore-killed-drupal

..one thing that open source doesn't do a good job with: building teams of people with complementary skills to make sure that the software is a good experience for the customer. Why? Because there is no customer. Oh sure, hundreds of thousands of people use my software and they consider themselves customers, but ultimately they are not. Why? The definition of a customer involves, among other things, providing a revenue stream.

Earl Miles (merlinofchaos), http://www.angrydonuts.com/contributing-to-open-source

The pay-per-copy business model just doesn't work very well, practically, unless you have the completely artificial system of copyright restrictions to prop it up. (Physical objects have a natural scarcity that makes pay-per-copy vastly more practical.) When you're dealing with copyleft software, it works even more poorly.

Larry Garfield, http://www.angrydonuts.com/contributing-to-open-source

Sometimes I keep wondering why on almost every drupaller comment I read on the net is against making money on selling modules but it is OK to sell themes?

If themer can get away / circumvent GPL by licensing their css/images/js in different license than GPL why can't module developer create a separate php class api that doesn't touch any of drupal api and license it with commercial license?

Jason Xie, http://drupal-translation.com/content/it-evil-request-payment

With respect to the question "How" this last commenter was on to something. Large projects on CodeCanyon protect themselves against redistribution by having a functional code library that can work independently from the CMS integration. If there is any open source lawyer reading this I would love to hear comments on GPL compatibility of this structure.

My opinion

As a (premium) Drupal themes developer I have a special interest in development of these plugins: they provide great value to clients of my premium theme. For only around 100 USD I can buy an extended license for a module that cost the developer hundreds of man-hours to develop. By including several plugins into my theme that cost 20 USD per plugin, my theme which costs 48 USD is instantly more valuable to end-users. In general I have a positive attitude to CodeCanyon developers joining the Drupal modules. However, there will be some modules that are good for Drupal and others that could be bad for the Drupal ecosystem. 

For example, me and several other Drupal developers have been working on improving Bootstrap+Views integration through the views_bootstrap module: https://www.drupal.org/node/2203111. In the meantime, some guy on CodeCanyon seems to have all our problems figured out already and he is selling a very sleek Views+Bootstrap module on CodeCanyon. The code he sells is all Drupal-integrated programming. As far as I understand GPL this means that all his code is also GPL. So what can we do, is it legal to copy his code into the views_bootstrap module? Is it compliant with the rules and code of conduct on Drupal.org? Is it morally OK?

 

Tags planet drupal app store premium modules premium themes Drupal 7.x
Categories: Drupal

OpenLucius: 13 new kick-ass features | Drupal distro OpenLucius updated

12 June 2015 - 4:26am

It has been quiet for a few weeks around our Drupal distro OpenLucius, but this has its reason. We have worked hard on the first 'Release Candidate'. And we could not resist to implement new features. These new features have been developed with the feedback of the now thousands of OpenLucius users.

So team and project management has been made even easier! :-D

The 13 new features and improvements:

Categories: Drupal

Open Source Training: How to Add a Slider Search to Drupal

11 June 2015 - 5:18pm

One of our customers was setting up a Drupal Commerce site and wanted to add a slider search.

Here's an example of a slider search in action:

There are a lot of steps involved in this process, but it's worth the effort. This tutorial will use the default search, without relying on Apache Solr or alternatives.

Categories: Drupal

DrupalCon News: Book Your Hotel Room Today!

11 June 2015 - 5:10pm

Have you reserved your room at the Barcelona Princess yet? It’s the preferred hotel for all DrupalCon Barcelona attendees, and we’ve negotiated some great rates for our Drupal friends.

Categories: Drupal

Red Crackle: 15 minutes to your first Drupal integration test

11 June 2015 - 1:52pm
This post will help you write and run your first Drupal integration test in less than 15 minutes. By end of this post, you will be able to write an automated test to make sure that superuser is able to create two pieces of content, one published and the other unpublished. We'll test that anonymous user is able to view the published content and is not able to view the unpublished content. You can follow along these steps on any Unix or Mac machine and have automated tests running in a matter of minutes.
Categories: Drupal

Drupal core announcements: DrupalCI: It's coming!

11 June 2015 - 11:25am

DrupalCI is the next-generation version of our beloved testbot. The MVP ("minimum viable product") is coming soon (rolled out in parallel with the old testbot for awhile).

Here's a sneak peak at what it'll look like and some of its new capabilities: https://groups.drupal.org/node/471473

Categories: Drupal

Drupal core announcements: D8 Accelerate critical issue sprint in London, UK, July 2-8

11 June 2015 - 10:08am
Start:  2015-07-02 09:00 - 2015-07-08 18:00 UTC Sprint Organizers:  xjm Sprint toward a Drupal 8 release candidate

As of this writing, 22 known critical issues block a Drupal 8 release candidate. It's time to close that gap.

The D8 Accelerate program is sponsoring a critical issue sprint in London, UK, from Thursday, July 2 to Wednesday, July 8. The sprint will be hosted by UK company and Drupal Association member BrightLemon at Unit 12, Zeus House 16-30 Provost Street London, N1 7NG United Kingdom.

Space is limited but we welcome your help!

This sprint will be focused exclusively on resolving critical issues in Drupal 8. Confirmed attendees so far include alexpott, amateescu, Berdir, dawehner, pfrenssen, plach, xjm, Wim Leers, and znerol. If you can help resolve the remaining critical issues, we'd love to collaborate with you as well! Space is limited, so contact xjm if you are interested in signing up for the sprint.

Remote collaboration is also welcome; join us in #drupal-contribute during the sprint. If you can't make this sprint, you can help on Drupal 8 criticals in the issue queue now or at one of the other upcoming Drupal 8 sprints, or help by triaging major issues.

Let's get Drupal 8 done!

Categories: Drupal

Drupal Association News: Wunderkraut Breaks Ground as Drupal's First Signature Partner

11 June 2015 - 9:32am

The Drupal Association is excited to announce that Wunderkraut, a full service European agency and longtime supporter of the Drupal project, is now our first Signature Supporting Partner. A Supporting Partner since March 2014, Wunderkraut's latest contribution deepens its commitment to advancing the Drupal project and empowering the Drupal community.

"Drupal’s community is amazing. We’re very proud to be a part of it," said Wunderkraut CEO Vesa Palmu. "We're an established provider of Drupal services, and enjoy contributing to the Drupal ecosystem however we can, whether through camps or sponsored events, and especially when we can be quirky and fun! This passion is why we're now a Signature Partner—to strengthen our commitment to growing this community and project we love."

The Supporting Partner Program includes more than 60 companies from around the world. All of the funding from the program goes directly to support maintenance and enhancements for Drupal.org. Program contributions have funded many initiatives, such as

  • Advancements in security
  • Improved development environments
  • User-friendly content strategy and design

Partners enjoy enhanced promotional services from the Drupal Association, such as brand visibility on Drupal.org, select access at premier events like DrupalCon, and increased publicity via various online social platforms. For their elevated contributions to the program, Signature Partners will receive upgraded promotional services.

"I’m absolutely thrilled that Wunderkraut is joining us as the first Signature Supporting Partner," said Drupal Association Executive Director Holly Ross. "Their support for the Association and the project is, and has always been, top-notch. This is another great expression of how much Wunderkraut believes in the incredible work our community does."

To join Wunderkraut as one of the Drupal Association's contributing partners, start by learning more about the Supporting Partner Program.

And to join us in thanking Wunderkraut for its partnership, we encourage you to send this pre-populated tweet, or to say thanks in the comments for their blog post.

Categories: Drupal

Mediacurrent: State of the Panels Union

11 June 2015 - 8:22am

One of the most loved display architectures available for Drupal, the Panels module and its many related projects have come a long way from rather humble beginnings as a customizable dashboard for Drupal 4. Today they stand to be a testament to the power and flexibility of the Drupal platform. At DrupalCon LA I was joined by several other contributors, as we give an update to where the modules are right now, along with some insight into our plans for Drupal 8.

Categories: Drupal

Drupal Watchdog: HTML + CSS + JavaScript = Mobile Web App

11 June 2015 - 8:08am
Feature

If you're a web developer, perhaps you've heard of this newfangeldy “mobile” concept that's been sweeping the world. And perhaps you've even gone so far as reading a tutorial or two on how to create mobile applications. If so, you've seen that you get the delightful choice between Objective C and Swift (iOS), or Java (Android), all of which renders your hard-fought HTML, CSS, and JavaScript knowledge moot.

But, lo! There is hope!

If you're someone for whom writing code in web parlance is a piece of cake (or at least more doable than C/Java), this article will explain how you can use the knowledge you already possess in order to create mobile applications using the following three ingredients:

  • jQuery Mobile, an HTML5-based framework for developing web-based mobile applications.
  • Drupal 8's Web Services modules, which provide read and write access to Drupal's content for use in your application.
  • Adobe PhoneGap, which packages web-based applications as mobile apps for use on platforms such as iOS and Android.

Let's get started!

About Our App

First, when developing mobile applications, it's customary to give some thought to the flow of the user interactions. Here are some basic wireframes:

Figure 1: The two main screens of our mobile application: list and view.

The idea of our app is simple: display a list of nodes from the front page of a Drupal 8 site, and provide a links view for the content. Drupal 8’s web services can also edit and delete content, but we'll stick to view, both for article space constraints and to avoid some bugs that are still present in Drupal 8's alpha releases.

Categories: Drupal

DrupalCon News: Session Submission Recap for DrupalCon Barcelona

11 June 2015 - 6:41am
Putting on a DrupalCon is a huge enterprise, and it wouldn’t happen without help from our amazing community. While our end goal is always that our guests have a great time at the convention, much of a Con’s success depends on the amazing men and women who step up to give sessions and lead training programs.   
Categories: Drupal

Acquia: Migrating Content to Drupal: The Weather Channel

11 June 2015 - 6:31am

One of the major challenges facing every digital publisher is making sure its content will display properly up on every possible venue: desktop, tablet, and phone of course, but also in web services, and on the emerging display opportunities arriving with the Internet of Things, like wearables.

Acquia partner Mediacurrent recently tackled this challenge on an awesome scale: migrating the giant The Weather Channel site to Drupal in a way that worked with all the above venues, and then some. (Have you thought about how your content will look on gas station pumps? Mediacurrent and The Weather Channel have.)

Recently, Matt Davis, a senior Drupal developer at Mediacurrent, explained how the team approached this task, in the first blog post in a projected series on the topic: Migrating Weather.com To Drupal: Increased Content Portability.

If your goal is to "write once, use everywhere" (and it should be), this post is worth checking out.

Tags:  acquia drupal planet
Categories: Drupal

roomify.us: Re-using the repeating date field widget in custom Drupal forms

11 June 2015 - 2:05am
As part of our work on Rooms Tours, (coming soon!) we wanted to give users the ability to quickly and easily input regular tour dates/times. This is a quick overview of how you can easily get this in Drupal using the widget that comes from the Date module.
Categories: Drupal

groups.drupal.org frontpage posts: DrupalCamp St. Louis 2015 - June 20-21 - Register now!

10 June 2015 - 3:20pm

On June 20 - 21, people from all over the Midwest who use, design, develop and support Drupal will convene in downtown St. Louis for the second annual DrupalCamp STL. Meet us in St. Louis and help us forge new skills and friendships while furthering the Drupal project.

Registration is only $25, and if you register ASAP you'll get a soft, comfy T-shirt, a nice catered lunch, and an excellent lineup of sessions on Saturday, and sprints all day Sunday!

Check out the schedule for the day, which includes a keynote by Alina Mackenzie on getting involved in the Drupal Community.

Join us in the Learning Lounge on Saturday, and for Sprints on Sunday, to increase your Drupal knowledge, meet some other Drupal community members, and help make Drupal better!

Categories: Drupal

Open Source Training: There's an Updated Drupal Logo for Drupal 8

10 June 2015 - 12:44pm

Drupal 8 will ship with a new version of the Drupal logo, known as the Druplicon.

It's not the biggest news in the world, but this will make some people happy. The current version of the logo is 11 years old and has several design problems:

  • The lighting on the logo is from top left which can conflict with other sources.
  • The 'freaky alien' vibe.
  • It looks a bit dated.
  • Some people find it "sinister", or "mean".
  • The color scheme is muddy and out-of-sync with "Seven" administration theme.
Categories: Drupal

Drupal core announcements: Drupal 8 Jersey shore sprint, Asbury Park, June 13-14

10 June 2015 - 10:07am

June 13-14, 2015, the Central NJ Drupal Group is hosting a core sprint
focusing on the upcoming release of Drupal 8.

The current plan is to focus on [meta] Remove or document every SafeMarkup::set() call, continuing the work done at the recent Drupal 8 theme system critical issues sprint (June 5-7 in Portsmouth, NH.)

See the event post at https://groups.drupal.org/node/468408 for more details, and
registration information.

Categories: Drupal

SitePoint PHP Drupal: Multiple Editors per Node in Drupal 7

10 June 2015 - 9:00am

One of the things that makes Drupal great is its flexible user permission system. The out of the box permissions grid we are all familiar with covers most uses cases of controlling what users can and cannot do. It is also very easy for module developers to create new permissions and roles that restrict the logic they implement.

Nevertheless, I have encountered a practical use case where the default configuration options are not enough. Namely, if you need to have multiple users with access to edit a particular node of a given type but without them necessarily having access to edit others of the same type. In other words, the next great article should be editable by Laura and Glenn but not by their colleagues. However, out of the box, users of a particular role can be masters either of their own content or of all content of a certain type. So this is not immediately possible.

In this article I am going to show you my solution to this problem in the form of a simple custom module called editor_list. Article nodes will have a field where you can select users and only these users (or those who have full access) will be able to edit that particular node. You can find the module already in this git repository and you can install it on your site for a quick start. Do keep in mind that it has a dependency on the Entity Reference module as we will see in a minute.

I will keep the code comments to a minimum to save space but you can find them in the repository if you want. Basic knowledge of Drupal 7 is assumed in the remainder of this tutorial.

Continue reading %Multiple Editors per Node in Drupal 7%

Categories: Drupal

Lullabot: Holly Ross on the Drupal Association

10 June 2015 - 8:30am

In this episode of Hacking Culture, Matthew Tift talks with Holly Ross, the Executive Director of the Drupal Association, about the Drupal community, the Drupal Association, non-profits, business, tax codes, and more. They get into some controversial issues, and some of Holly's answers may surprise you!

Categories: Drupal

Dcycle: Add unit testing to legacy code

10 June 2015 - 7:40am

To me, modern code must be tracked by a continuous integration server, and must have automated tests. Anything else is legacy code, even if it was rolled out this morning.

In the last year, I have adopted a policy of never modifying any legacy code, because even a one-line change can have unanticipated effects on functionality, plus there is no guarantee that you won't be re-fixing the same problem in 6 months.

This article will focus on a simple technique I use to bring legacy Drupal code under a test harness (hence transforming it into modern code), which is my first step before working on it.

Unit vs. functional testing

If you have already written automated tests for Drupal, you know about Simpletest and the concept of functional web-request tests with a temporary database: the vast majority of tests written for Drupal 7 code are based on the DrupalWebTestCase, which builds a Drupal site from scratch, often installing something like a site deployment module, using a temporary database, and then allows your test to make web requests to that interface. It's all automatic and temporary environments are destroyed when tests are done.

It's great, it really simulates how your site is used, but it has some drawbacks: first, it's a bit of a pain to set up: your continuous integration server needs to have a LAMP stack or spin up Vagrant boxes or Docker containers, you need to set up virtual hosts for your code, and most importantly, it's very time-consuming, because each test case in each test class creates a brand new Drupal site, installs your modules, and destroys the environment.

(I even had to write a module, Simpletest Turbo, to perform some caching, or else my tests were taking hours to run (at which point everyone starts ignoring them) -- but that is just a stopgap measure.)

Unit tests, on the other hand, don't require a database, don't do web requests, and are lightning fast, often running in less than a second.

This article will detail how I use unit testing on legacy code.

Typical legacy code

Typically, you will be asked to make a "small change" to a function which is often 200+ lines long, and uses global variables, performs database requests, and REST calls to external services. Bit I'm not judging the authors of such code -- more often than not, git blame tells me that I wrote it myself.

For the purposes of our example, let's imagine that you are asked to make change to a function which returns a "score" for the current user.

function mymodule_user_score() { global $user; $user = user_load($user->uid); $node = node_load($user->field_score_nid['und'][0]['value']); return $node->field_score['und'][0]['value']; }

This example is not too menacing, but it's still not unit testable: the function calls the database, and uses global variables.

Now, the above function is not very elegant; our first task is to ignore our impulse to improve it. Remember: we're not going to even touch any code that's not under a test harness.

As mentioned above, we could write a subclass of DrupalWebTestCase which provisions a database, we could create a node, a user, populate it, and then run the function.

But we would rather write a unit test, which does not need externalities like the database or global variables.

But our function depends on externalities! How can we ignore them? We'll use a technique called dependency injection. There are several approaches to dependency injection; and Drupal 8 code supports it very well with PHPUnit; but we'll use a simple implementation which requires the following steps:

  • Move the code to a class method
  • Move dependencies into their own methods
  • Write a subclass replaces dependencies (not logic) with mock implementations
  • Write a test
  • Then, and only then, make the "small change" requested by the client

Let's get started!

Move the code to a class method

For dependency to work, we need to put the above code in a class, so our code will now look like this:

class MyModuleUserScore { function mymodule_user_score() { global $user; $user = user_load($user->uid); $node = node_load($user->field_score_nid['und'][0]['value']); return $node->field_score['und'][0]['value']; } } function mymodule_user_score() { $score = new MyModuleUserScore(); return $score->mymodule_user_score(); }

That wasn't that hard, right? I like to keep each of my classes in its own file, but for simplicity's sake let's assume everything is in the same file.

Move dependencies into their own methods

There are a few dependencies in this function: global $user, user_load(), and node_load(). All of these are not available to unit tests, so we need to move them out of the function, like this:

class MyModuleUserScore { function mymodule_user_score() { $user = $this->globalUser(); $user = $this->user_load($user->uid); $node = $this->node_load($user->field_score_nid['und'][0]['value']); return $node->field_score['und'][0]['value']; } function globalUser() { return global $user; } function user_load($uid) { return user_load($uid); } function node_load($nid) { return node_load($nid); } }

Your dependency methods should generally only contain one line. The above code should behave in exactly the same way as the original.

Override dependencies in a subclass

Our next step will be to provide mock versions of our dependencies. The trick here is to make our mock versions return values which are expected by the main function. For example, we can surmise that our user is expected to have a field_score_nid, which is expected to contain a valid node id. We can also make similar assumptions about how our node is structured. Let's make mock responses with these assumptions:

class MyModuleUserScoreMock extends MyModuleUserScore { function globalUser() { return (object) array( 'uid' => 123, ); } function user_load($uid) { if ($uid == 123) { return (object) array { field_score_nid => array( LANGUAGE_NONE => array( array( 'value' => 234, ), ), ), } } } function node_load($nid) { if ($nid == 234) { return (object) array { field_score => array( LANGUAGE_NONE => array( array( 'value' => 3000, ), ), ), } } } }

Notice that our return values are not meant to be complete: they only contain the minimal data expected by our function: our mock user object does not even contain a uid property! But that does not matter, because our function is not expecting it.

Write a test

It is now possible to write a unit test for our logic without requiring the database. You can copy the contents of this sample unit test to your module folder as mymodule.test, add files[] = mymodule.test to your mymodule.info, enable the simpletest modules and clear your cache.

There remains the task of actually writing the test: in your testModule() function, the following lines will do:

public function testModule() { // load the file or files where your classes are located. This can // also be done in the setUp() function. module_load_include('module', 'mymodule'); $score = new MyModuleUserScoreMock(); $this->assertTrue($score->mymodule_user_score() == 3000, 'User score function returns the expected score'); } Run your test

All that's left now is to run your test:

php ./scripts/run-tests.sh --class mymoduleTestCase

Then add above line to your continuous integration server to make sure you're notified when someone breaks it.

Your code is now ready to be fixed

Now, when your client asks for a small or big change, you can use test-driven development to implement it. For example, let's say your client wants all scores to be multiplied by 10 (30000 should be the score when 3000 is the value in the node):

  • First, modify your unit test to make sure it fails: make the test expect 30000 instead of 3000
  • Next, change your code iteratively until your test passes.
What's next

This has been a very simple introduction to dependency injection and unit testing for legacy code: if you want to do even more, you can make your Mock subclass as complex as you wish, simulating corrupt data, nodes which don't load, and so on.

I highly recommend getting familiar with PHPUnit, which is part of Drupal 8, and which takes dependency injection to a whole new level: Juan Treminio's "Unit Testing Tutorial Part I: Introduction to PHPUnit", March 1, 2013 is the best introduction I've found.

I do not recommend doing away entirely with functional, database, and web tests, but a layered approach where most of your tests are unit tests, and you limit the use of functional tests, will allow you to keep your test runs below an acceptable duration, making them all the more useful, and increasing the overall quality of new and even legacy code.

Tags: blogplanet
Categories: Drupal


Google+
about seo