Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 9 hours 56 min ago

KnackForge: How to update Drupal 8 core?

23 March 2018 - 10:01pm
How to update Drupal 8 core?

Let's see how to update your Drupal site between 8.x.x minor and patch versions. For example, from 8.1.2 to 8.1.3, or from 8.3.5 to 8.4.0. I hope this will help you.

  • If you are upgrading to Drupal version x.y.z

           x -> is known as the major version number

           y -> is known as the minor version number

           z -> is known as the patch version number.

Sat, 03/24/2018 - 10:31
Categories: Drupal

Valuebound: Drupal 8: How to create a custom block programatically

18 December 2016 - 11:33pm
Drupal 8: How to create a custom block programatically Jaywant.Topno Mon, 12/19/2016 - 02:33
Categories: Drupal

Valuebound: Drupal 8: Custom Block Creation programmatically

18 December 2016 - 11:33pm
Drupal 8: Custom Block Creation programmatically Jaywant.Topno Mon, 12/19/2016 - 02:33
Categories: Drupal

Palantir: From Intern to Employee: What to Expect in the Transition

30 August 2016 - 10:59am
From Intern to Employee: What to Expect in the Transition brandt Tue, 08/30/2016 - 12:59 Matt Carmichael Aug 30, 2016

Internship experience is extremely valuable, especially in web development. So what can you expect in the transition from coursework to client work?

In this post we will cover...
  • The benefits of having an internship
  • What learning challenges you can expect

Want to work at Palantir?

Send us your resume!

The transition from student to full-time programmer can be intimidating. The days of submitting buggy and poorly-tested code that is just good enough to get a passing grade are over. Every line of code is just as important as the last, and even the smallest mistakes could lead to catastrophic problems for your team and your client. But trust me, it's doable!

I was lucky enough to have an internship at Palantir the summer before becoming a full-time employee. The opportunity to dive into the professional side of development without having quite the expectations of a full-time employee is priceless in my opinion. It gives you a chance to focus more on the learning experience of being a developer, without stressing as much over productivity and results. 

The most prominent takeaways from my time as an intern were learning and engaging in the process of collaborative programming with a team and also understanding the importance of code quality. In school a majority of the projects are done individually and you rarely have to rely on anyone else to get the job done. This is one of the biggest adjustments to make, as the workplace is the exact opposite. The members of your team need your code to be correct, verbose, and understandable in order to do their jobs. That being said, coding standards cannot be stressed enough in a team environment and doing things ‘your way’ is not going to cut it. 

At Palantir, I was introduced to an extensive Github repository devoted to documenting our code standards and development process. Familiarizing myself with the workflow, documentation, and code style expectations seemed like a full time job in its own right. Every line of code is submitted in a pull request which is inspected by a senior engineer and tested against the standards that are laid out in the developer documentation. 

Issues as seemingly trivial as the size of an indentation and documentation formatting are sent back to the programmer for revisions. Once the code has been through the critique and revision phase and is cleared by the engineer, the code is finally merged into the master branch and is ready to go into production.  This level of attention to details that seem trivial at a glance, but are vital for code consistency and readability, is in place to ensure the best product for the client.

Once you get past the logistics of teamwork, and the code standards become second nature to you, it's all uphill from there. As I settle in and become more confident in my role I realize how exciting worklife is. The opportunity to work with people of all backgrounds and skillsets and to see a project come together from start to finish is what makes it all worthwhile. 
 

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.
Categories: Drupal

Chromatic: Drush SQL Sync Alternative: SQL Sync Pipe

30 August 2016 - 10:56am

Using Drush to sync databses (drush sql-sync) is a valuable tool, but it is not always an efficient choice when dealing with large databases (think over 1GB). SQL Sync Pipe (drush sql-sync-pipe) is a Drush command that provides an alternative for drush sql-sync that streams the database dump directly from the source to the destination as opposed to sql-sync saving the database dump, transferring it via rsync and then importing the dump file. As an added bonus it excludes cache tables by default.

Benchmarks

Below are examples from the command's README, syncing the same 1.05Gib database using the two different methods:

drush sql-sync Command: drush sql-sync @alias.dev @alias.sandbox --no-cache Transfer size: 88.1MiB (compressed using rsync) Import size: 1.05GiB Total time elapsed: 46 minutes 47 seconds drush sql-sync-pipe Command: drush sql-sync-pipe @alias.dev @alias.sandbox --progress Transfer size: 88.1MiB (sent compressed using gzip) Import size: 1.05GiB Import & transfer time: 27 minutes 05 seconds Total time elapsed: 30 minutes 35 seconds

What are you waiting for? Download and install SQL Sync Pipe and get started!

drush dl drush_sql_sync_pipe --destination=$HOME/.drush && drush cc drush
Categories: Drupal

Drupal.org blog: Documentation overhaul

30 August 2016 - 9:11am

One of the biggest content areas on Drupal.org—and one of the most important assets of any open source project—is documentation. Community-written Drupal documentation consists of about 10,000 pages. Preparations for the complete overhaul of the documentation tools were in the works for quite some time, and in the recent weeks we finally started to roll out the changes on the live site.

Background

Improving documentation on Drupal.org has been a part of a larger effort to restructure content on the site based on content strategy we developed.

The new section comes after a few we launched earlier in the year. It also uses our new visual system, which will slowly expand into other areas.

Goals and process

The overall goal for the new Documentation section is to increase the quality of the community documentation.

On a more tactical level, we want to:

  • Introduce the concept of "maintainers" for distinct parts of documentation
  • Flatten deep documentation hierarchy
  • Split documentation per major Drupal version
  • Notify people about edits or new documentation
  • Make comments more useful

To achieve those goals, we went through the following process:

First, we wrote a bunch of user stories based on our user research and the story map exercise we went through with the Documentation Working Group members. Those stories cover all kinds of things different types of users do while using documentation tools.

We then wireframed our ideas for how the new documentation system should look and work. We ran a number of remote and in person usability testing sessions on those wireframes.

Our next step was to incorporate the feedback, update our wireframes, and create actual designs. And then we tested them again, in person, during DrupalCamp London.
Incorporated feedback again, and started building.

The new system

So, how does the new documentation system work exactly? It is based on two new content types:

  1. Documentation guide: a container content type. It will group documentation pages on a specific topic, and provide an ability to assign 'maintainers' for this group of pages (similar to maintainers for contributed projects). Additionally, users will be able to follow the guide and receive notifications about new pages added or existing pages edited.
  2. Documentation page: a content type for the actual documentation content. These live inside of documentation guides.


Example of a new documentation guide

All of the documentation is split per major Drupal version, which means every documentation guide or page lives inside of one of a few top level 'buckets', e.g. Drupal 7 documentation, Drupal 8 documentation.
It is also possible to connect guides and pages to each other via a 'Related content' field, which should make it easier to discover relevant information. One of our next to-do’s is to provide an easy way to connect documentation guides to projects, enabling 'official' project documentation functionality.

More information on various design decisions we made for the new documentation system, and the reasons behind them, can be found in our DrupalCon New Orleans session (slides).

Current status

Right now, we have the new content types and related tools ready on Drupal.org.
We are currently migrating existing documentation (all 10,000 pages!) into the new system. The first step is generic documentation (e.g. 'Structure Guide'), with contributed projects documentation to follow later.

While working on the migration, we are recruiting maintainers for the new guides. If you are interested in helping out, sign up in the issue. Please only sign up if you actually have some time to work on documentation in the near future.

There is a lot of work to be done post-migration (both by guide maintainers and regular readers/editors). The content is being migrated as-is, and it needs to be adapted for the new system. This means almost every single page needs to be edited. New fields (such as Summary) filled out with meaningful text (to replace text automatically generated by the migration script). A lot of pages include information for both Drupal 7 and Drupal 8, but this content needs to be split, with Drupal 8 information moved to pages in the appropriate version of the guide. These are just some of the steps that need to happen once the documentation has been migrated into the new system.

Next steps

As staff, we have a few follow-up tasks for minor improvements to the content types and tools. However, the bulk of the work is editing and improving the actual documentation, as I described above. This is in your hands now. Not only do we not have enough staff members to edit every single documentation page in a reasonable amount of time, we are also not subject matter experts for many of the topics, and so can't provide meaningful edits. The tools are ready, now it is up to the community to pick them up and write great documentation.


Example of a documentation page

Thank you

Lastly we want to say thanks.

Thanks to all the community volunteers who wrote those 10,000 pages over the years. Thanks to the Documentation Working Group members for their expertise, insight, and patience.

And, of course, thanks to staff. Unfortunately due to recent changes for the Engineering team, this will be the last section we'll have resources to work on for a while. This was a fun and important project to work on, and we are glad that we got to finish it. It is a beautiful legacy of the work we did together with some of our former colleagues: DyanneNova, japerry, and joshuami. Thank you!

Categories: Drupal

Sooper Drupal Themes: "It starts with something small" Next Gen Drupal Themes From 1.0 To 2.5 In a Single Year

30 August 2016 - 9:00am

Just over a year ago I started with something small. I combined some existing technologies to create a drag and drop builder/theme. A combination of jQuery UI, CKEditor, Bootstrap 3 and Drupal. The result was far from perfect but interesting enough to get a bunch of people excited and involved in helping me find out how to improve the product.

Above: our Glazed main demo. Click to view full demo. Glazed Construction Design, Product Updates

Today's blog celebrates the new Construction design that is available today to all SooperThemes members. We've been working towards this release for nearly a year and the reason it took so long is that the core of the Glazed framework theme and drag and drop builder needed to be 100% up to the job. The reliability, sophistication and flexibility of our framework theme and drag and drop builder are lightyears ahead of the minimum viable product we released 14 months ago. To our customers who joined us in the beginning and are now renewing for the second year: Thank you so much! 

Our construction theme (click to view demo) is not the prettiest design I've ever created but that's not really the point. The point is that it looks like a construction theme all the way. It doesn't look like a generic theme that was customized to look a little bit more "heavy industry". Our Glazed framework theme allows you to completely design every aspect of your Drupal site from typography, to colors, grid design and navigation. Combine this with our drag and drop builder and everything you need in a business website can be designed and developed in the browser. From a blank canvas all the way down to the pages, views and forms everything in this demo was created in the browser, without writing a single line of code

No templates were edited, no CSS was written, not even a single hand coded HTML tag was needed to build this unique 40 page Glazed demo.

For more details about todays products updates check out the Glazed Changelog and Carbide Builder Changelog.

Why WordPress Is Taking Turf From Drupal 

It's simple economics. You can buy a WordPress theme for $59,- USD and a few days of customization and content editing later and your client is impressed and your project is comfortably on schedule and on budget. WordPress themes have become a major source of innovation in recent years, offering drag and drop builders, and niche-specific features for magazine websites, directory websites and all sorts of small business websites.

Themes are becoming more sophisticated and crawling into Drupal territories like for example education, magazines and community websites.

10 years ago I moved away from WordPress and Mambo because I simply felt Drupal was better, and I still feel that way. While these WordPress themes are loaded with features, they lack Drupal's modularity, coding standards and interoperability. I sincerely believe Drupal can be a better platform for all these themes. After all, Drupal has built in support for content types, relations, versioning, configuration management, and superior user management and access control.

Starting from today I will focus on offering as many niche designs for small businesses, large businesses, NGOs, governments, educators and online magazines. I hope that you will join sooperthemes.com and help us with our mission to show the world that Drupal is capable of doing what WordPress does and more. 

Our mission as SooperThemes is to promote Drupal as the #1 platform to author content on the web and at the same time to remain the #1 provider of designs and design tools for Drupal. See our roadmap for more details. The way to make Drupal the number one choice again is through the same economics that made WordPress so big, so our initial focus is to disrupt the market with a 90% decrease in costs of building and running a Drupal website.

Enjoying The Ride 

The past year has been a big adventure but also a lot of grinding, bug fixing, technical debt problems and all the things that new products face when they enter the market. However it has mostly been fun and exciting to develop these new technologies for the Drupal community and the reception of our updates is really motivating and powering our new developments.

Allthough pioneering in the area of next gen (drag and drop) Drupal themes meant facing a steep learning curve it can be said that Drupal is actually easier to build on in the long term. Our Drag and Drop builder is very similar to a frontend framewor that uses the CMS as an API. This is somthing that needs hooks and AJAX capabilities. Something that Drupal provides out of the box.

If you are reading this as a prospective customer: please join Sooperthemes and enjoy the ride with us. To our existing customers: keep your eyes open for exciting new features and designs. 

Categories: Drupal

Appnovation Technologies: Becoming an Appnovator

30 August 2016 - 8:21am

Categories: Drupal

Tag1 Consulting: Drupal 6 Long Term Support is My Favorite Feature of Drupal 8

30 August 2016 - 8:04am
rfay Tue, 08/30/2016 - 08:04

Long Term Support for Drupal 6 might be my favorite new feature included in Drupal 8. (I know, that might be stretching things for the fundamentally awesome step forward that Drupal 8 is, but bear with me.)

Categories: Drupal

InternetDevels: Collection of great free responsive Drupal themes 2016

30 August 2016 - 5:53am

According to the best practices of responsive web design, a website neatly adapts to whatever screen it is viewed on. And according to the best practices of our blog, we make collections of free responsive Drupal themes for you to use.

Read more
Categories: Drupal

LevelTen Interactive: Hang Out With Some Cool People-- We Are Hiring!

29 August 2016 - 10:00pm

Are you looking for a job in the tech world? Have you ever worked at a company that practiced Agile Methodology? Then this is the job for you! 

Who We Are:

We’re a small web development and marketing agency near Southern Methodist University in Dallas, Texas. We like the occasional ice cream socials and NERF gun battles, but most of all, we enjoy making Drupal websites and helping client's businesses grow. 

The Position:

PT Technical...Read more

Categories: Drupal

DrupalCon News: Join Us for the New DevOps Summit

29 August 2016 - 2:33pm

We added a new summit to the DrupalCon line-up this year: the DevOps Summit, on Monday, 26 September. It's a day filled with keynotes, an industry leaders panel, open discussions, and networking.

DevOps is a popular part of DrupalCon. There are 12 sessions dedicated to DevOps topics like continuous integration and serverless architecture. But we're excited to add more programming for DevOps fans far and wide. With the summit, we've dedicated time and space to offer networking and collaboration activities.

Categories: Drupal

Lullabot: Internal API Design for Distributed Teams

29 August 2016 - 9:00am

My first real project with multiple distributed teams and a timeline measured in weeks (not months!) was the launch of The Tonight Show with Jimmy Fallon. With six weeks to go from nothing to a CMS, a website, and multiple apps, we were forced to figure out the best way to keep all the teams always moving. I wrote then about Legally Binding your Web APIs, but I think it’s time to clarify and update some of it’s points for maximising your team’s productivity.

Introduce the teams

Before features are defined, APIs are designed, and work is started, it’s really important to have some sort of team introduction. This doesn’t need to be a long meeting. What’s important is to get at least one technical person who will need to create or use APIs from each distinct team introduced. At a high level, identify the API providers and consumers from a business perspective. Determine who owns the APIs and their specifications. Make sure each technical person understands the goals of the project. Then, unless you are one of those technical people, get out of the way! Leave the meeting, drop the call, and let those people get to work.

Lay the API Foundation

Every API makes assumptions - about the basic structure of data, about authentication, and about maintenance and updates. Before determining your core objects, figure these things out. Discuss if you’re implementing an RPC API or a REST API. Decide if you’re supporting JSON, XML, or both. For REST APIs, find a suitable specification that supports the Hypermedia Factors you need, like JSON API or HAL, and use it to structure your data and API to simplify client and server implementations. Decide on authentication protocols, like OAuth or HTTP basic. Decide on a versioning strategy such as versioned URLs or custom MIME types. Steal from existing internal implementations where possible. Finally, start writing code.

The problem with beginning implementations now is that there is no source of truth for the API. It’s easy for teams to start making bad assumptions, leading to rework and putting your launch at risk. Instead, use a tool built for managing API documentation like Apiary’s Blueprint or Swagger. Ideally, the tools will let you easily generate API stubs too. Doing so will unblock client implementations, as they won’t be dependent on the production API to start their work. Best yet, when there is disagreement between implementations, the docs become the arbiter of what is right. Sure, documentation can be wrong or miss key details, but it’s much easier to understand a spec than someone else’s code. Best yet, since the first API consumer will be an involved participant in writing the docs, your API will have docs ready to go when that second consumer comes along.

Now, your teams can start writing code, pulling in the core libraries for authentication and data structures.

Design API Objects

Now that you have the basic API details figured out, you can start to design objects (or in REST parlance ‘resources’). At this stage, you are modelling data, and not actions. Assume every object has a GET call, even if it’s not immediately clear that it’s needed. Letting your clients inspect the state of objects will help them to debug your API and their code without relying on expensive calls and meetings that suck up time from getting things done. Design the object schema to be as “obvious” as possible—don’t use ‘image’ in one object attribute and ‘picture’ in another, unless they mean different things. Use REST best practices such as using URLs as canonical identifiers of objects. A critical step many teams miss is determining who manages unique IDs. With the inherent concurrency and assumed unreliability of HTTP requests, identifying which systems manage which IDs is something not to forget.

Again, at this point you should have new documentation and stubs, but no code. Let your documentation continue to be the source of truth.

Design API Operations

Using your work to this point, API operations should start to have intuitive implementations, especially if you are using REST best practices. Map your various CRUD operations to GET / POST / PATCH / PUT / DELETE as required. Find good HTTP status codes to communicate the results of REST calls (my favourite new discovery is 409 Conflict).

One common mistake services teams make at this point is to create a “wide-open POST endpoint” that accepts arbitrary data, and then to reverse-engineer the data into an implementation. Remember, our goal is to keep any sort of dependencies between the teams to a minimum. This sort of development methodology maximizes the dependencies between the teams, and requires implementations that might be totally wrong. It makes what should be an explicit API contract implicit. When the API calls break, there’s no documentation to fall back on, forcing calls and meetings that block all the teams.

Implement All The Things!

All the work so far has been to get to this point of productivity. By now, there should be no hard dependencies between the teams. Stubs can be replaced by implementations as development continues. New APIs can be added quickly by following the existing patterns. API consumers can even make assumptions about how an API would likely be designed before they contact the API team. Questions and iterations can be focused on tickets and documentation comments, helping to preserve the feasibility of the launch date. Stakeholders, project managers, developers, all win.

Header image from The simplest foundation, a padstone

Categories: Drupal

Acquia Developer Center Blog: Waterwheel, the Drupal SDK Ecosystem

29 August 2016 - 8:56am

As Drupal is increasingly widely used as a back end for application ecosystems, developers of wildly diverse backgrounds are now retrieving and manipulating data from Drupal in unprecedented ways. With Drupal 8 and core REST support articulating an API-first vision for the decoupled future, Drupal is eminently well-prepared to back a bevy of applications with divergent approaches. There's just one problem: non-Drupal developers don't know Drupal.

That's where Waterwheel comes in. Waterwheel is an emerging ecosystem of software development kits (SDKs) built by the Drupal community which ease and accelerate development of applications in other technologies. If you will momentarily forgive the flawed metaphor, Waterwheel helps non-PHP and non-Drupal developers "speak" Drupal.

Tags: acquia drupal planet
Categories: Drupal

Drop Guard: undpaul, welcome to update management automation!

29 August 2016 - 4:45am

More and more, midsize companies are excited by Drop Guard, recognising the benefits and values of using this tool.

This time we want to present undpaul to you, a Drupal agency from Hannover, Germany, that is built by an enthusiastic team of Drupal developers. Eleven team members support Anja Schirwinski and Johannes Haseitl, founders and CEOs, in their daily effort to please the needs of their customers best.

In doing so, the whole company let Drop Guard support them and let it provide continuous Drupal and website security for their clients. We asked the undpaul about what changed since they started to use Drop Guard on a daily basis.

 

Drupal Drupal Planet SLA Interview Redmine JIRA Success Story
Categories: Drupal

Cheeky Monkey Media: How To Reduce Your Cost Per Lead in AdWords

29 August 2016 - 2:43am
How To Reduce Your Cost Per Lead in AdWords steph Mon, 08/29/2016 - 09:43

Running a campaign in AdWords can be a fantastic way to get more leads for businesses that rely on lead generation. It can also be an expensive money pit, if you’re not doing it right.

We’re going to share with you some fairly straightforward ways of reducing your cost per lead. Our PPC team recently reduced a client’s cost per lead by 178% while increasing the number of leads by 186%. Here is how we did it.

 

Add Keyword Negatives

Some people advise against using broad match terms altogether. They can be expensive and a big waste of clicks if done incorrectly. When done correctly, however, they can provide you with targeted keywords you might not have thought about (such as competitor terminology or industry slang).

Broad match terms can also provide you with an exceptional list of keyword insights that you can later use to organically optimize your site. This data is gold, so it's why I personally love using broad match terms (where appropriate) with lots of negatives.

Here’s how to find negative keywords to add:

Categories: Drupal

Jim Birch: Making a Bootstrap Carousel with Drupal Paragraphs and a Single Twig Template

29 August 2016 - 2:20am

Last week I wrote how to make a multi-column section with Drupal Paragraphs and Bootstrap.  This post describes how to take a similar approach to create a Carousel.  Creating this using Paragraphs allows your content administrators an easy way to add a Slideshow/Carousel to their pages.

I am going to assume that you are including Bootstrap CSS and JS in your theme, and that you have the Paragraphs module installed and have a few Paragraphs already set up.  Go to Structure > Paragraph types to click the Add paragraphs type button.  Add a Paragraph bundle called Slideshow (Also could be called Carousel, Gallery, or Slider depending on you or your company's nomenclature).

Add a field called Slides.  We will use this to add items to the the carousel.  I like to use a reference field to other paragraphs, so we can select Image Paragraphs, Simple Paragraphs, Video Paragraphs, even the Multicolumn paragraph I wrote about last week where it can have additional Paragraphs.  Yes, that would be a Paragraph in a Paragraph in a Paragraph!  All is fair in love and Entity References.

On the Add field screen, in the Add a new field dropdown, select Paragraph under Reference revisions.

Read more

Categories: Drupal

Drupal core announcements: Drupal 8.2.0-rc1 on the week of September 7 and what it means for 8.1.x

29 August 2016 - 12:45am
Start:  2016-09-06 12:00 - 2016-09-09 23:55 UTC Event type:  Online meeting (eg. IRC meeting)

Drupal has adopted semantic versioning and a scheduled release cycle starting with Drupal 8.0.0. This means that it is possible within a major Drupal version to add new functionality in a backwards-compatible way, and there is no need to wait for Drupal 9 for improvements.

The second such version, Drupal 8.2.0, is going to be released on October 5th 2016, including the following new experimental modules: Content Moderation (to manage content review workflows), Outside-In (for editing configuration without leaving your frontend), Place Block (to add blocks directly to the page), and DateTime Range (to store end dates on date fields).

To prepare for Drupal 8.2.0, we released three beta versions in August. Announcements for beta1, beta2, and beta3 detail the significant changes made for Drupal 8.2.x. Now, we are getting ready to create Drupal 8.2.0-rc1, the first release candidate, the week of September 7, 2016.

This means several things in terms of support for Drupal 8.1.x versions and allowed patches in Drupal 8.2.x:

  • Starting with the RC, the 8.2.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.
  • To ensure a stable and timely release candidate, a commit freeze for the 8.2.x branch will begin Tuesday, September 6 at 1200 UTC.
  • The week of September 7 is also the final scheduled patch release window for 8.1.x, and it will not receive further development or support after that date aside from its final security release window on September 21 (which will not include bug fixes). Site owners and module or theme authors should prepare to update to 8.2.x.
  • As a consequence, all outstanding issues filed against 8.1.x will be automatically migrated to 8.2.x after the final 8.1.x patch release. Future bug reports should be targeted against the 8.2.x branch.
  • 8.3.x will remain open for new development during the 8.2.x release candidate phase.

See the Drupal core release cycle overview, Allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Minor versions like Drupal 8.2.0 may include changes to user interfaces, translatable strings, themes, internal APIs like render arrays and controllers, etc. (See the Drupal 8 backwards compatibility and internal API policy for details.) Developers and site owners should test the release candidate to prepare for these changes.

Categories: Drupal

hussainweb.me: Drupal Meetup Bangalore – August 2016

28 August 2016 - 11:22pm
This month's Drupal meetup was held at Srijan Technologies office in Bangalore on August 27, 2016. This was the first time we had a Drupal meetup in Kalyannagar, or even so far north in Bangalore and as such, we had a lot of new faces. There were around 20 attendees out of 32 RSVP's which is just about the attendance ratio in meetups in Bangalore.
Categories: Drupal

d7One: Is Ubercart still relevant now that Drupal 6 has reached EOL?

28 August 2016 - 2:11pm

In this day and age where Drupal 8 is all the rage and while contemplating an end-of-life Drupal 6 Ubercart Store upgrade to Drupal 7 or 8, I wondered if Ubercart was still a relevant alternative? Because if it was, then Ubercart 6.x store owners wishing to upgrade would not have just one but two options to choose from, two chances to find the right fit.

My initial thought was, let's go with the flow and migrate to Drupal Commerce. The main reason behind my sheepish logic: Commerce is the de facto go-to e-commerce platform.

Then, another side of me argued that Commerce's dominance is somewhat artificial and really stems from the fact that commerce-talk dominates the techno buzz channels, grabbing most of the spotlight and in so doing is casting other potential solutions in the gloomy shadows of quasi-oblivion...

In this article, I will share my experience about a recent project for a small town hockey association which, for the past 5 years, has been relying on a Drupal 6 Ubercart 2.x website to automate seasonal registrations for its 350 hockey players. With Drupal 6 now defunct (EOL) and no security team* to provide the required assurance that credit card transactions would be safe, there was little choice but to upgrade at least to Drupal 7 before registration could start.

Categories: Drupal

Pages