About 18 months ago I wrote about how you could sell access to Organic Groups with Drupal Commerce with a configuration of fields and Rules.
With Commerce License and Commerce License OG selling access to Organic Groups you have a setup that is as easy to setup than the 'old' field+Rules way (if not easier) and you'll have great new functionality for revoking membership access.Step by Step instructions
You can find the step-by-step instruction on how to sell your Organic groups with Drupal Commerce based on Commerce Licenses at https://www.drupal.org/node/2366023. Just follow the 8 easy steps and you'll have it setup in no-time.How does it work?
Basically you'll be selling licenses to your Organic Group (content). These licenses can expire, or be forever. You can configure them the way you see fit. The license determines if a user has access to the Organic Group or not.
Commerce License is a framework for selling access to local or remote resources.
Read more about Commerce Licenses at https://www.drupal.org/node/2039687 under Basic Concepts -> License.Show me
If you follow the 8 steps in the instruction at https://www.drupal.org/node/2366023 you'll see that you can easily configure the products like this:
and users on the site will be given licenses like this
From Dev to Stable
commerce_license_og module is currently in dev state. It works fine for the most common usecase: users buying access to your site. However make sure it works the way you want it before you decide go 'all in' implementing this on a production site.
Currently there seems to be an issue with granting anonymous users access to Organic Groups (https://www.drupal.org/node/2366155).
Please add your input to https://www.drupal.org/project/issues/commerce_license_og to help developing this module to a stable release.Category: Drupal Planet Drupal Commerce Drupal Organic Groups
This has been an interesting couple of weeks for Drupal, and that platform as a whole has received a lot of press. With the release of Drupal 7.32, a major (I use this term lightly) security vulnerability was corrected. Drupal then announced this week that, despite there being no significant evidence of a large number of sites attacked, any site that wasn't patched within a 7 hours of the patch release should consider itself compromised. Hosts were reporting automated attacks beginning only hours after the patch announcement. The vulnerability was unprecedented for the Drupal community, but really it shows why Drupal is great, and isn't a black mark on Drupal in our eyes.
First lets look at the announcement by the Drupal Security Team this week, where they say that sites were beginning to be attacked within hours of the patch announcement. The biggest thing to take from this announcement is the words Drupal Security Team. Yep, Drupal has one. I did a search this morning using the following criteria "<popular CMS> security team", and I found the results quite interesting. When I added Drupal as the "popular CMS" I got a page full of Drupal Security team information, policies and procedures. For every other CMS I tried, I got nothing about a team of security people, but a lot of information stating that they are secure and if you find a problem here is how to report it. Drupal focuses on security, and the Security Team at Drupal is a prime example of how important this really is to the Drupal community.
The second thing to take away from this is that the patch really notified the world that there was a vulnerability, and there is no way to stop this from happening. We didn't have any mass attacks on Drupal sites prior to this release, and the damage here after the release seems to be primarily related to those who chose not to apply the updates as they were instructed to. This really emphasizes the importance of applying available updates. Sites where the update was applied quickly likely did not experience any negative effects of the vulnerability, and if they did it was very limited. Updates to Drupal are certainly optional, but they are necessary to avoid headaches down the road, and this is proof of exactly why.
So don't be discouraged by all of the bad looking press related to this. I still stand by the idea that Drupal is the most secure platform available, but it is only as secure as you allow it to be. If you aren't applying the updates as they are available, you are likely putting your self at risk to have your site compromised. The big difference I see between Drupal and the other CMS options is that Drupal works diligently to fix module and core vulnerabilities as a habit. Many others aren't as diligent.For more tips like these, follow us on social media or subscribe for free to our RSS feed and newsletter. You can also contact us directly or request a consultation.
Bluespark Labs: Follow the readiness of the top 100 modules for Drupal 8 with our automatically updated tool
With the first Drupal 8 beta having been released at Drupalcon Amsterdam, we thought this would be a good time to a look at the top 100 projects on drupal.org to see just how far along the line the process of preparing for Drupal 8 is. However, given that there's a lot of progress to be made and I don't feel like manually updating a long list of modules, I decided to make a small tool to get the status of these modules and keep the data up to date.
This turned out to be a fun little project, and slightly more involved than I anticipated at first. (Isn't it always the case!) However, at its heart it's a bone-simple Drupal project - one content type for the Drupal projects (and their metadata) we're interested in, and a few views to show them as a table and calculate simple statistics. The work of updating the metadata from drupal.org is handled in 85 lines of code, using hook_cron to add each project to a Queue to be processed. The queue callback borrows code from the update module and simply gets release data, parses it, and updates the metadata on the project nodes. In the end, the most work was doing the research to determine which projects are already in core, and adding notes about where to find D8 upgrade issues and so on.
So, how did it all turn out? Using the current top 100 projects based on the usage statistics on drupal.org, our tool tells us that as of today, out of the 100 most popular projects:
Thanks for reading, and be sure to keep an eye on the status page to see how the most used contrib modules are coming along!Tags: Drupal PlanetDrupal 8
With the Drupal Security team's release of a public service announcement, the infamous security update known as 'SA-005' is back in the news. Even though it's old news, we've been fielding a new round of questions, so we thought we'd try to clear up some of the confusion.
Modules Unraveled: 124 Creating Drupal Configuration in Code Using CINC with Scott Reynen - Modules Unraveled Podcast
- What is CINC?
- How is it different from Features or Configuration Management?
- Is it something you use on an ongoing basis? Or is it just for the initial site setup?
- What types of configuration can you manage with CINC?
- What if you already have a content type created, and you want to add a field to the content type?
- How does that affect existing content, and new content.
- What about the reverse? Can you remove a field?
- What happens to the data that is already in the database?
- Can you undo configuration that you’ve created with CINC?
- How do you prevent site admins from disabling the module and deleting their content types?
- CINC YAML
- CINC & Features
- CINC & Drupal 8 Config API
- How do you see CINC working in a headless Drupal setting?
- Create dozens of fields quickly.
- Add a field to a content type after an existing field.
- Update configuration only if it still matches the default settings.
- How do you use this in a dev/staging/production
- Have you noticed any improved feedback, improvements to your workflow while using CINC?
- If people want to jump in and help development or work on new features what should they do?
As extremely pedantic developers we take documenting our APIs very seriously. It's not rare to see a good patch rejected in code review just because the PHPdocs weren't clear enough, or a @param wasn't declared properly.
In fact, I often explain to junior devs that the most important part of a function is its signature, and the PHPdocs. The body of the function is just "implementation details". How it communicates its meaning to the person reading it is the vital part.
But where does this whole pedantic mindset got when we open up our web-services?
I would argue that at least 95% of the developers who expose their web-service simply enable RESTws without any modifications. And here's what a developer implementing your web-service will see when visiting /node.json:
They say that hindsight is 20/20. With the many advances that have happened in the Drupal community recently, we asked our team "What is the one thing you wish you knew about Drupal two years ago?"
Much like an evolutionary tree our goal in technology adoption is too continue to move forward and evolve, rather than getting caught in a dead end. In the natural world, becoming bigger can be good but can lead to extinction events should the environment or food source change. Right now we are in a technology Jurassic...
If you have been around CodeKarate.com for awhile you have noticed that our branding has been, we
"Like a lot of people, I did both sides of technology; working on paid, proprietary systems [and open source]. There is a big difference. I can't imagine myself going back to any proprietary system where I have to pay; I can't share the code I am doing with anyone; I have to ask a company about the right tool to use. I love the way that everybody contributes to the same piece of code, trying to make it the best ... and for free!"
From October 13 - 16, 2014, I had the opportunity to go to (and the priviledge to present at) Islandora Camp Colorado (http://islandora.ca/camps/co2014). These were four fairly intensive days, including a last day workshop looking to the future with Fedora Commons 4.x. We had a one day introduction to Islandora, a day of workshops, and a final day of community presentations on how Libraries (and companies that work with Libraries such as ours) are using Islandora. The future looks quite interesting for the relationship between Fedora Commons and Drupal.
- The new version of Islandora allows you to regenerate derivatives on the fly. You can specify which datastreams are derivatives of (what I am calling) parent datastreams. As a result, the new feature allows you to regenerate a derivative through the UI or possibly via Drush, which something the Colorado Alliance is working to have working with the ...
"DrupalCamp Ohio 2014 returns to The Ohio State University's Nationwide and Ohio Farm Bureau 4-H Center, for another two-day camp to build on last year's success, and will include keynote speeches, topical sessions, Beginners Training, Birds of a Feather breakouts, and code sprints."
This article will be more about the patterns you need to use during Drupal 8 development than how to fit the various pieces together.
There’s good reason for this approach: fitting the pieces together has plenty of examples, change records, and whatnot – but many pieces of the puzzle are entirely new to Drupal developers.The Background
The first half of this article provides general PHP information which uses Drupal as an example, but is not Drupal specific. The idea behind this is that the knowledge can be reused well (indeed, this was also a design goal for Drupal 8).Classes, Objects, Interfaces
In Drupal 7, stdClass was used at a lot of places; ergo, classes (like stdClass) and objects (instances of a class, like node, user, etc.) should be familiar. stdClass is a class without methods, and the properties are not defined ahead of time. In PHP, it’s valid to set any property on an object, even if it’s not defined on its class. So, stdClass worked much like an associated array, except that it used arrows instead of brackets. Another important distinction between arrays and objects is passing them to a function: in PHP5, if a function/method gets an object and then changes the object, it will affect the object everywhere – objects are not copied every time, while arrays are.
Before creating a custom module it's a great idea to see if it has already been written. npmjs.org is the place to look. When you find a module you’d like to include in your project, retrieve it and add it as a dependency with npm. For example, to install lodash:npm install lodash --save
Requiring modules from NPM is done just like local modules but you don’t have to provide the path, just use the module name. require will look in the node_modules folder automatically.var _ = require(‘lodash’);
First install it globally with npm. Globally installed modules can be accessed from anywhere on your machine.npm install -g browserify
build/myModule.js is now browser ready! Now you can add it to your website.Come see me at BADCamp
However, although Views is powerful, it is too complex for many Drupal users and Node Gallery remains popular. So here's an update that shows how to use Node Gallery in Drupal 7.
Node Gallery is still the easiest way to build a photo gallery in Drupal. It requires very little set-up and almost no configuration.
What's new at SooperThemes
Welcome to the fifth redesign of sooperthemes.com!
The fifth major update to sooperthemes.com is the biggest update ever. It's a completely new site, unlike the previous sites which were built on top of the original alldrupalthemes.com (2007!)!
The new site comes with a big shift in focus. With Drupal 7 sites becoming more complex, and the upcoming Drupal 8 introducing new power and flexibility, but also complexity, we work hard to offer tools, services and products that allow everyone to profit form Drupal's flexibility without having to suffer the steep learning curve (alone). In addition to selling Drupal themes with turn-key demo sites we now offer more services:
- Custom built ticket system on sooperthemes.com, to work alongside e-mail support
- Design to Drupal service, for affordable and top quality Drupal themes based on your own design
- Enterprise Drupal services, including art direction, design, theming, data driven design and consulting.
- No more one-off theme sales, total focus on club membership and long term support
Our new tools are the best part, read on to learn about our major plans to support Drupal for small/medium businesses.Drupal Developers will Love these New Tools: A new Distribution: Drupal CMS Powerstart
Drupal's awesome architecture is what makes it such an awesome alternative to competing CMS like Wordpress and Joomla, but setting up shop with Drupal is described by many as painful and too complicated. Here, Drupal's power in flexibility is also it's weakness. It takes too much time to install basic features like WYSIWYG with media management: you need to find modules and set up complicated configurations, sometimes needing patches or development versions of modules, external libraries, etc.
To solve this problem, we created a Drupal CMS Distribution, targeted to small business sites and aiming to make life easier for developers and shops who create small sites.
Dries has mentioned in several keynotes that Distributions are the key to make Drupal more accessible and therefore the Drupal ecosystem more succesful. We too believe distributions are the solution but we don't like how they are currently made and how they are managed by drupal.org. Therefore we have created a new interface: A user-friendly interface to our distribution that lets you pick features, so that you don't get a bulky distro with everything in it, and the kitchen sink.
Check out the custom build interface to Drupal CMS Powerstart:
In order to create a truly responsive distribution, we developed and refined a lot Bootstrap 3 Drupal-integration. Responsive grid control from Views, content organisation with Bootstrap shortcodes: https://www.drupal.org/project/bs_shortcodes and all our features come with default layouts that regardless of whether you use a Bootstrap theme.
Development of Drupal CMS Powerstart is sponsored by sooperthemes.com and if you want to support future development of this new platform, please help beta testing and/or consider becoming a member of our premium themes club, you can see our "premium themed" version of CMS Powerstart here: http://glazed-demo.sooperthemes.com/ - more Drupal themes.Tags sooperthemes drupal 7 drupal 8 distributions cms planet drupal planet cms powerstart Drupal 7.x
After six years of working with Drupal, I’ve seen many successful Drupal projects. I’ve also felt how hard it is to become an experienced Drupal developer. When I asked myself why some Drupal projects succeed while others don’t, I came to this conclusion: the projects that integrate with Drupal core and the contrib ecosystem – i.e. the ones that use "best practice" deployment workflows and try to use configuration instead of custom code – keep their flexibility, stay maintainable and avoid "niche know-how". This then ensures that the project can be continued even if the team changes. Of course, there are lots of other non-technical factors that make projects successful but we’re focusing here on the technical ones. The problem is that there’s no central repository of "best practices": almost all developers or Drupal shops have their own.
This brings me to the point of considering some Drupal design patterns. Whereas in object-oriented programming, developers have patterns for their object models to solve specific problems that appear again and again, we haven’t yet established any in Drupal. But if we look at the configuration layer of Drupal as a "programming language", we could describe some patterns or best practices that would help others with problems that have already been solved hundreds of times before. This would have the same benefits as design patterns in other programming languages. Solutions for equivalent problems / requirements are always designed in a similar way. For any given workflow we could always use the same rules, so everybody would know where to go to change some behavior. The result would be that modules wouldn’t implement their own logic in code but provide actions, events and conditions, and some default rules. People still wouldn’t find a Drupal image gallery module but they would know how to build one according to some patterns. Of course we’d have a longer dependency chain for some modules, but is this really a problem if we’re depending on standard modules?
When to choose which module – would patterns work for this?
With more than 8000 modules available at Drupal.org, new Drupal users may find it hard to get started. What usually happens is that they enable lots of modules to test them; if the module works for their requirements, it remains enabled. If the user is a technical person, maybe even a developer, he/she will most likely use the Drupal API to extend the Drupal app.
But wouldn't it be great if we had a list of modules that were "state of the art" for best practices such as using rules for workflows and business logic, ECKs and fields for data structure modelling, views for lists and data queries, restWS and WSclient for communication with other applications, entity view modes in combination with panels for layouting, and features for the deployment. Considering the above, I’ve created the Drupal application stack poster to collect all our modules – along with their specific use cases –and to share this overview with the community. Shouldn't we always have a "Drupal-relevant set" of modules in mind when it comes to the modelling process of our Drupal app? This would keep Drupal apps sustainable and flexible.
Dos and don’ts
There are also some examples of what not to do. In a few projects that had crashed before they came to us to be rebuilt, it became clear that the previous developers had exactly the problems listed above. They had no guide to help them figure out when to use the API and when to choose which module, which further led to code and architectures that nobody but the developer could maintain. After the first release, the projects weren’t extendible, as there was no deployment process established. Wouldn't it help to collect these examples as well, to help people avoid them and get on the right path with Drupal? With a list of positive and negative patterns, we could give users some objective criteria for rating the implementation of their Drupal project.
Distributions – start from a higher level
Distributions built on such best practices as Drupal commerce kickstart or ERPAL Platform provide a good starting point for new Drupal developers, since they can see how experienced Drupalistas created the distros and which modules they used. Distros can be showcases for Drupal design patterns or a kick-start for vertical use cases like e-commerce sites or business applications.
If we want the Drupal community to grow, we should help others find the right starting point – not just any old one that could lead them off in the wrong direction: while they might see some quick results, if it wasn’t the right approach, they would only realize that after days of work. Once too much time has elapsed, with the money already spent and the deadline looming ever closer, nobody will ever refactor the Drupal application to improve its structure.
With Drupal design patterns, we’d be able to offer standard solutions to often-complex problems. What are your thoughts about Drupal design patterns? Would this bring us another step closer to making Drupal into a world-leading web application framework?
With Halloween just around the corner, I thought it might be fun to hand out some tasty treats. Don't worry, you're not getting fruit or pennies. It's something much more fun! I designed a custom Halloween icon set, which is free to download and use however you want. With Drupalize.Me's scary good Drupal training, it's fitting that these icons can spook, sweeten, or surprise your next project.
Visualization some complex part of Drupal is helping understand Drupal better. This is about the menu tree using Graph Viz for a static SVG diagram and D3JS for a dynamic version.
Autocomplete is a feature for textfields in Drupal. It provides a dropdown list of matching options from the server. It is implemented through AJAX. To know how to add an autocomplete form element in Drupal visit https://www.drupal.org/node/854216
For customizing autocomplete we need to override the Drupal system file "misc/autocomplete.js". This can be achieved ideally in two ways:
Override "Drupal.ACDB.prototype.search" with a custom behaviour in theme script.js or module js file, as long as it's added after /misc/autocomplete.js it will override it.