Oct 08 2015
Oct 08

11 Liipers attended the DrupalCon Barcelona in September 2015. We learned a lot about Drupal 8. And heard over and over again: “Start working with Drupal 8 now!”.

But let’s have a look back: The development of Drupal 8 took more than 4 years and for me as a developer it sometimes seems, like no stone was left unturned. Almost everything has changed. Symfony2 walked onto the stage and brought some paradigm shifts in Drupal 8 that may prove to be a challenge for us as developers.

But the good news is that there are so much new features and tools, that make developing enterprise websites so much easier, that I would like to start new projects with Drupal 8 exclusively and never use Drupal 7 again ;-)

At DrupalCon, there were a lot of interesting sessions about exciting features for developers. My personal favourites were the following:

But what about new projects with Drupal 8?

Sure, all these new features sound exciting. But what about building new customer projects with Drupal 8? The answer isn’t that easy.

We at Liip already started to work with Drupal 8 and we can share some experience with other companies out there, who would like to start working with Drupal 8.

New simple CMS project with Drupal 8 will work out of the box!

Simple CMS projects that rely on Drupal 8 Core without the help of too many contrib modules will work out of the box. So many great features like Views, Page Manager and CKEditor are now part of the core. Drupal 8 matured and is now a full featured enterprise content management system capable of building websites based on structured data.

Nevertheless, there is an initial investment you will have to do, because the learning curve of Drupal 8 is quite steep. If you are not familiar with Object Oriented Programming (OOP) and Symfony2, you will have to put some effort to learn the new concepts. But as soon you managed that, your Drupal installations will become easier to deploy and ways better maintainable.

In our first smaller projects, we calculate with a 10-20% additional costs, because of missing knowledge and experience. we also will have to fix some of these early adopter bugs. These costs will be covered mainly by my personal education budget and also by some extra budget Liip AG has reserved for Drupal 8 transition phase.

If you plan to start a new project you should try to go with Drupal 8 if it’s somehow possible. This will protect your investment for the next few years and make sure, that the long term costs (aka maintenance) stay low. You can expect that in the near future all new Drupal websites will be build with Drupal 8. Additionally you can profit from all the new features. Even as an end user you have a much better user experience and a lot of benefits. If you are uncertain, you may contact us. We have a lot of expertise in this field and will figure out together with you if your project will work out with Drupal 8. In the end, it will be up to you to decide which version is implemented.

For new and complex project you will have to calculate quite some extra efforts!

Bigger project often depend on a lot of custom module. For example complex media management (as we had it in Drupal 7) is not ready at all. For every contrib module you have to evaluate and test, if there is a working Drupal 8 version. If there is none, you will probably have to upgrade parts of the module or looking for an alternative.

We calculate with more than 50% additional costs, if we have to upgrade complex contrib modules or parts of it. As we would like to contribute these modules back to the community, this number can grow quickly if you try to implement the new module in a generic reusable way.

Upgrading existing big Drupal 7 project To Drupal 8: Stay away!

At the time of writing I consider it absolutely senseless to upgrade big projects to Drupal 8 that rely on a lot of contrib modules. You would have to upgrade a lot of contrib modules and also completely rewrite your custom modules. Updating a contrib module means, that you have to understand the code someone else has written and transform it into working module on Drupal 8 (where you probably are not as experienced) and in the same time discover and use the new system / APIs / services. Quite a brave mission that probably will end up in a mess. You should try to avoid that.

So what should I do now?

Every Drupal site is different and especially the customer needs are different and have to be considered on a case by case basis. You will certainly have to calculate with additional internal costs that you cannot bill to your customer in your first Drupal 8 project.

But you should definitely now start working and building websites with Drupal 8. You will enjoy all the new features and make your customer happy with a fast, testable and user friendly system. And we hope, that you also contribute and help upgrading key modules. This helps the Drupal community a lot and will enable all of us to do more complex Drupal 8 projects in the near future.

Jul 15 2015
Jul 15

Regardless of industry, staff size, and budget, many of today’s organizations have one thing in common: they’re demanding the best content management systems (CMS) to build their websites on. With requirement lists that can range from 10 to 100 features, an already short list of “best CMS options” shrinks even further once “user-friendly”, “rapidly-deployable”, and “cost-effective” are added to the list.

There is one CMS, though, that not only meets the core criteria of ease-of-use, reasonable pricing, and flexibility, but a long list of other valuable features, too: Drupal.

With Drupal, both developers and non-developer admins can deploy a long list of robust functionalities right out-of-the-box. This powerful, open source CMS allows for easy content creation and editing, as well as seamless integration with numerous 3rd party platforms (including social media and e-commerce). Drupal is highly scalable, cloud-friendly, and highly intuitive. Did we mention it’s effectively-priced, too?

In our “Why Drupal?” 3-part series, we’ll highlight some features (many which you know you need, and others which you may not have even considered) that make Drupal a clear front-runner in the CMS market.

For a personalized synopsis of how your organization’s site can be built on or migrated to Drupal with amazing results, grab a free ticket to Drupal GovCon 2015 where you can speak with one of our site migration experts for free, or contact us through our website.

_______________________________

SEO + Social Networking:

Unlike other content software, Drupal does not get in the way of SEO or social networking. By using a properly built theme–as well as add-on modules–a highly optimized site can be created. There are even modules that will provide an SEO checklist and monitor the site’s SEO performance. The Metatags module ensures continued support for the latest metatags used by various social networking sites when content is shared from Drupal.

SEO Search Engine Optimization, Ranking algorithm

E-Commerce:

Drupal Commerce is an excellent e-commerce platform that uses Drupal’s native information architecture features. One can easily add desired fields to products and orders without having to write any code. There are numerous add-on modules for reports, order workflows, shipping calculators, payment processors, and other commerce-based tools.

E-Commerce-SEO-–-How-to-Do-It-Right

Search:

Drupal’s native search functionality is strong. There is also a Search API module that allows site managers to build custom search widgets with layered search capabilities. Additionally, there are modules that enable integration of third-party search engines, such as Google Search Appliance and Apache Solr.

Third-Party Integration:

Drupal not only allows for the integration of search engines, but a long list of other tools, too. The Feeds module allows Drupal to consume structured data (for example, .xml and .json) from various sources. The consumed content can be manipulated and presented just like content that is created natively in Drupal. Content can also be exposed through a RESTful API using the Services module. The format and structure of the exposed content is also highly configurable, and requires no programming.

Taxonomy + Tagging:

Taxonomy and tagging are core Drupal features. The ability to create categories (dubbed “vocabularies” by Drupal) and then create unlimited terms within that vocabulary is connected to the platform’s robust information architecture. To make taxonomy even easier, Drupal even provides a drag-n-drop interface to organize the terms into a hierarchy, if needed. Content managers are able to use vocabularies for various functions, eliminating the need to replicate efforts. For example, a vocabulary could be used for both content tagging and making complex drop-down lists and user groups, or even building a menu structure.

YS43P

Workflows:

There are a few contributor modules that provide workflow functionality in Drupal. They all provide common functionality along with unique features for various use cases. The most popular options are Maestro and Workbench.

Security:

Drupal has a dedicated security team that is very quick to react to vulnerabilities that are found in Drupal core as well as contributed modules. If a security issue is found within a contrib module, the security team will notify the module maintainer and give them a deadline to fix it. If the module does not get fixed by the deadline, the security team will issue an advisory recommending that the module be disabled, and will also classify the module as unsupported.

Cloud, Scalability, and Performance:

Drupal’s architecture makes it incredibly “cloud friendly”. It is easy to create a Drupal site that can be setup to auto-scale (i.e., add more servers during peak traffic times and shut them down when not needed). Some modules integrate with cloud storage such as S3. Further, Drupal is built for caching. By default, Drupal caches content in the database for quick delivery; support for other caching mechanisms (such as Memcache) can be added to make the caching lightning fast.

cloud-computing

Multi-Site Deployments:

Drupal is architected to allow for multiple sites to share a single codebase. This feature is built-in and, unlike WordPress, it does not require any cumbersome add-ons. This can be a tremendous benefit for customers who want to have multiple sites that share similar functionality. There are few–if any–limitations to a multi-site configuration. Each site can have its own modules and themes that are completely separate from the customer’s other sites.

Want to know other amazing functionalities that Drupal has to offer? Stay tuned for the final installment of our 3-part “Why Drupal?” series!

Jul 08 2015
Jul 08

why drupal

Regardless of industry, staff size, and budget, many of today’s organizations have one thing in common: they’re demanding the best content management systems (CMS) to build their websites on. With requirement lists that can range from 10 to 100 features, an already short list of “best CMS options” shrinks even further once “user-friendly”, “rapidly-deployable”, and “cost-effective” are added to the list.

There is one CMS, though, that not only meets the core criteria of ease-of-use, reasonable pricing, and flexibility, but a long list of other valuable features, too: Drupal.

With Drupal, both developers and non-developer admins can deploy a long list of robust functionalities right out-of-the-box. This powerful, open source CMS allows for easy content creation and editing, as well as seamless integration with numerous 3rd party platforms (including social media and e-commerce). Drupal is highly scalable, cloud-friendly, and highly intuitive. Did we mention it’s effectively-priced, too?

In our “Why Drupal?” 3-part series, we’ll highlight some features (many which you know you need, and others which you may not have even considered) that make Drupal a clear front-runner in the CMS market.

For a personalized synopsis of how your organization’s site can be built on or migrated to Drupal with amazing results, grab a free ticket to Drupal GovCon 2015 where you can speak with one of our site migration experts for free, or contact us through our website.

______

Drupal in Numbers (as of June 2014):

  • Market Presence: 1.5M sites
  • Global Adoption: 228 countries
  • Capabilities: 22,000 modules
  • Community: 80,000 members on Drupal.org
  • Development: 20,000 developers

Open Source:

drupalOS

The benefits of open source are exhaustively detailed all over the Internet. Drupal itself has been open source since its initial release on January 15, 2000. With thousands of developers reviewing and contributing code for over 15 years, Drupal has become exceptionally mature. All of the features and functionality outlined in our “Why Drupal?” series can be implemented with open source code.

Startup Velocity:

Similar to WordPress, deploying a Drupal site takes mere minutes, and the amount of out-of-the-box functionality is substantial. While there is a bit of a learning curve with Drupal, an experienced admin (non-developer) can have a small site deployed in a matter of days.

drupal-the-onion

Information Architecture:

The ability to create new content types and add unlimited fields of varying types is a core Drupal feature. Imagine you are building a site that hosts events, and an “Event” content type is needed as part of the information architecture. With out-of-the-box Drupal, you can create the content type with just a few clicks–absolutely no programming required. Further, you can add additional fields such as event title, event date, event location, keynote speaker. Each field has a structured data type, which means they aren’t just open text fields. Through contrib modules, there are dozens of other field types such as mailing address, email address, drop-down list, and more. Worth repeating: no programming is required to create new content types, nor to create new fields and add them to a new content type.

admin-screenshot

Asset Management:

There are a number of asset management libraries for Drupal, ensuring that users have the flexibility to choose the one that best suits their needs. One newer and increasingly popular asset management module in particular is SCALD (https://www.drupal.org/project/scald). One of the most important differences between SCALD and other asset management tools is that assets are not just files. In fact, files are just one type of asset. Other asset types include YouTube videos, Flickr galleries, tweets, maps, iFrames–even HTML snippets. SCALD also provides a framework for creating new types of assets (called providers). For more information on SCALD, please visit: https://www.drupal.org/node/2101855 and https://www.drupal.org/node/1895554

turner.premshow2

Curious about the other functionalities Drupal has to offer? Stay tuned for Part 2 of our “Why Drupal?” series!

Jun 02 2015
Jun 02

In April 2015, NASA unveiled a brand new look and user experience for NASA.gov. This release revealed a site modernized to 1) work across all devices and screen sizes (responsive web design), 2) eliminate visual clutter, and 3) highlight the continuous flow of news updates, images, and videos.

With its latest site version, NASA—already an established leader in the digital space—has reached even higher heights by being one of the first federal sites to use a “headless” Drupal approach. Though this model was used when the site was initially migrated to Drupal in 2013, this most recent deployment rounded out the endeavor by using the Services module to provide a REST interface, and ember.js for the client-side, front-end framework.

Implementing a “headless” Drupal approach prepares NASA for the future of content management systems (CMS) by:

  1. Leveraging the strength and flexibility of Drupal’s back-end to easily architect content models and ingest content from other sources. As examples:

  • Our team created the concept of an “ubernode”, a content type which homogenizes fields across historically varied content types (e.g., features, images, press releases, etc.). Implementing an “ubernode” enables easy integration of content in web services feeds, allowing developers to seamlessly pull multiple content types into a single, “latest news” feed. This approach also provides a foundation for the agency to truly embrace the “Create Once, Publish Everywhere” philosophy of content development and syndication to multiple channels, including mobile applications, GovDelivery, iTunes, and other third party applications.

  • Additionally, the team harnessed Drupal’s power to integrate with other content stores and applications, successfully ingesting content from blogs.nasa.gov, svs.gsfc.nasa.gov, earthobservatory.nasa.gov, www.spc.noaa.gov, etc., and aggregating the sourced content for publication.

  1. Optimizing the front-end by building with a client-side, front-end framework, as opposed to a theme. For this task, our team chose ember.js, distinguished by both its maturity as a framework and its emphasis of convention over configuration. Ember embraces model-view-controller (MVC), and also excels at the performance by batching updates to the document object model (DOM) and bindings.

In another stride toward maximizing “Headless” Drupal’s massive potential, we configured the site so that JSON feed records are published to an Amazon S3 bucket as an origin for a content delivery network (CDN), ultimately allowing for a high-security, high-performance, and highly available site.

Below is an example of how the technology stack which we implemented works:

Using ember.js, the NASA.gov home page requests a list of nodes of the latest content to display. Drupal provides this list as a JSON feed of nodes:

Ember then retrieves specific content for each node. Again, Drupal provides this content as a JSON response stored on Amazon S3:

Finally, Ember distributes these results into the individual items for the home page:

The result?

A NASA.gov architected for the future. It is worth noting that upgrading to Drupal 8 can be done without reconfiguring the ember front-end. Further, migrating to another front-end framework (such as Angular or Backbone) does not require modification of the Drupal CMS.

Jun 12 2012
Jun 12

Posted Jun 12, 2012 // 0 comments

Right now, the Drupal Apps module is open source software development at its very best -- collaborative, smart people, solving their problems by building a great tool set together to solve real problems. And we couldn't be more excited by what people are doing.

When we created the Apps module for OpenPublic in early 2011, we were trying to solve a very specific problem: we wanted to make it easier for distribution users and site builders to add functionality to their OpenPublic sites, without bloating the distribution with functionality that only some users would want. 

LevelTen has taken this strategy with their distribution, Open Enterprise, with great success. Knowing that their distribution's users have varying needs around things like blogs, FAQs, events, or image handling, they built these features in Open Enterprise as Apps, making installing, enabling, or disabling this functionality simple. But then they took it a step further, and contributed a great solution to Apps,  allowing users to choose their apps upon distribution installation. Big win for Apps, big win for distributions. 

So now, we're seeing an exciting evolution of the Apps and Appserver modules -- more and more, distribution owners are creating simple, clean "base distributions," and then utilizing Apps to "specialize" the distribution upon installation -- and we think it's pretty freakin smart. Pantheon's "Panopoly" is a Panels-powered base distribution. You can install the Panopoly apps (shown here), or, if you're a university, you can install Chapter Three's Open Academy set of apps on top of Panopoly and have a "University web site in a box." 

And across the pond, Node One is employing the same concept -- and the Apps module -- with Nodestream. As the product's notes explain, "NodeStream Core is the base platform and NodeStream products are great add on features that can be turned on or off to target your project for things like intranets, newspapers, or enterprise websites." 

What began as a simple solution to one distribution's challenges has grown to become a solution set for many of the challenges facing distribution owners and maintainers, and we're excited to see that. Finally, we can stop arguing about apps, because whether they’re accused of being “modules for dummies" or an evil vehicle for code-selling and community-destroying, it’s not productive. Instead, companies are seeing the module for what it is -- a way to make distributions lighter, more modular, and easier to use to solve more problems for site builders. Many thanks to those who have committed patches and contributed code to this project – we’re really excited to see where it goes next.

As a product director with us, Karen Borchert keeps Phase2 growing each day; she focuses on the business strategy for our products, including OpenPublish and OpenPublic.

Thanks to her deep background in product strategy, Karen can ...

Feb 22 2012
Feb 22

Now that we have created our products we'll dive into the Product display content type so that we can display our products to our users. In this instance we'll start out be re-using the nodes created by Commerce Kickstart, then we create two new displays for our remaining items. We finish up by rearranging the fields on the content type using Drupal 7's manage display configuration.

Jan 09 2012
Jan 09

Within the Drupal community, we continue to wrestle with what, exactly, these things called distributions should be, and could become. Going into D7, the benefits of distributions (and specifically, the tools that support building distributions) are clear to developers. For most shops, the notion of building a site without using (at the very least) features hasn't really been an option for the last few years. Within FunnyMonkey - like at many other shops - we treat custom builds as product development, creating an install profile to contain config that can't be pushed to features, and making use of drush make during the build. Again, this is nothing horribly unique; this workflow simplifies testing, and technical decisions can be directly traced to code or a feature. Over the course of even a mildly complex project, having a clean, replicable build for all team members to work against saves countless hours of time.

Mind the Gap

But this is really only of interest to developers, or to people who directly benefit from a clear development process. These benefits filter down (theoretically) to the end user and content administrator in the form of a site that is easier to manage and use. But, the power of distributions has yet to become obvious to less technical users because, up to this point, the focus of distributions has been on automating a site install that delivers complex functionality out of the box. Distributions have done a great job solving this issue. Between installation profiles, drush make, and features, many of the pain points of replicating site builds have been eliminated or minimized.

So, using distributions, Drupal can be used to create products, and everyone can build an app store, and developers can sit back and make it rain.

Except: while distributions have taken the pain out of replicating complex site builds, they still require ongoing maintenance. Like every other software system, technology requires periodic updates; Drupal is no exception. Any Drupal site, whether built from scratch or deployed from a distribution, requires maintenance over time.

Most distributions are based on a collection of features. As a result, maintaining a distribution raises an additional question: should a distribution attempt to stay synchronized with the features that power the distribution, or with the underlying modules that are used within these features?

Tracking Overridden Features

The reflexive answer - the satisfying answer, the one that we want to be right - is that any site built on a distribution should stay synchronized with the features that drive the distribution. Over time, these features will evolve, and will have new, better, shinier functionality. However, the strength of features makes managing the config covered by that feature potentially more complex over time (there are many strengths and advantages to features, but one of the most obvious is the ability to push complex config to code where it can be managed and tracked via version control). Even a simple change (adding a field to a view, adding a field to a content type, changing a variable that has been strongarmed, etc) results in the feature being overridden. Over time, these overrides will need to be tracked against the features in the base distribution, and reverting these overrides could potentially break customizations in the production site. So, on a production site with overridden features, the overrides need to be tracked and either merged or ignored on each feature update. This is very possible to do, but it requires a level of technical expertise that is generally beyond the immediate reach of the people that distributions are supposed to empower: less technical users who just want to launch and use a web site.

Distribution-based Sites as Standalone Web Apps

And this brings us to the other alternative: once a site has been deployed from a distribution, that site is essentially detached from the distribution, and the site should be viewed as a standalone web app. With this approach, the features used on the production site should be checked into version control, and all site-specific overrides should be committed. This approach cuts the site off from potentially all future improvements in the base distribution, but it ensures that all modifications remain untouched. And, of course, this method requires a level of technical expertise that undercuts one of the main selling points of distributions. Managing overridden features in a sane way requires technical expertise, and distributions are supposed to make it easier for non-technical people to run Drupal sites.

Middle Grounds

There are additional possibilities here for working with and adapting the features within a distribution, but all of these methods require a level of technical expertise that undercuts the "distributions will simplify Drupal for non-technical users" argument. Probably the best option involves having features that are well architected, and make logical separations with documented dependencies within features. Then, end users can turn on the features that they want, and then they can clone and modify or ignore the features that they don't want to use. This leaves the core features untouched and in synch with the base distribution, but it also creates an additional set of features that should be managed via version control.

In any case, no matter the approach, maintaining a complex web site requires technical expertise. Distributions take the pain out of deployment, but they haven't done the same for maintenance.

Where To Go From Here

At the risk of stating the obvious, keeping all features untouched is really only possible in a SaaS environment, or an environment where the site admin has the discipline to resist unnecessary changes to the config. Aside from these two scenarios, most sites will require some modifications to meet the specific needs of the people running the site. And it's worth noting that in a SaaS environment, people are used to not having full admin rights, so there are use cases where only providing limited admin access could work. But, for most people/organizations, one of the key appeals of Drupal is the ability to tinker, modify, and expand the base build. This is good, and normal, and natural; if an organization doesn't think about how to use their web site in different ways after the initial launch, they are essentially stuck in time, and that's not good, and distributions need to be flexible enough to support that reality. However, within the community, until we clarify what we mean when we talk about admininistering a site deployed from a distribution, people using distributions will remain uncertain about the best approach to keep their site working well over time.

Dec 08 2008
Dec 08

If you haven't tried to do video online, you'd be surprised at how difficult it is. There's a large number of formats out there, and often your source video isn't appropriate for displaying on a web page. The process of converting the source to a format and size that works online and then getting it into Drupal and delivered to your viewers turns out to be expensive and time consuming.

Many people turn to public video sites like Vimeo or Blip.tv for video transcoding and hosting and lie with having their video under the control of a third party. Others install ffmpeg on their web server, but that fails as soon as they have any volume. That's why we're proud to announce CDN2 -- a Drupal-native video platform that offloads video processing from your web server and gives you the delivery cost advantages of a content delivery network. It's on demand video transcoding and delivery, pre-integrated with Drupal.

CDN2 is a combination of a Drupal module and a hosted service that's designed to help you manage video with ease. The module allows you to transcode video into many different formats, from iPhone video to Flash video for the web, to high definition flash. It plugs into Drupal's permissions system, allowing you to specify user roles that are allowed to upload video, what formats they can transcode into, and who can view the different formats.

The display of your video is fully themeable and you can choose any flash video player you'd like. We've included support for FlowPlayer and DashPlayer, and adding your own is a simple matter of theming.

Unlike installing ffmpeg on your own server, this won't tie up server resources during upload and conversion, allowing you to scale your web site independently of your video services. We handle the upload, the transcoding, and even the hosting for the video files. Pricing is simple and starts at $2.50 for every GB you transcode, and $0.50 per GB for the bandwidth consumed by your video. There's no contracts to sign, just pay for what you use.

Using CDN2, you don't need to build anything to get started with video. No custom integration projects. No hardware or software to buy. No work involved in getting your video on the web. Download it and have your first video up and running in minutes.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web