Drupal is the #1 platform for web content management systems. It powers millions of websites in more than 180 languages, with a massive online community with more than 26,000 constantly building and sharing themes and resources.
Project management is often the unsung hero in our work. When a project is completed on-time, on-budget, and in-scope, the wheels of innovation keep moving. However, when poor project management takes hold, the work, creativity, and excitement can come to a screeching halt.
Single Sign On is an authentication service that allows users to use one set of credentials i.e(username and password) to login to multiple sites. For example you are creating a main website for an university and there are ‘n’ number of websites for ‘n’ number of departments in the same university. You can login to main website, that will allow you to login to the respective department sites as well.
For SSO, there are two main parts namely, IDP(Identity Provider) and SP (Service Provider).
Configuration of SimpleSAMLphp on Drupal 8 may vary according to IDP such as Shibboleth 1.3, A-Select, CAS, OpenID, WS-Federation or OAuth.
Here we going to see how to…
This one is dedicated to all my fellow Drupalers. There’s no better exercise for a brain than reading ancient chinese poetry taming Drupal 8. When I’m bored, I turn to Drupal!
Recently I got my Drupal 8 Address module updated and it turned out that from now on street address ...
Quizzes and contests are the ways to improve a user activity and to grab the attention of even a rather passive user. We’ll tell about Drupal modules enabling different widgets and voting feature/quizzes features: Webform default fields, Quiz, Advanced Poll and other are combined in this compilation. Click! :)
One of our OSTraining members asked about the current state of the Panels module in Drupal 8. They already had experience with Panels in Drupal 7.
Panels is one of the most popular ways to create page layouts in Drupal.
In this quick tutorial, we will show you have to create your Panel in Drupal 8. The process is definitely different when compared to Drupal 7, although many similarities remain.
For this tutorial, you do not need to have experience with Panels.
Cloud9 is an IDE and development environment in the cloud. Yeah yeah, buzzwords buzzwords, but what does this really mean?
Let's dig in a bit, starting with the positives.What I Like
I've been using it heavily for a few months now, and here are the features that stand out to me.Workspaces
C9 gives you "workspaces", each of which is a complete Ubuntu-based environment (i.e., a Docker container behind the scenes). This means that you can install stuff, use sudo, change config, etc. You can create and delete workspaces as you please.
You can really go to town on these things in pretty much any way that is useful.Workspace cloning
C9 also lets you clone workspaces to create new ones. Cloning is super fast - usually around 30 seconds for me from start to finish. This means I can do things like having a stock "Drupal" workspace that has all the tools and config that I like to have for Drupal projects, which I just clone when setting up a new Drupal site. There are other cool possibilities here too, which I'll get to shortly.
Sure, theoretically Vagrant and friends let you do this already for local environments, but the speed and ease that C9 brings to this process is unmatched compared to anything I've seen.Out of the box debugging (for Node.js, PHP, Go, and C++)
Interactive debugging is already there, waiting for you. In PHP for example, you just click the little "bug" icon before running your app, and then set a breakpoint wherever you want. No messing with xdebug config or path mappings or exposing ports, none of that. Just click and you're done.
This is especially nice for me on the Node.js side, since I've never learned how to set up a Node debugger and don't particularly want to.Custom runners
Cloud9 environments come with some pre-configured "runners", which are basically commands that you can run by clicking a button, and have their output stuck into their own tabs. For example, starting the app typically means starting the "Apache" runner to get the server running, which will throw Apache logs into the output of that tab.
That's all fine, but it gets more interesting when you create custom runners. You can drop in a name and command and some configuration such as the current directory, and then you have a nice little command runner waiting to be clicked. I like this for things like "grunt watch" which watches for Sass updates, but it's even more useful for commands with hard to remember names, so that you can kind of abstract that away. It's like shell aliases on steroids, in a way.Performance
Cloud9 is surprisingly quick given that it's a pretty bulky web app. I don't have an insanely powerful laptop or anything, and I found the Cloud9 IDE to be responsive enough that I never really saw any noticeable slowness, which is the goal after all.What I don't like No VPNs
Due to the way Cloud9 is built, it can't really connect through an existing VPN. So if you're trying to work on a site that is hidden behind a VPN, then it might be test to avoid Cloud9 for that project.IDE limitations
The C9 IDE is ok, but not good, and definitely not great. If PHPStorm is a 9/10 in terms of IDE functionality, then Cloud9 is more like a 4 or a 5. It's a pretty decent text editor, but a pretty lame IDE.
For example, it's missing features like:
- Jumping directly to a function definition from somewhere that function is called
- Auto-generating block comments with @params, etc., based on function code
- Function parameter hinting as you type
- Viewing all usages of a given function
- Project-wide autocompletion that works smartly and consistently
You can only clone your own workspace - you can't clone someone else's. This means that it's basically impossible to have a setup where a tech lead manages a "pristine" project workspace which everyone else can clone whenever they need to start fresh, or when new people are ramped on. I love the sound of that workflow, and it's disappointing that it isn't allowed.Credit card required for signup
You can't sign up to C9 without entering your credit card info, even for the free accounts. This isn't the end of the world for me or possibly for you, but it can be a real bummer when you want to give someone on your team access to your codebase to do some pair programming. The "how much do I really want this?" factor kicks into high gear when you're asked to pull out your credit card.Use cases Open source work
C9 is great for doing open source work. It gives you the ability to share your code or your environment when anyone just by sending a link, which can help a lot when collaborating on something remotely that is only on your local environment.
Plus, with workspaces being so cheap and powerful, you can have a separate workspace for each open source project that you maintain. That way, you always have an environment ready to be worked on for everything, and you never have to wonder if that environment you build 6 months ago for module X is still running and working.Demos
Creating a workspace specifically for a demo (or a prototype or anything else temporary that you want to show other people) can be really nice. It even gives you a URL to share with people so they can try out your demo with their own two hands.
This lets you work on your demo in a clean, empty environment, which can just be deleted when you're done.Random fiddling around
You know that thing where there's a new tool or app or whatever that you want to try installing, but you don't want to worry about adding more dependencies or possibly bringing in a different version of a dependency that will break something else?
The speed with which you can spin up C9 workspaces is great here. Create a workspace in a few seconds, do whatever you want, and delete it. That way you never have to worry about leaving any remnants of your random tinkering on your main computer.Pair programming
One of the banner features of C9 is the ability to live-edit code along with other people, and see each other's updates in real time. If you ever pair program, then this is basically the dream. It sure beats screen sharing over a Google Hangout.Debugging
The out of the box debugger support kind of automatically makes "debugging" a good use case for Cloud9. The fact that you have a full Ubuntu environment means that you can usually change whatever you need to change to replicate your prod setup, and the built in debugger can take it from there to help you find your bug.
Again, you can always just use Docker yourself to replicate an environment and install Xdebug, but this is just so much easier.Regular old development
If you can live without advanced IDE features, and you don't need a VPN to access anything, then you can really do most of your regular everyday development on C9. That way you have cheap workspaces and easy debugging and shareable URLs for everything that you work on.Tips
Finally, here are some tips for getting the most out of Cloud9, especially if you're using it for Drupal.
1. Start each workspace from a starter instance that has all the tools you need
For example, create a "Drupal" starter workspace that has Drush, Drupal Console, Apache config, git aliases, XHprof (here are installation instructions), etc. Then, whenever you spin up a new site, just clone that workspace.
2. Create per-ticket workspaces
Taking workspace cloning to the next level, you can just create a stock workspace for your project which you never actually touch except to keep it up to date. Then just clone it every time you start work on a new ticket. That way you can have completely separate environments for unrelated workstreams, and you never have to worry about clobbering data or whatnot when switching back and forth. Plus, that ticket you worked on 3 weeks ago will still have a working environment to go back to when it fails QA and needs a fix.
3. Make the keybindings match your main editor/IDE
Cloud9 has fully configurable keybindings for just about everything. This means that you can make C9 keyboard shortcuts match the ones you're already used to from your normal editor/IDE. That way it's really easy to switch back and forth. There are even Vim and Emacs modes!
4. Create custom runners for all the things
Think of all the commands you run on a regular basis. Things like "grunt watch" or "drush cc all" or "drush updb -y && drush fra -y", etc. Put all of those things in custom runners, so you can just click a button to watch them run in their own tab. This is especially useful for complex commands that you're likely to forget.
5. Go crazy with the layout
C9 lets you drag and drop tabs to dock to the left or right or bottom, and resize however you want. You can have a terminal on the right and server logs at the bottom, or keep them all in tabs in the same place. It's up to you.
6. Don't ignore the project search (and replace)
If you're like me then you might be tempted to install The Silver Searcher or Ack or just use grep to search your codebase. Before you do that, at least give C9's code search a try. It's fast, it supports regex, and it gives you lots of options about where you want to search. It's surprisingly robust, so give it a shot.The end
Overall I think Cloud9 is really pretty great for what it is. It's lacking some IDE features and it suffers a bit unavoidably just based on the fact that it's cloud based, but it also solves a lot of real world problems that make up for all that in most cases.
I'm using it for a pretty big chunk of my day to day development nowadays, and it's saved me plenty of headaches.
Do you have any concerns or questions? Feel free to comment below if so. I'm curious to hear about the types of things holding other people back from using it.mcrittenden Tue, 01/17/2017 - 17:26
The Drupal eCommerce market mainly consists of Ubercart and Drupal Commerce, but there are also some impressive emerging technologies to keep an eye on, such as the Stripe payment API, that allow for more customized solutions.
The eCommerce solution that you choose will depend upon the particular Drupal site you’re developing. Is it a simple online store with just a few products, or a much more robust site with a wide variety of products? This is one of the strengths of eCommerce with Drupal: you can build the kind of solution you need without the extra, unnecessary features and functionalities. Ubercart vs Drupal Commerce Drupal Commerce is by far the most popular Drupal eCommerce solution these days. It’s the successor to the original eCommerce solution, Ubercart. Drupal Commerce was written for Drupal 7 by the same developer that created Ubercart, Ryan Szrama, using the latest APIs and features for Drupal 7.
Drupal Commerce is supported by Ryan Szrama’s company, Commerce Guys, and the Drupal community as a whole. Developers are more likely to add new features to Commerce because it is more widely used in Drupal 7 and beyond. The Drupal 8 version is still in beta, so more work needs to be done to get it to a full release. Check out the Drupal Commerce issue queue to see where you might be able to help.
Drupal Commerce learned from Ubercart's primary shortcoming; it was difficult to configure and not very modular. Where Ubercart was one module that was difficult to build upon, Drupal Commerce has a small set of features in the main module and a large suite of available contributed modules. This allows for easier configuration and more customizations. Kickstart Your Online Store One of the most useful features available for Drupal Commerce is the Commerce Kickstart Drupal distribution. This is a great way for non-technical store owners to get a Drupal Commerce store up and running quickly and easily. It comes with an impressive installer that allows you to install an example store to see how everything can be configured. It then allows you to wipe the site clean and start a fresh build of your own custom store.
The Commerce Kickstart comes with some additional built in modules and configurations that help get a Drupal Commerce site up and running quickly. This is a more efficient solution than building from scratch with the Drupal Commerce module and any contributed modules that are necessary to achieve the desired functionality. The Commerce Kickstart distribution shows off the power of Drupal distributions; it’s a turnkey solution for Drupal eCommerce websites. Stripe API One of Drupal’s greatest advantages over its competitors is how well it integrates with third party APIs. This allows for integration with many different payment gateways, one being Stripe API. Drupal developers can integrate Stripe with a Drupal site through a custom module and create highly customized payment solutions. This type of customization allows for a variety of solutions for selling and accepting payments that would be more challenging to implement with Drupal Commerce. Which Solution Should I Choose? The solution you choose depends on the site’s needs. A small online store that only needs a simple shopping cart might be best suited for Ubercart. At its core, Ubercart is still the easiest to set up without using a Drupal distribution like Commerce Kickstart.
Drupal Commerce is a much more robust eCommerce solution for Drupal with enterprise level features that large online stores use to sell products like product displays. On top of that, you get all the features of a normal Drupal website like content types, taxonomies, and user permissions.
If you are looking to build a very customized payment solution that doesn’t really fit into either of these categories, perhaps a custom solution with the Stripe API module is best.
In the end, the Drupal eCommerce solution you choose should be easy to use for your store administrators and easy for your customers to buy your products online.
Configuration management (CM) in Drupal 8 is great. However, when more complex configuration scenarios arise, we must find solutions to problems that core CM functionality doesn’t address (yet).
Learn all about Twig templates in Drupal 8 from our very own Larry Walangitan.
This is the fourth post in a series about coding standards. In this post we’ll talk about why good, standardized documentation is crucial to your project, and review Drupal coding standards regarding documentation and comments.
Drupal 8.3.0, the next planned minor release of Drupal 8, is scheduled for Wednesday, April 5, 2017. Minor releases include new features, usability improvements, and backwards-compatible API improvements. Here's what this means now for core patches.Alpha vs. Beta releases
In previous Drupal 8 minor releases, the first pre-release version of the minor was labeled as beta1, and expectations were slightly different for later betas. For Drupal 8.3.0, we've recategorized this first pre-release version as alpha1, to distinguish it from the subsequent beta releases. (We will also no longer have "beta target" issues; some strategic issues are considered for backport to 8.3.x, but only after they are fixed in 8.4.x, and only up until the new beta phase begins.)
This change should provide better clarity and fairness on which issues are accepted for commit. The overall timeline for the minor release is not changed; alpha1 simply replaces the previous beta1, and the previous, stricter beta2 now becomes beta1. (More information on alpha and beta releases.) The release candidate phase is the same as for past releases.Drupal 8.3.0-alpha1 will be released the week of January 30
- In preparation for the minor release, Drupal 8.3.x will enter the alpha phase the week of January 30.
- Developers and site owners can begin testing the alpha.
- The 8.4.x branch of core will be created, and future feature and API additions will be targeted against that branch instead of 8.3.x. All outstanding issues filed against 8.3.x will be automatically migrated to 8.4.x once it is opened.
- All issues filed against 8.2.x will then be migrated to 8.3.x, and subsequent bug reports should be targeted against the 8.3.x branch.
- During the alpha phase, core issues will be committed according to the following policy:
- Most issues that are allowed for patch releases will be committed to 8.3.x and 8.4.x.
- Drupal 8.2.x will receive primarily critical bugfixes in preparation for its final patch release window. (Drupal 8.1.x and 8.0.x are not supported anymore and changes are not made to those branches.)
- Most issues that are only allowed in minor releases will be committed to 8.4.x only. A few strategic issues may be backported to 8.3.x, but only at committer discretion after the issue is fixed in 8.4.x, and only up until the beta deadline.
Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.
The release candidate phase will begin the week of February 27, and we will post further details at that time.
See the summarized key dates in the release cycle, allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.
As a reminder, we have until the start of the alpha to add great new features to Drupal 8.3.x. Stabilizing experimental modules (such as Inline form errors and Migrate Drupal), landing some key Media Initiative components, and working on bugfixes are all priorities for 8.3.0. Help with these changes now for a great Drupal 8.3.0!
Are you looking for an easy way to find errors thrown by your Drupal modules and themes?
A lot of new developers are learning to create their first Drupal 8 modules or Drupal 8 themes. Often they've made a very small typo or spacing error and are looking for an easy way to debug their mistake.
Follow this tutorial, and you'll quickly be able to see a detailed list of recent errors on your Drupal site.
I've previously written about dynamic forms in Drupal, using #states to show or hide input boxes depending on other inputs. Since then, Drupal 7 and 8 have both got the ability to combine conditions with OR and XOR operators. This makes it possible to apply changes when a form element's value does not equal something, which is not obvious at all.
The Drupal node access grants system has always been a powerful and flexible way to control access to your nodes. It's been there from Drupal 5 (if not earlier) and it continues to exist in Drupal 8 as we move forward. In this article, I want to quickly highlight this system from a D8 perspective and how I propose to use it in a OOP architecture.What is it?
The node access grant system is a way by which you can control programatically and very granularly access to all four operations on your Drupal nodes (view, create, edit, delete). It allows to define certain realms of functionality (related to your access requirements) and a set of grants that are required for any of the four mentioned operations, within that realm. Users will then need to posses the grants in the respective realms in order to be granted access.
The two main components of this system are therefore:
- The implementation of hook_node_access_records() which is called whenever a node is saved (or site-wide permissions rebuilt). It is responsible for storing the access requirements for that given node.
- The implementation of hook_node_grants() which is called whenever a user is trying to access a node (or a query is being performed in the name of that user). It is responsible for presenting the grants for the current user, which if match the access requirements of the node, allows them access.
The great thing about this node access grants is that it's system-wide in the sense of who checks for the access. In contrast to implementing hook_node_access() which only is called when viewing a node on its canonical URL, the access grants are checked almost everywhere such as views or even custom queries with much ease.Drupal 8
In Drupal 8 these 2 hooks remain the foundation of the node access grants system, albeit with type hinted parameters. This means that we need to place their implementation inside our .module files.
Node access grants are not used on every site because they serve relatively complex access rules. Complex access rules usually also require a fair bit of calculating what grants a particular node must have for a given realm, as well as whether a given user possesses them. For this very reason I am not so fond of having to put all this logic in my .module file.
So I came up with a basic developer module that defines an interface that has two methods: accessRecords() and grants(). Other modules which want to implement the access grants hooks can instead now create a service which implements this interface and tag it with node_access_grants. My module will do the rest and you won't have to touch any .module file. You can inject whatever dependencies from the container you need and perform whatever logic is needed for determining your grants and access records.
Let me what you think down in the comments. Would love your feedback.
Drupal Modules: The One Percent: Drupal Modules: The One Percent — Views Flipped Table (video tutorial)
Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Views Flipped Table, a module which will rotate your Views tables 90° and ask if using HTML tables is ever appropriate.
After ending 2016 with a new PHP version and starting 2017 with a new HTTP version, we’re happy to report that there’s still plenty of new left for us to launch. This time around it’s a new Apache Solr version, 6.3.