Atlassian Summit 2017

Atlassian Summit 2017

by | Aug 25, 2017 | Ascend Blog, Project Atlassian

The Atlassian Summit in San Jose is fast approaching! Between the excitement of the keynotes, partner day, bash, and the exhibit floor partners and decision makers, the week will be filled with opportunities for networking and education on agile and the Atlassian tool suite.

As an Atlassian Silver Solutions Partner, we’d like to take a moment to share some thoughts on what we’d like to see this year at Summit:

  • New JIRA Capabilities: JIRA has expanded greatly in functionality since 2015 and its continued growth is a testament to a strong following and user base. We’d like to learn what Atlassian is planning for JIRA 7.5 and beyond!
  • Confluence Integrations: Confluence has had limited integrations with other Atlassian tools in the past. What can we expect going forward?
  • Bamboo’s Next Steps: Where are we going with Continuous Build and Integration? What will happen with Bamboo, and will Bitbucket’s build capabilities be expanded to incorporate more CI capabilities?
  • Trello: What will the future of Trello look like, now that Atlassian has purchased the firm? How will it be incorporated into the Atlassian tool suite?
  • Future Integration Capabilities: In 2015 we got Atlassian Connect, but what does the future of the Plugin SDK look like?
  • Atlassian Cloud capabilities: Will we be able to integrate LDAP to the Cloud? And what about the ability to create our own URLs?

If you have any questions in the meantime regarding the Atlassian tool suite, visit our site and learn more about the tools and our capabilities: https://ascend.zellecloud.com/what-we-do/atlassian/.

Details on the summit and the event schedule can be found here on the Atlassian homepage.

Three of our consultants are attending this year, so look for us at the Summit!

Find us on the Atlassian Partner Portal
Integrating JIRA and SSO Using CAS

Integrating JIRA and SSO Using CAS

by | Aug 1, 2017 | Ascend Blog, Project Atlassian

By default, Atlassian JIRA has an internal directory, integrates with LDAP / Active Directory, and integrates with a Single Sign On (SSO) solution: Crowd. However, a growing number of administrators are looking to integrate their Atlassian solutions across their enterprise Central Authentication Service (CAS). We decided to write this blog based on the original work put together by the JASIG team: CAS Configuration. The original code repository can be found here if you’d like to build the JAR files yourself: https://github.com/apereo/java-cas-client. A more detailed account along with code snippets can be found on our blog here: https://ascend.zellecloud.com/ascend-blog.

While the JASIG team created an excellent entry, we wanted to build on its success by adding easy-to-find download links, updated XML entries, and some additional details or directories / locations. This entry includes details on integrating with JIRA 7.x running on a Linux-based server.

The five steps we are covering here include:

  1. Shutdown JIRA + Know your File Locations
  2. Copy the JAR Files
  3. Modify web.xml
  4. Modify seraph-config.xml
  5. Start JIRA

While this is meant to be an overview and will help in getting your JIRA to communicate with your CAS system, it is not meant to be a full setup of CAS, or a full JIRA configuration / set up as well. This article is for semi-advanced users and administrators. But, with that said if you have any questions as you go through it, please feel free to reach out to us: info@ascend.zellecloud.com.

Step 1: Shutdown JIRA + Know your File Locations

First, make sure JIRA is shut down.

All files discussed here will exist in the following locations (note, JIRA_INSTALL by default is set to the /opt/atlassian/jira/atlassian-jira/ directory). The list of the files to be modified / copied are below as well as their locations:

  • seraph-config.xml: JIRA_INSTALL/WEB-INF/classes
  • web.xml: JIRA_INSTALL/WEB-INF/
  • CAS Client for Java Core: JIRA_INSTALL/WEB-INF/lib (needs to be copied here)
  • CAS Client for Java Atlassian Integration (for JIRA 7): JIRA_INSTALL/WEB-INF/lib

NOTE:
You can download the updated CAS clients (v3.3) that will be used along with the Jira7 JAR files from our Bitbucket repository here (download both files): https://bitbucket.org/mbrown_ascend/jira-cas-integration/downloads/

Step 2: Copy the JAR Files

After you have downloaded the files above (CAS Client for Java Core v3.3.3 + CAS Client for Java Atlassian Integration v3.5), copy both of these JAR files both into the JIRA_INSTALL/WEB-INF/lib/ file directory.

Step 3: Modify web.xml

Open up web.xml in your favorite text editor. We used VIM for most of these modifications. Around line 374, just above the “THIS MUST BE THE LAST FILTER IN THE DEFINED CHAIN” comment, add the following code (Wherever it says to add your specific information):

<!-- CAS:START - Java Client Filters -->
 
<filter>
   <filter-name>CasSingleSignOutFilter</filter-name>
   <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>
<filter>
  <filter-name>CasAuthenticationFilter</filter-name>
  <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
  <init-param>
    <param-name>casServerLoginUrl</param-name>
    <param-value> Include your CAS login here </param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value> include your JIRA url here </param-value>
  </init-param>
</filter>
<filter>
    <filter-name>CasValidationFilter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
        <param-name>casServerUrlPrefix</param-name>
        <param-value>Include your CAS login here</param-value>
    </init-param>
    <init-param>
        <param-name>serverName</param-name>
    <param-value>include your JIRA url here</param-value>
    </init-param>
    <init-param>
        <param-name>redirectAfterValidation</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
 
<!--- CAS:END -->
Next, around line 627, there will be a filter mapping for your login, something like this:
    <filter-mapping>
        <filter-name>login</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher> <!-- we want security/login to be applied after urlrewrites, for example -->
    </filter-mapping>
Above the filter mapping code listed above, copy and paste the following:
<!-- CAS:START - Java Client Filter Mappings -->
 
<filter-mapping>
   <filter-name>CasSingleSignOutFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>CasAuthenticationFilter</filter-name>
    <url-pattern>/default.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>CasValidationFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
 
<!-- CAS:END -->
You can just copy / paste this code directly. After you have finished, save the web.xml file (in the VIM editor type ESC and then “:wq”).

Step 4: Modify seraph-config.xml

Next, you must make the following modifications to the seraph-config.xml file. In your seraph-config.xml file, there should be series of parameters. This is where you will make the modifications. Look at the code below, once again any area below that states “add your CAS URL…” is what you will need to modify.

<init-param>
    <!--
      The login URL to redirect to when the user tries to access a protected resource (rather than clicking on
      an explicit login link). Most of the time, this will be the same value as 'link.login.url'.
    - if the URL is absolute (contains '://'), then redirect that URL (for SSO applications)
    - else the context path will be prepended to this URL
 
    If '${originalurl}' is present in the URL, it will be replaced with the URL that the user requested.
    This gives SSO login pages the chance to redirect to the original page
    -->
    <param-name>login.url</param-name>
    <!--<param-value>/login.jsp?os_destination=${originalurl}</param-value>-->
    <param-value>add your CAS URL here</param-value>
</init-param>
<init-param>
    <!--
      the URL to redirect to when the user explicitly clicks on a login link (rather than being redirected after
      trying to access a protected resource). Most of the time, this will be the same value as 'login.url'.
    - same properties as login.url above
    -->
    <param-name>link.login.url</param-name>
    <!--<param-value>/login.jsp?os_destination=${originalurl}</param-value>-->
    <!--<param-value>/secure/Dashboard.jspa?os_destination=${originalurl}</param-value>-->
    <param-value>add your CAS URL here</param-value>
</init-param>
<init-param>
    <!-- URL for logging out.
    - If relative, Seraph just redirects to this URL, which is responsible for calling Authenticator.logout().
    - If absolute (eg. SSO applications), Seraph calls Authenticator.logout() and redirects to the URL
    -->
    <param-name>logout.url</param-name>
    <!--<param-value>/secure/Logout!default.jspa</param-value>-->
    <param-value>add your CAS LOGOUT URL here</param-value>
</init-param>
After you have finished with this modification, scroll down to around line 93, and comment out SSOSeraphAuthenticator and JIRASeraphAuthenticator lines:
<!-- CROWD:START - If enabling Crowd SSO integration uncomment the following SSOSeraphAuthenticator and comment out the JiraSeraphAuthenticator below -->
    <!--
    <authenticator class="com.atlassian.jira.security.login.SSOSeraphAuthenticator"/>
    -->
<!-- CROWD:END -->
 
    <!-- CROWD:START - The authenticator below here will need to be commented out for Crowd SSO integration -->
    <!-- <authenticator class="com.atlassian.jira.security.login.JiraSeraphAuthenticator"/> -->
    <!-- CROWD:END -->
Add the following to this section instead:
<authenticator class="org.jasig.cas.client.integration.atlassian.Jira7CasAuthenticator">
        <init-param>
            <param-name>casServerUrlPrefix</param-name>
            <param-value>include your cas server here</param-value>
        </init-param>
        <init-param>
            <param-name>serverName</param-name>
            <param-value>include your JIRA server URL</param-value>
        </init-param>
</authenticator>
From there, save and close the file.

Step 5: Start JIRA

After you start JIRA instance, go to a browser and type in your JIRA URL. You will be re-directed to your CAS Client.

If you are having issues with your configuration, please reach out to us anytime! We have completed CAS configurations in multiple environments using different versions of CAS. If you have any questions about this blog or about integrating your Atlassian Tool with multiple SSOs, send us an email at info@ascend.zellecloud.com.

Structuring Agile Kanban Boards with JIRA’s “Kanplan”

Structuring Agile Kanban Boards with JIRA’s “Kanplan”

by | Jul 13, 2017 | Ascend Blog

JIRA Software 7.4 Server was just released to the world! The release contained a lot of new features and fixes (detailed here: Release Notes). Being Agile specialists and Atlassian Solutions Partners, we at Ascend Integrated are excited at this release, one which we’ve been reading about since the EAP in April 2017 because it featured “Kanplan”, the ability to create a backlog in a Kanban board.

Why is this cool? Well, Kanban is a very flexible, agile foundation enabling teams working mostly in continuous delivery / support / maintenance to assign, implement, and complete / release features, functionality, and bug fixes. The Kanban backlog goes a step further, providing Kanban teams using JIRA Software increased abilities to plan and manage upcoming stories, tasks, and bug fixes.

To enable your Kanban Backlog, you will need to be a Board Administrator. Go to Board > Configure, and select “Columns” on the left-hand side. Here, you can drag a status into the Kanban Backlog, which will enable the backlog for your board! In the image below, I dragged the Backlog status into the Kanban Backlog column.

Figure 1: Enabling the Kanban Backlog

Now, when you return to your Kanban board, you will see the Backlog icon on the left-hand side (like the SCRUM board view). Clicking the Backlog icon will take you to the Kanban Backlog board, where you can perform functionality once only capable in the SCRUM boards:

  • Adding Issues to the Backlog
  • Prioritizing Backlog Issues
  • Viewing / Editing Issues (using the Issue Details view)
  • Creating Sub-tasks
  • Issue Transitions
  • Select Issues for your team to work on
  • …And more!

Figure 2: Kanban Backlog View

A very useful and innovative method for structuring your Kanban related projects, the Kanban Backlog is available now in JIRA Cloud and JIRA Software 7.4!

Any questions regarding the Kanban Backlog, or upgrading to JIRA 7.4? Reach out to us anytime!

Your Help Desk Needs: Zendesk vs. Atlassian JIRA Service Desk

Your Help Desk Needs: Zendesk vs. Atlassian JIRA Service Desk

by | Mar 16, 2017 | Ascend Blog, Project Atlassian

No one can downplay the importance of utilizing an efficient and effective IT Service Management (ITSM) software at work in your organization or enterprise. A business must be able to respond both externally to customers’ requirements, and internally to stakeholders with inquiries or support needs in an acceptable amount of time and maintain consistent communication throughout the process. Two applications dominating the ITSM market with their innovative approaches to service management are Atlassian’s JIRA Service Desk and the Zendesk platform. To be effective, ITSMs often need to provide reporting capabilities, SLA’s, automation, and need to be easily extendable / adaptable across multiple teams. Here we’ll examine the pros and cons of both applications, along with our recommendations based on our use of both applications across different environments.

Note: comparisons between Zendesk and Service Desk were made using the Zendesk Cloud platform, and the JIRA Service Desk Cloud / v 3.3.1 (server) implementations. 

Zendesk

Founded in 2007, Zendesk is a system for tracking, prioritizing, and solving customer support tickets (thank you Wikipedia). Zendesk is a completely cloud based ITSM. After I went to their application site, https://www.zendesk.com/ and clicked “Get Started”, I was up and running in a matter of 5 minutes. Pretty cool! I began customizing my Zendesk instance right away, and was happily greeted with a straightforward user interface (see Figure 1 below). Just adding a new field was a simple task. Much of the administration was intuitive, no training required!

Figure 1: Adding a New Field

After setting up the system itself, users entering tickets would see a screen similar to this one:

Figure 2: Entering a Ticket into Zendesk

Here are some of my thoughts based on my experience working with Zendesk in the past and just recently.

Starting Price:

$5.00 per agent per month (agent denotes someone who is a user and administrator of the ITSM, not a customer)

Pros:

  • Straightforward User Interface and Administration built into the Zendesk application. Take a look at Figure 1 above to see just how easy it is to add a field to a ticket.
  • Triggers, Automations, and SLA’s are now a core feature built into the Zendesk application.
  • Social Media Integration (yes you can link to Facebook, Twitter, etc.).
  • Reporting and Views functionality allows users to create views using specific conditions selected from multi-select boxes. Users can drag+drop columns to better organize their reports.
  • Rich App Marketplace for add-ons and extending the functionality of your Zendesk instance. Some of these add-ons are free and easily installed on your instance with a few clicks.

Cons:

  • As its hosted in the cloud, the URL will appear as “yourcompanyname.zendesk.com” rather than having it on a dedicated URL.
  • Price of $5 per month per agent can be costly to a small business depending on the number of agent accounts you would like to create.
  • Limited overall customization capabilities: while Zendesk is simple to get up and running, and it is certainly extendable, there is much less functionality out-of-the-box with Zendesk when compared with JIRA Service Desk.
  • Zendesk is not specifically ITIL compliant. While it is possible to install plugins in order to bring the system close to ITIL compliance, it is not ITIL certified out of the box.

JIRA Service Desk

Built on the power and flexibility of JIRA Core, JIRA Service Desk is a standalone ITSM software developed by Atlassian for use as an IT Help Desk ticketing system. After navigating to the Atlassian website and clicking “Try it Free”, I’m brought here where I can create my own Service Desk instance in the Cloud: https://www.atlassian.com/software/jira/service-desk/try and I’m off and running. Service Desk can also be downloaded locally to your own server.

After I create my instance, I can create a Service Desk Project based on previously defined templates, or I can create a custom project, including workflows, fields, request / issue types, permissions, notifications, etc. Figure 3 shows the types of customizations, for instance you can perform creating custom fields.

Figure 3: Customizing Fields for JIRA Service Desk

Figure 4 provides an overview of how the ticket / request type forms will look like if you choose a standard out-of-the box template.

Figure 4: Entering A Ticket Through JIRA Service Desk 

Starting Price:

$10.00 for 1 – 3 agents in the cloud / server instances.

Pros:

  • To start, JIRA Service Desk is ITIL Compliant and Certified. This is a make or break decision for some organizations looking to implement an ITSM that complies with ITIL.
  • Excellent price points initially (1 – 3 agents are only $10.00 / month), though it can become expensive if you begin scaling (i.e. a service desk with 6 agents would run you $3,000.00 per year, compared with $30.00 per month using Zendesk).
  • The administration section of JIRA Service Desk is extremely customizable, you can customize anything from field types, to request types, automation & SLA’s, and create custom dashboards using built-in gadgets.
  • Comprehensive reporting using JIRA Query Language (JQL), allow you to create advanced reports easily.
  • Atlassian Marketplace is filled with Add-Ons (some free) that further extend the functionality of Service Desk.

Cons:

  • Too many customization options require the Service Desk administrators to be specialists. Nuances abound when administering a Service Desk instance.
  • For clients using the server-based version of Service Desk, they will need to have a separate server / hosted environment which may add to the costs.
  • If you are using the Atlassian Cloud instance, you will be stuck with a URL such as “yourcompanyname.atlassian.net”, very similar to Zendesk.
  • There are inconsistent functionalities across the Cloud and Server versions of Service Desk. New functionality is often introduced in the Cloud before it is found on the Server version.

Conclusion

Zendesk and JIRA Service Desk are both powerful ITSM’s in the marketplace. They provide a full range of functionality for users of all types of organizations. Interestingly enough, these systems have long since decided to interoperate with one another. Users may install add-ons for JIRA that allow JIRA data points to be displayed in a Zendesk instance (and vice versa).

Our recommendation: JIRA Service Desk is best suited for organizations who require more complex reporting out-of-the-box, additional functionality / control, and who may need their Service Desk instance hosted behind a firewall. Zendesk is preferential for smaller organizations (not to say it can be used for larger organizations as well) who do not require the complex administration / management / reporting, but want a dependable system running in the cloud.

What are your thoughts, have you used Service Desk or Zendesk?

The Right Agile Tool For Your Team

The Right Agile Tool For Your Team

by | Mar 3, 2017 | Ascend Blog, Project Atlassian

Software development and the processes that guide it have been evolving over the past twenty years. The Waterfall methodology, thought by many to now be obsolete, paved the way for both iterative and agile based software development methodologies. Agile itself is not confined to a single method, but is often fluid and changes between process frameworks (i.e. SCRUM vs. Kanban) and the organizations that use agile (Non-Profits, Government Agencies, and Commercial firms). Due to Agile’s propagation among software projects, and the need for teams to stay organized, tools have been developed in order to help software developers, scrum masters, product owners (and the list goes on) stay organized. Here we’ll be examining four agile tools used for planning and organizing teams: JIRA, Trello, Targetprocess and Bugzilla. Specifically, with these tools, we will be examining their pros, cons, and the types of organizations for which they are most suited.

JIRA / JIRA Agile

JIRA is a versatile issue tracking system built and designed for software teams to track project related tasks / issues. Atlassian utilizes Kanban and SCRUM based boards that are highly customizable. As JIRA Experts and Partners, we are not only (slightly) obligated, but also thrilled to write about JIRA and JIRA Agile’s capabilities. JIRA also enables users to create complex reports and filters using Jira Query Language (JQL) which functions similar to SQL. You can find out more, and try JIRA for free here: https://www.atlassian.com/

Figure 1: JIRA Agile Board

Starting Price:

10 users for $10 /month (Cloud and Server). Data center options are available.

Pros:

  • Highly Customizable: you can create custom fields, boards, reports, etc.
  • Built for Cloud + Server: you can install and manage JIRA-Agile in your data center or access it through the cloud.
  • One of the most widely used Agile tools on the marketplace.

Cons:

  • Price: after you get past the 10 users, the price quickly jumps for 15 users to $75 per month. 2,000 users may run you $1,500.00 in the cloud per month. 10,000 users in JIRA Server will run you close to $36,000.00 per month.
  • Add-ons may be pricey, and are sometimes required to extend the base functionality of JIRA.
  • There is a steep learning curve for administration, installation, and customization.

JIRA is a great overall tool for both small and large teams. However, in our experience we’ve found JIRA may offer too much customization for a small team to get a tool “up and running”. But, for many organizations, JIRA is the first tool we show them when helping them select an agile tool. We would recommend JIRA for small but established teams as well as medium sized and large teams / organizations.

Trello

Trello is an agile, cloud-based tool recently acquired by Atlassian. It currently does not have a standalone installation. The boards allow users to define their own lanes or columns (called “lists) where you can drag and drop cards. Cards on the board also allow you to attach images and files, write descriptions and you can assign cards to Trello users (or add them) who have access to your board. Trello Boards can be public or private. You can try Trello for free here: https://trello.com/.

Figure 2: Trello Agile Board

Starting Price:

$0, Trello Gold will run you $5 per month, or $45 per year.

Pros:

  • (In our opinion) The most fluid / easily understandable UI of all the tools we reviewed.
  • No costs upfront: you can create a Trello board with limited costs to you and your team. This is excellent for small teams or startups.
  • Ability to add potentially unlimited number of users to your board.

Cons:

  • Lack of customization (custom fields, screens, and issues / tickets).
  • Limited reporting capabilities (no fancy advanced reporting or dashboards here).
  • No way to link code to cards that are being developed unless you use the advanced APIs.

Trello is excellent for small and medium sized agile development teams, but may not hold up well against larger teams due to its lack of overall customization capabilities. We would recommend this mostly for small teams and startups.

Targetprocess

Targetprocess is an Agile tool allowing users to build out detailed projects and project schedules. Very similar to JIRA, it allows users to customize boards, user permissions, notifications, and issue types (called entities). It has a standalone installation that is normally used for large organizations or projects, and a cloud-based application. You can find additional information regarding Targetprocess, and try it out here: https://www.targetprocess.com/.

Figure 3: Targetprocess Agile Board

Starting Price:

Its free, you can begin using Targetprocess at $0.00.

Pros:

  • Starting price of $0.00 is a huge motivator for small teams looking to begin development.
  • Free courses on basic and advanced system features. You do not have to pay for training.
  • Highly customizable tool with excellent customer service.

Cons:

Targetprocess can be used for both small and large project teams. It has a nice blend of rigid controls and permissions that compare with those provided by the Atlassian tool suite. However, the UI seems to be a bit outdated, but its rigidness may apply best to large programs and projects where users may only be allowed to execute limited functionality.

Bugzilla

Actively maintained by the Mozilla foundation, Bugzilla is a true open-source bug tracking tool. There is no cloud instance, which means you are required to download and install it on your server or in a hosted instance (i.e. AWS). Of all the bug tracking / agile tools we’ve touched on here, it is the oldest (being released in 1998) and to this day is still actively maintained. You can download and install Bugzilla here: http://www.bugzilla.org. Bugzilla does not come out-of-the-box with an Agile based board installed, you will need to install one: http://www.scrumexpert.com/tools/scrum-kanban-open-source-tools-for-bugzilla/

Figure 4: Bugzilla using the KanbanBoard Plugin

Starting Price:

$0.00 (its open source!)

Pros:

  • Absolutely Free, you will never pay for the actual Bugzilla application.
  • Highly customizable: you have full documentation on the code from the Mozilla group that you can review and build atop the success of Bugzilla.
  • Heavily documented tool and actively maintained.
  • Majority of add-ons for Bugzilla are free, you can extend the functionality of Bugzilla for little to no cost.

Cons:

  • There is no customer support for this tool. Should you have an issue or question, you can consult the Mozilla documentation, Stack Overflow, and other support forums.
  • No cloud hosted option for small teams, you are required to use a standalone server (or purchase a hosting platform).
  • Outdated, clunky UI for many of the Agile based add-ons.

Bugzilla is great for project teams of all sizes who may have some extra server power lying around. And maybe for that reason, it would be geared towards established smaller teams who want to have the customization and configuration capabilities of JIRA / Targetprocess and want to host it on their own server / instance.

What Should You Choose?

While each tool has their strengths and weaknesses, they all appeal to a specific team / project / organization and the way in which they will use the tool.

Let us know if there’s a tool you would like us to review. You can contact us through our site, or comment on this blog entry!

Which tool is right for your organization?

Co-Authored By: Mike Brown & Ben Dickshinski — Ascend Integrated

Drupal 8 Review: Part-3 (Should I upgrade to Drupal 8?)

Drupal 8 Review: Part-3 (Should I upgrade to Drupal 8?)

by | Sep 28, 2016 | Ascend Blog, Project Drupal

In the final installment of this 3-part blog discussing Drupal 8, we review what makes Drupal 8 great, areas where it can improve, and some items to seriously consider when deciding to upgrade to Drupal 8 from Drupal 7. Throughout this entry, we will take a look at a consolidation of our previous notes / blog entries, and provide additional information regarding Drupal 8.

Disclaimer: Since Drupal 8 has gone live, the community is no longer supporting Drupal 6. We highly recommend upgrading to either Drupal 7 or 8 as soon as possible. This represents a minority of the Drupal users, so this blog will be mostly focused on upgrading from Drupal 7 to 8.

What’s Great

If you decide to upgrade to Drupal 8, you’ll instantly see many of the benefits at your finger tips. Drupal 8 is great for Content Managers, Mobility & Responsive Design, and for those firms who want to be on the bleeding edge of CMS Development. Let’s explain:

Many of the features and functionality built into Drupal 8 was built mostly around the content manager, and a bit less around the developer. This was evidenced by Drupal 8’s transition to Object Oriented Programming (OOP) (D8 code looks different from D7’s functions and arrays) and purposefully embedding the CKEditor into the Core. As a content manager or administrator, I can start administrating my site quickly and easily. The backend UI is very different and allows for easy navigation. Building a basic content only site with minimal functionality is a breeze with Drupal 8.

Drupal 8 has responsive and mobile design built into the core. Even Bartik, the default Drupal theme contains elements of responsive design. The administration menu and screens also exhibit responsiveness. You can now manage your Drupal 8 site on your tablet or smartphone. In comparison, there are still a number of Drupal 7 themes that are not 100% responsive themes. Search engines, specifically Google, penalize sites’ SEO rating harshly if there is limited to no responsive design. Therefore, Drupal 8’s out-of-the-box capabilities for responsive design help guarantee your site appears at the top of search engine results.

Drupal 8 is the most advanced version of Drupal to date. While this comes with less module support, it enables developers to be creative and determining their own custom solutions. Drupal 8 still requires a lot of work, but developers can definitely take advantage not only for the possibilities twig offers for theming, but also the back-end OOP support. Drupal 8 is also optimized for PHP 7, decreasing overall performance issues associated with PHP 5.x and improving the stability of the CMS greatly. Drupal 7 still does not support PHP 7 completely, as evidenced by the current thread on the Drupal site: https://www.drupal.org/node/2656548.

What Could Be Improved

Drupal 8 is a living software development project, constantly being updated and maintained. While Drupal 8 brings many benefits to both users / administrators and developers, it lacks functionality with limited module support, lack of themes, and creates some administration and development difficulty through a general lack of Drupal 8 documentation.

As touched on previously in our second blog, we noticed many of the modules for Drupal 8 were still in the process of being developed, i.e. were still only of “Alpha” or “Beta” status. Support for many of the Drupal 7 modules continues, but Drupal 8 still does not have the full support of contributors developing modules. This is partially due to the user base (there are still many more Drupal 7 sites than Drupal 8 sites), and the relatively recent release of Drupal 8.

As of September 2016, there are 12,296 modules built for Drupal 7, with only 2,103 modules built for Drupal 8. Regarding themes, Drupal 7 has 702 themes and theme options available, where as only 124 are available for Drupal 8. Similar to the modules, many of the themes developed for Drupal 8 are in their Alpha or Beta stage, and not yet ready for full-production use. The sites we’ve seen developed by the larger firms using Drupal 8 utilize customizable themes like Bootstrap or are built from the ground-up using twig. Smaller companies and development shops may not have the capacity to support custom front-end development for Drupal.

The documentation across the site is lacking information regarding Drupal 8. We believe this to be caused by the recent Drupal.org site migration and also the relative newness of Drupal 8. While the Acquia library currently has a wealth of information, the open source Drupal.org site does not have a consistent, updated Drupal 8 documentation library.

Since the time of this writing, the Drupal community continues to improve module compatibility with Drupal 8. However, we are still years away from full Drupal 8 adoption. The Drupal community is excellent, and I’m sure the flaws we’ve addressed here are being alleviated and solved by the community already.

If you decide you absolutely need Drupal 8…

We are skipping ahead here, but we wanted to highlight some unique functionality Drupal 8 implemented in the Drupal 8 core. Drupal has made life for Drupal 7 (and 6) users a bit easy if they decide to upgrade to 8. Included within Drupal 8 is the “Migrate” module. As of v8.1.x these are included in the “Experimental” section of the Core modules (see the figure below). While experimental, the community understands many user’s frustrations migrating / updating their sites, and decided to make it easier. However, as of Drupal 8.2, the migration path is still not complete especially for Multi-lingual sites. Migrate at your own risk!

Figure 1: Drupal Migrate Modules

Installing the Migrate, Migrate Drupal, and Migrate Drupal UI will activate the Drupal Upgrade process, whereby you can import an existing Drupal site into a clean install of Drupal 8. It will overwrite anything you have configured currently in Drupal 8. The system will ask you for your database source, source file information, and you are off to the races.

Figure 2: Drupal Upgrade Process Beginning

Should you Upgrade?

As we hinted at earlier, Drupal 8 is excellent if your site is heavily content and theme focused, and less focused on functionality (i.e. ecommerce), then Drupal 8 is probably a great place to start. In fact, I would say skip using Drupal 7 altogether and go right to 8 for content heavy sites. You’ll be happy you did! You’ll be able to stay on top of new themes, updates, and use modules as they go-live. For a smaller firm, personal site, or mid-sized firm with content heavy sites, Drupal 8 is highly recommended. Multi-lingual sites also greatly benefit from the built-in Drupal 8 compatibility with multiple languages. Try it out!

For those sites that require a great deal of security, ecommerce, or have a large user base (i.e. such as those for a portal or collaboration site), we recommend staying with Drupal 7 a bit longer. Many of the modules for Drupal 8 that enable permissions and usability are not yet compatible with Drupal 8. While you can mimic a lot of functionality in modules not yet updated to Drupal 8 by writing your own custom code, its not likely recommended due to time and costs associated with development. Many themes for Drupal 7 are also mobile responsive, so jumping to 8 just to have the “responsive” functionality is not nearly as effective as finding a great responsive Drupal 7 theme.

It is likely Drupal 7 will continue to be supported for several years to come. Depending on your organization’s size, appetite for change, and the functionality your site provides, upgrading to Drupal 8 may be a blessing. Upgrading may also cause more headaches through increased costs and development time attempting to patch together custom modules and functionality not supported by Drupal 8.

I hope you enjoyed our series on the Drupal 8 CMS! Feel free to reach out to us at anytime: www.ascendintegrated.com