Feeds

Author

Mar 07 2019
Mar 07

In our last meetup here on Long Island, we reviewed Preston So's recent book "Decoupled Drupal in Practice". We had the opportunity to record the meetup, figured it can't hurt to post it here!

We also demonstrate how setup a super simple REST server and connect it to a React component. 

In our last meetup here on Long Island, we reviewed Preston So's recent book "Decoupled Drupal in Practice". We had the opportunity to record the meetup, figured it can't hurt to post it here!

We also demonstrate how setup a super simple REST server and connect it to a React component. 

[embedded content]

Mar 20 2018
Mar 20

MidCamp Group

Wow its been a while for us here on the Sego blog. Man, we have been busy and having a bunch of fun building value for our partners and clients... we just really need to write about it more. 

We just got back from Chicago. We were honored to be invited to deliver the module development training at the camp. We had a blast doing it and wanted to publically give a special thank you to all the organizers and folks that came out for the training and the camp overall. Chicago is an awesome town and we hope to be back to connect with the community out there. 

All the sessions are available here, thanks to the awesome @kevinjthull

Oct 10 2016
Oct 10

Software is an ever changing interweaving of collections of ideas expressed in code to solve various problems. In today's day an age the problems that software is solving is expanding at an ever increasing rate. The term “software is eating the world” is more and more relevant every day.

Although software is being deployed in every area of our daily lives the process which teams develop software is extremely inconsistent. Most of this may be a function of the maturing processes in a relatively new field. We are starting to see patterns emerge in the area of “devops” and better managed development workflows. At the core of a lot of these topics is how we test our software.

As developers we are extremely interested in building, learning, and automating. A smaller (but growing) collection of us gets excited about testing. Personally I have struggled for years in various environments to pin down a good testing strategy. That is still a learning curve I am on… and most likely will never be off of. It is what is inspiring me to write this post.

 

So what is software testing?

If you ask an end user, and many developers, what they think software testing is they would most likely say “Well, click (or tap) around the application and see what breaks”.  This isn’t necessarily incorrect. This is simply one level of a deeper topic. Therefore in order to define what software testing is we need to first define what levels of software testing exists. So let's break this down from the bottom level (the single lines of code) to the top level (the system as a whole):

  1. Unit testing

  2. Integration testing (sometimes referred to as functional tests)

  3. System testing

  4. Acceptance testing

Each of these levels builds upon the previous to provide for a consistent and comprehensive testing environment for a given project.

How much testing do we need?

Does your organization or project require a comprehensive suite of tests in each level? This depends on many factors. Purists will most likely say YES but the realist in me wants to say most likely not.

Organizations and the software developers you choose to work with should have honest conversations around the requirements of a feature, what should be tested, and how we will be testing. From these conversations we can map a out a testing plan that will serve as a communication tool for both project stakeholders and developers. Ideally the testing plan would integrate into an overall CI / CD system to provide an organic view of the projects state. For smaller projects a simple Google doc will suffice.

 

So how do we actually test?

Armed with functional requirements and a solid understanding of what is important to be tested within the scope of these requirements we can start to write our tests. For web applications, we have a slew of tools to choose from. For unit testing in the PHP world our go to framework should be PHPUnit. For functional tests we have a few options in the Drupal CMS. These tests are developed using a framework that allows us to mock up a full application in an isolated environment which we can run tests.

This allows us to run the entire suite of tests before we merge in a feature branch. This ensures that the new feature works and that it is not breaking any other existing functionality. The last piece is critical. I’ve worked on some very large software projects that did not test for regressions. Each change we made cause a ripple of frustrations through our user base. No bueno! With a well developed test suite and clear communication we should be able to mitigate these risks!

In coming posts I would like to explore some of the base classes we have available to test our solutions in the context of Drupal. This will hopefully give you a more concrete understanding on how we can take a test plan and translate them into executable tests.

What level of testing do you do with your clients / projects? I'd love to discuss in the comments! 

Sep 26 2016
Sep 26

Earlier this month Acquia put on a great webinar hosted by Angie Byron & Gabor Hojtsy titled All You Need to Know About Drupal 8.2 and Beyond (slides linked below).

There were many topics covered and I could not help but get super excited for some things we can look forward to in the upcoming release of Drupal 8.2 slated for October 5th 2016.

Below are some takeaways I found particulary cool and wanted to share:

Migrate in Core

Currently we have a migrate UI available to us as a experimental core module. I have not played with this much to date but as a sitebuilder I am really excited to see efforts being made to develop a UI for this and bring it into core.  In previous migration efforts (using the migrate module) it was very much a job 100% slated for our devs and now I hope to be able to help with these efforts.  In Drupal 8.2 the migrate modules are still experemental but it looks like there was some mojor upgrades and a focus is being placed to get this out of experemental and into core sooner than later.

Content Workflow

Revision all the things! (well almost all the things)  The Content Workflow initiative is a result of Deploy and Workbench Suite of modules mantainers working together to bring this functionality into Drupal core.  These tools allow us to create/manage revisions and approval workflows for our content.  In Drupal 8.2 we are getting our first glimpse of this in core with the Content Moderation module added as an experimental core module for us to play with and provide feedback.  There is some really cool C.R.A.P. (create/read/archieve/purge) slated for this initiative down the road with things like Full-Site previews with "Workspaces".

Block Layouts

Some of you may remeber back in the early D8 beta days there being some work done on Block Layouts but it was pulled aong the way due to it not gong to be ready in time for launch.  Well in Drupal 8.2 we are getting a chance to see the some of this in action.  Again this is being released as a experemental core module. In 8.2 we will gain the ability to place blocks directy from the front end of the site and not have to access the blocks administration page.  This looks to be very much in line with how the inplace editor feels to an end user and an overall great usability improvement (especially for folks new to Drupal).

There are many other greats things in the works for Drupal core slated for 8.3-8.4 that were presented.  API Improvements, Enhanced media management, Dream Fields/Data modeling, Pre Content Type Layouts, Swapable Layouts and Preview-First Views UI just to name a few.

Check out the video/slides HERE for a full rundown and ways to help with all of these initiatives.

Thank you Acquia, Angie & Gabor for the exciting update!

Jul 15 2016
Jul 15

Welcome to the third and final installment of our three part Drupal 8, Pantheon & GitKraken series.  For more information on what this series will be covering check out our intro HERE.

The first installment of the series can be found HERE.  For the second installment click HERE.

OK so now that we have our site all set up on Pantheon, Gitkraken installed and configured, and our remote repo cloned it's time to version control some of our work.

Step 1. Exporting our sites "Active" configuration

When making changes on your Pantheon dev site you are changing the "active" configuration. There are many things we can do to our site to change this but for this example I have created a new view.  Once you have made your change the goal is to now take this active configuration, version controll it, and move it into our "staged" configuration:

1. In the admin menu go to Configuration>Configuration Synchronization and click the export tab.

2. With Full Archive selected, export the sites active config.

 

Step 2. Pull from the remote repo to our local repo

Now that we have our active config exported we want to do a Pull from the remote repo to ensure our local repo is up to date before we change the staged config.

1. In Gitkraken click on the "Pull" icon.

(*note: For this tutorial this step is technically not needed since we know no one has changed our site since we cloned our repo BUT it is very important to always pull before you push)

Step 2. Updating our local Repo's "Staged" Configuration

Now that we have our dev sites active config exported and we have pulled from the remote repo, we need to update our local repos staged config:

1. Extract all the files from the export and place them in the following directory of your local repo: sites\default\config.

 

Step 3. Stage and Commit our changes locally

Once we have these files in this directory we should see the changes in Gitkraken. and we can stage and commit them to our local repo.

1. Add a commit message (this is a brief description on what changes were made).

2. Click the Stage all changes button.

3. Click the commit button.

 

 

Step 4. "Push" changes committed from our local repo to our remote repo  

With our changes staged and committed local we are ready to push

1. Click the push icon in Gitkraken.

2. Verify that your commit on your Pantheon site.

 

Congratulations! Your work is now version controlled!!!

 

Final thoughts:

There is no doubt that a command line workflow is much faster and more efficient, but for me (for now) this is working and allowing me to collaborate with our more experienced developers.  Some other benefits of learning some of these tools is I can now use Gitkraken to pull and push to other repos (not just Pantheon). Git branching and the entire repo in general is much more easily visualized which makes understanding the whole process a lot easier.

What's Next?:

So while this is working, having a local developemnt environment integrated in this workflow is ideally how I want to work.  I have struggled for some time now fiding the best way to set up a local development environemnt on a windows machine without using any code, the command line, or having to edit a bunch of files on my local system.  Just recently (yesterday) I have had much success with Acquia Dev Desktop 2 and plan on sharing how I integrated that into this workflow

I hope others have found this helpful and look forward to sharing more with you.

Cheers!

Jul 08 2016
Jul 08

Welcome to the second installment of our three part Drupal 8, Pantheon & GitKraken series.  For more information on what this series will be covering check out our intro HERE.

The first installment of the series can be found HERE.

OK so now that we have our site all set up on Pantheon its time to get our Git workflow set up.

Step 1. Download and Install GitKraken

1. Go to www.gitkraken.com

2. Click the Download Now button at the upper right hand of the page

3. Select your platform and click Download

 

4. Run the the GitKrakenSetup.exe to install GitKraken

 

Step 2. Generate SSH Keys

Once you have GitKraken Installed you will need to configure a few things in order to generate your SSH Keys

1. Enter your Email Address, Name, Read and Agree to the End User License Agreement and click the Register button. (An email will be sent for you to verify within 5 days).

 

2. Click the gear icon in the uper right corner and select Authentication from the menu on the left.

3. Deselect the Use local SSH Agent checkbox and click the Generate button to create Public and private SSH Key that GitKraken will use.

 

4. Choose a location to save the file, save it, open it and copy the SSH Key.

 

Step 4. Upload your newly created SSH Key to Pantheon

Now that we have our SSH keys configured locally with GitKraken, it's time to get them uploaded to Pantheon.

1. Log into your Pantheon account

2. Click the account tab on your dashboard, select SSH Keys from the menu on the left, paste your SSH key into the text field and click the Add Key button.

 

Step 5. Clone your remote GIT repository to your local machine

Now that we have our SSH keys uploaded to Panteon we can use GitKraken to clone our remote repo to our local machine.

1. Click the Sites tab on your Pantheon account and click on your Drupal 8 site

 

2. Switch the connection mode from SFTP to Git and copy the git clone URL

(*note: After the Drupal install we will have have 1 file to commit SFTP mode. You will not be able to switch to Git mode until this change is commited)

 

3. Open Gitkraken and click the folder icon in the upper left corner.

4. Select Clone from the menu on the left, select a location for your local repository, paste in the clone URL from Pantheon and click the Clone the repo! button.

 

Congratulations! You now have your Git workflow completely set up and you are ready to start version controlling your work!

Woooohoooo!

In next weeks final installment of our Drupal 8, Pantheon, GitKraken series we will take a look at exporting, importing and version controlling your sites configuration.

Jul 01 2016
Jul 01

Welcome to the first installment of our three part Drupal 8, Pantheon & GitKraken series.  For more information on what this series will be covering check out our intro HERE.

Step 1. Setting up a Pantheon Account

The first thing we are going to want to do is create an account on Pantheon:

1. Go to www.pantheon.io

2. Click the Create Free Account button at the upper right hand of the page

 

 

3. Fill out the form and click create account 

 

Step 2. Create a Drupal 8 Site

After creating your Pantheon account you will be automatically logged in and redirected to your dashboard.  Time to create a Drupal 8 site! 

1. Click the Create new site button

 

2. Name your site (this will also be the URL for your site) and click the Create Site button

 

3. Select Drupal 8 from the list of options

 

 

4. After a short wait your site will be created and you can click the Visit your Pantheon Dashboard button

 

5. Once on your dashboard click on your newly created site under the sites tab

6. Click the Visit Development Site button an go through the Drupal Install.

(*note: we need to have the site in SFTP connection mode for the Drupal 8 install, we will be switching to Git a little later )

Congratulations! You have just created a pantheon account, have a fresh Drupal 8 site installed and ready to go, and a dev/test/live workflow set up.

YOU ROCK!

In next weeks installment we will take a look at getting Gitkraken set up, generating SSH Keys, and cloning your remote Git Repo to your local machine.

Jun 29 2016
Jun 29

With our new configuration management system as part of Drupal 8 core we now have a powerful system to manage site configuration between our different environments. This system does not declare a strict workflow for how to use configuration. In this post I’d like to explore some workflows we have been exploring.

First let's define what site configuration is.

There are two types of configuration in a Drupal site. First, simple configuration which stores basic key/value pairs such as integers, strings, and boolean values. Second, configuration entities, which we explored in this post. Basically configuration entities are more complex structures that define the architecture of our site. This would be things such as content types, views, and image styles.

Both types of configuration entities are exportable.

Where does this configuration live?

Site configuration lives in two places depending on its stage in life (no pun intended). There are two stages in a piece of configurations life:

  1. Staging

  2. Active

Active configuration lives in the database by default. It is the configuration that is currently being used by the site. Staged configuration lives on the file system by default.

When you make changes to the site within the web interface, for example changing the site name, you are changing the active configuration. This active configuration can them be exported and staged on another instance of the same site. The last piece is key:

Configuration is only to be moved between instances of the same site.

For example, I change the site name on our DEV environment and want to move this change to our TEST environment for testing.

Ok, let's talk workflows

There are a few ways we can manage the site configuration. Site configuration, like our code should follow a “flow up” model. That is, configuration will be committed to our git repo and moved up into higher order environments:

LOCAL → DEV → TEST → PROD

In this workflow configuration changes will be made as far down the chain as possible. In this case on a developer's local environment. These configuration changes should be exported and committed to their own branch. This branch can then be pushed for review.

Once pushed these configuration changes will be “staged” on the DEV environment. A site administrator will need to bring these staged changes into the “active” configuration. There are two ways we do that today:

  1. Through the sites UI from under ‘admin/config/development/configuration’

  2. Using a drush command ‘drush cim’ command to import staged configuration to active.

From what we are seeing this seems to be the defacto workflow at this point.

Further workflow Ideas

I am thinking there could be some interesting workflows that could emerge here. One idea is to have a branch (or tag) that triggers configuration imports using drush and fires off some automated tests. If all passes then merge into another designated branch for movement to a live environment.

Another idea is to use some of the emerging contrib modules to manage different “configuration states”. I believe this was discussed in the config_tools projects issue queue. Using this idea we can tag known “good” configurations and move between different “configuration states” of a given site. I am thinking we could even have the configuration hosted in separate repo then our code, if that makes any sense.

Bottom Line  

The new configuration management system offers a powerful tool to move changes on our sites between different instances. It does not however define an exact workflow to follow. I look forward to talking to folks on how they leverage this system to coordinate the efforts of high performing teams!

If you or your team is using this in different ways we would love to hear about it!

Jun 24 2016
Jun 24

For those of you who know me well, you know I do not like to play around with code all that much or even use command line tools if I can avoid it. There are many reasons for this but mostly I am just not that comfortable setting up, maintaining and using these type of tools.  That being said I do like to site build in Drupal….A LOT :). 

Lately I have been creating and managing Drupal 8 sites with Pantheon and using a Git client called GitKraken to manage my version control workflow and I have to say the experience has been FANTASTIC!

With these three components I am able to:

  • Create a brand new Drupal 8 site
  • Export/Import my sites configuration
  • Have a fully version controlled workflow with dev, test and live environments
  • Generate SSH keys
  • Clone / create a local repository
  • Stage and commit changes
  • Pull & Push code to a dev environment

All without ever touching a line of code or a command line!  Want to learn more??

If you said YES then you are in the right place.

Following this intro post there will be a three part weekly series where I will walk you through my experiences with setting up a new Drupal 8 site on Pantheon, managing configuration changes with Drupal 8, and managing a Git repository with GitKraken.

This is a great set up/intro for beginners looking to work with Drupal 8 and keep their work versioned controlled (which we should all do) or for folks like myself who would just rather use a GUI as opposed to command line tools.

Jun 14 2016
Jun 14

Drupal 8’s improvements to contact form management and creation is one of my favorite site building upgrades that has been added to Drupal 8’s core.

We now have the ability to field contact forms in the same familiar way as many other entities and can have multiple form variations living at different urls on the same site.

- Need a phone number field? Not a problem.

- Want it to be required? Piece of cake.

- Looking to have a RFQ form as well as a contact form? Yup, we got that….all in core!

All of your forms are nicely managed in one place (/admin/structure/contact) and over all it makes for a much improved experience from previous versions of Drupal.

Recently while building a new D8 site I had a request to hide the “preview” button that is shown on all the contact forms.  A task most commonly done with a simple form alter but not being a developer I wanted to see if I could do this without any code and not trouble our dev team as they were working on more complicated features.

Enter the Contact Storage module.  This little gem offers some really useful enhancements to the already much improved Drupal 8 contact form improvements.

First off it solved my issue of hiding the preview button with a simple check box on the contact form edit screen.

It also allows for a redirect path to be set which is great considering I would have done this with the Rules module in the past, which at the time of this post is still in alpha for D8.

Another nice little feature is the ability to change the text of the submit button….a common request which is now very easily accommodated right in the UI!

As the name suggests the Contact Storage module also provides storage for all the messages submitted through the forms on your site as well as views integration to manage them.

The admin view is configured with the ability to look at all of the submissions at once or filter them by individual forms.  The view itself is conviently accessible via a new "List" tab added to the contact form admin screen.

A big thanks to larowlan and all the contributors who helped put this module together and are currently maintaining it.

I have a feeling I will being using this one a lot more in the future!

Apr 11 2016
Apr 11

This past weekend we were honored to co-host the Drupal Global Training day at DoSomething.org in NYC. This training was focused on Drupal 8 module development. We have been training on the ins and out of Drupal 8 module development for over a year now but this time we changed the format, considerably. I think for the better! 

Using the Role Notices module, developed by Ted Bowman, we put together an exercise that walks you through building the functionality it exposes step by step. We also built a list of resources chock full of links pertaining to various tools and docs for getting your chops up with D8 development. 

All this work is open source and available at this link. I am really hoping that this content can serve as a valuable resource for folks looking to learn the proper flow of developing a Drupal 8 module.

There are so many exciting concepts and programming patterns to explore in D8, we hope you continue to join us during this jounrney. 

Mega thanks to everyone that helped make this happen! 

Mar 28 2016
Mar 28

When developing applications for Drupal the need to interact with what we call Entities arises quickly in our development cycle. The Entity system in Drupal has evolved greatly over the last couple of versions. Drupal 8 now contains a full set of APIs to define, manipulate, and manage entities of various types.

One aspect of Drupal 8 that left me a bit lost was the two different base Entity types. That is:

In this post, I’d like to talk a bit about the key differences between these two types of entities and discuss some of the potential use cases for each. I want to keep this as succinct as possible while still be able to clearly explain the two. Let me know how I did in the comments!

What is a Configuration Entity?

Generally speaking a configuration entity is something that a site administrator or site builder would be creating. There are many types of configuration entities that Drupal 8 implements in core. Some examples include Views, Image Styles, Vocabularies, Display settings, etc.

The idea of a configuration entity enables us to integrate the powerful new configuration system in D8 to the full featured Entity API. Combine this with the fact that we can export all of these configuration entities to YAML files and we have a very powerful solution for our development operations.

Configuration Entity information is stored as YAML. (as of writing active configuration is stored in the database but exportable as YAML)

What is a Content Entity?

Content Entities are pieces of content that are generally created by the content creators of our solutions. These entities serve as the underpinnings of the structured content within our application. Content entities come in various different types in core Drupal 8. This includes nodes, users, block types, comments, etc.

Content entities allow us to create entities that are tightly integrated with the Field API and the same Entity API configuration entities derive from. This allows content entities to be fieldable by site builders in order to define the structure of our content while still exposing a consistent set of APIs for developers to work with.

Content Entity information is stored in the database.

To Summarize

With the above being said we can summarize the core differences between these base Entities into two core areas:

  1. Where the information is stored.
    1. For Configuration Entities data is stored as YAML.
    2. For Content Entities data is stored in tables / fields in our database.
  2. Who is creating the information
    1. For Configuration Entities site builder / site administrators.
    2. For Content Entities content creators / end users.

My motivation to write this was to explore and better understand the differences between these two core types of Entities BUT I think it may be just as important (if not more) to understand the similarities. Both are now under the scope of same unified Entity API. That is important. They provide integration points from the Entity API to two other important APIs, the configuration API and field API respectfully.

As we continue to work with these systems I look forward to learning more about how to leverage these systems to develop solutions for our clients!

Mar 04 2016
Mar 04

In the world of web development we developers are presented with a pallet of options when tasked with developing a solution. We have a wide array of server side programming languages, their respective frameworks, various DBMS systems, and a growing choice of client side presentation frameworks. Choosing the best software stack for given requirement can be overwhelming.

Over the past few years we have been interested in the ability of the Drupal CMS to be built for web applications and function more as a framework then as a predefined CMS platform. We spent a long time working with the inner workings of Drupal 6, Drupal 7, and now Drupal 8.  We have successfully implemented various systems using this framework that have real data models, users, and requirements. Over a few forth coming articles I would like to present some of the modules, tools, and techniques we have discovered along our journey. Some of the more interesting discoveries was the ability to setup true relational data models using the field system. The skill set required to build these apps is distributed in a slightly different way then the more “traditional” popular frameworks. It is almost reminiscent of when you developed small (non-shared) DB apps with Access. Field creation and their specs are defined using the web interface and as such can be performed by less skilled but trained staff. At the same time these fields can be consumed by developers to bundle specific application functions. I believe this is a powerful proposition for development shops and can prove useful for servicing customers of these apps.

In future posts I would like to delve into the specifics of these methods and share with the community the powerful framework the Drupal system can be used for. Drupal 8 represents a very positive shift in how we approach our solutions. It is truly exciting times!

Feb 03 2016
Feb 03

We love Drupal Commerce!

Its an extremely flexible ecommerce framework largely built on rules which as a site builder makes me very happy.

It is above and beyond our current go-to platform for building ecommerce sites. However if you have ever built a site with Drupal Commerce you know that there are few main components, Product Types, SKU’s and Product Displays.

For those of you who are unfamiliar, when using Drupal Commerce you create a content type as a “Display” which will house certain “Product Types” via a product reference field. You can have multiple product types which will house all of your various SKU’s.

You can think of displays as shelves in a physical retail store. Once you have built your “shelf” you can then place your “shirts” on it. A “shirt” would be an example of a product type. The shirts on your shelf may be different sizes and different colors but they are all shirts. The SKU is what would differentiate the various size and color options. This is a common way we would explain this to new clients who we are building a Drupal Commerce site for that may not be familiar with the platform.

This concept of Displays, Product Types, and SKU's, although very logical, can cause a bit of confusion and can feel cumbersome. This is especially true since the creation of displays and products are managed in two different areas of the site.

Enter the Inline Entity Forms module.

The Inline Entity Form module adds a new widget type to the Product Reference field which when added to a Display allows for streamlined workflow for users to add/manage products all within the display!

To achieve a basic set up for this simply do the following (assuming you have Drupal Commerce installed and configured):

  1. Install and enable the Inline Entity Form module.
  2. Add a product reference field to your Display Content Type.
  3. Select the new “Inline entity form - Multiple values” options as the widget for this field.
  4. Select the product types you want to be referenced for this display.
  5. Select Allow Users to add new products.
  6. Select Unlimited on the number of values
  7. Save 

*There are some other options which are helpful in this set up that you can explore but this is what I would consider the basis to streamlining this process.

Now with this set up a user can add a product to their site by creating a display. Within the display there is a product reference section that will allow them to select a product type and add/configure individual skus of that type, for that display….all in one place :).

If they want to add existing skus to a display they can do that as well with some options selected in the widget set up.

We find this to be a great improvement to the product creation/management workflow and have had a better response from clients when rolling out new systems with this set up. I highly recommend you check out the Inline Entity Form module if you a builing a drupal commerce site. As always a big thanks to Ryan Szrama (rszrama) and all the folks over at Commerce Guys for building/maintaining such an awesome ecommerce framework & contributed modules to extend it!

Dec 22 2015
Dec 22

We are excited about Drupal 8 and the many new front and back end features it is bringing to the table. Our block system has been completely rewritten and while blocks in Drupal are nothing new in Drupal 8 they are getting some serious upgrades!

Block Types

In Drupal 8 we now have the concept of block types. In previous versions of Drupal our blocks were pretty basic. They offered us a title and a body field. In Drupal 8 we can have various custom block types which are fieldable, very similar to content types. This provides a whole new level of customization to blocks that we have never had in the past.

Blocks in multiple regions

Another major change to the block system in Drupal 8 is the ability to place the same block in multiple regions. We can now choose to display blocks in different places on different pages etc.

View modes for blocks

We can also choose to have various view modes for our blocks. This allows us to customize what fields are displayed based on the view mode we select. This combined with Block Types and the ability to put blocks in multiple regions opens up a level of flexibility that is far superior to anything we have had to date with the block system in Drupal.

Display title check box

In Drupal 8 we now have a simple check box to turn the display of a block title on and off. No more having to type "<none>" if you don’t want the title to display.

New things are now blocks

We have some new blocks available to us in Drupal 8:

  • Site Branding
  • Page Titles
  • Tabs
  • Messages
  • Breadcrumbs

This gives us much greater control over where these items display. For anyone who has worked with Drupal in the past having the page title as a block is going to make life a little easier for us ;)

Blocks are now exportable

With Configuration Management built into Drupal 8 our blocks are now exportable. This was a big deterrent for us using blocks too heavily in the past as they did not travel well, or easily. Thankfully that is a thing of the past!

New Block Layout UI

There is a brand new UI for block management in D8. The new “Block Layout” screen shows all of our available regions and the blocks within them similar to the block screens in the past. One of the main differences is it gives us access to view and create custom blocks as well as manage/create block types via a “Custom Block Library” tab at the top of the page.

Another big change is we no longer have this massive list of every block on the site at the bottom of the page. Instead we now have a “Place Block” button that will open up a modal showing us all of the available blocks for us to place.

Within the modal we have search box which filters down our available blocks by title in real time making finding what you're looking for much quicker without the need for any contributed modules.

Overall the Block system in Drupal 8 is more flexible, functional, and manageable right out of the box.  I am looking forward to building more with it and seeing how these new features play into customer requirements and new site architecture.

Here's to one of the many new and great things with Drupal 8!

Dec 09 2015
Dec 09

We are excited to announce the release of the Exploring Drupal 8 podcast series!

We partnered with the fine folks at TalkingDrupal.com to put togehter a six episode series to get you up to speed with Drupal 8 fast. Our goal was to provide some insight in the major changes we are all seeing with Drupal 8 in a quick easily consumable format and hopefully inspire listeners to explore further.

We have released the series in a Netflix style binge format. So get together snuggle up in a warm blanket and Drupal 8 and chill.

http://www.talkingdrupal.com/exploring-drupal-8

In addition we will be hosting two webinars after the holidays to answer questions in a more interactive format. Register via the link above. We hope to see you there!

Nov 24 2015
Nov 24

In the wonderful world of software development we have back end developers, front end developers, project managers, designers and a slew of other roles and titles that make it all possible and great!  With Drupal came a new role…the site builder.

One of the most satisfying roles for me at Sego is that of a site builder. There is no better feeling than being able to implement a feature or build something from scratch without having to touch ANY code. This is of course the opinion of someone who is not a programmer by trade but I imagine this sense of satisfaction from creating something out of nothing is why most programmers do what they do….its an amazing feeling.

Up until my experience with Drupal I would consult with clients creating comps based off of their needs and then pass them along to our developers. The team would bring the product to life and turn these static comps into functioning pieces of software. It was satisfying to see the finished product but I always felt like I wanted to be more involved in the actual building of the software.

When we first started using Drupal I immediately began exploring all that could be done in the UI and quickly said “wow this is confusing”. As with most things Drupal it took practice, persistence, and a lot of help from the community but before I knew it I started understanding the lay of the land.

Shortly after that I began building out small pieces of projects with our devs. Setting up some content types, building out different menus, and little by little we started to realize that as a site builder I could reduce their workload and we could really push projects out quicker with this Drupal thing.  I was building not just designing...without any code...awesome!

Many years later the power of site building is better than ever especially with some of the major upgrades with Drupal 8. This is one of the main reasons why we love building with Drupal. It allows for a synergy between site builders and developers that when done right can produce some power results in incredibly fast turnaround times. We have entire platforms that are fully extendable all though site building which allows for our devs to focus on more complicated issues while our site builders (me included) can extend these existing platforms.

If you are looking to get involved with technology and do not have a lot of, or any formal programming experience, I would highly recommend looking into Drupal site building. It’s open, has a great community, and when mastered will allow you to build some pretty amazing things all without ever having to touch a line code.

Nov 04 2015
Nov 04

With Drupal 8 in RC2 we believe it is time to get your engines humming with learning all the in's and out's of the new version of our favorite content managment system! Towards this goal we have put together a few programs to get you and your team up to speed fast. We have been hitting the road over the past few months getting the word out and providing Drupal training wherever we can.

Our journey started up north at Drupal North. We had to the opporintity to give a few talks around Drupal 8 Site Building and Drupal 8 Module Development. Turn out was excellent and the camp was, as expected, filled with awesome folks. It was an excellent time... Toronto rocks! 

This lead up to NYCCamp, which was held at the United Nations. We had the opportunity to give the half day Drupal 8 Module Development training. Again, we had a great turn out and was able to get everyone feeling confortable coding quickly! We leveraged our Stack Starter platform to distribute full development environments and we were super excited that it worked smoothly! We recieved a bunch of great feedback and was happy to be able to implement much of it very quickly. 

Our most recent stop of our Drupal 8 training tour was up in Providance RI at NEDCamp. The folks in Rhode Island can put together a camp! We had the opportunity to give a talk on Drupal 8 site building and provided a full day training on module development. We took the things we learned at previous camps and built on them for NEDCamp. We think the outcome was a positive one! 

We are looking forward to continuing to give our training at various camps. Through our training efforts and the development of TryDrupal8.com we are proud to say we have spun up thousands of Drupal 8 instances over the beta's and we believe the future is only going to get brigher!

Stay tuned for some more exciting training news in the near future! If you or your team is looking for a quick and cost effective way to get up to speed give us a shout

Oct 02 2015
Oct 02

For those of you who know us, you know we have been excited about Drupal 8 for a very long time. I can recall discussing at one of our user group meetups over two years ago now touting how D8 is going to be a major step forward for us in the Drupal community. With ZERO critical issues left and Dries announcing at DrupalCon Barcelona that we can expect a RC (release candidate) with in the next few days... the time is near!

If you have not started to get your company up to speed with the developments in D8 now is the perfect time! Whether you are a site builder, developer, or stake holder you can not ignore the exciting developments. This release will truly be garnering a new age in Drupal, enabling us to take advantage and integrate with a whole world of open source technologies that have traditionally been challenging to leverage within the context of Drupal. At Sego, although we have a sweet spot for Drupal, we strongly believe in choosing the best tool for the job. With Drupal 8 it will make it much easier for us to develop clean, best of breed solutions for our clients leveraging a wide spectrum of open source technologies. That get us buzzing!! We are up in Road Island next week for NEDCamp. We will be doing the D8 module development training. If you are in the area, its a great value to get up to speed with some of the development changes we can expect.

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