Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Oct 07 2021
Oct 07

 At Globant, on my team, we have been exploring multiple content staging and deployment strategies. The observations from some of which can be found in my earlier posts here and here.

Next Tuesday, Makbul and Rahul from my team are presenting a consolidation of our findings, and a refined strategy that we use in our enterprise projects to create, stage and deploy content across environments using a robust process that increases our productivity significantly.

Sign up for the webinar @ https://bit.ly/3DdBAKD

image 18

Aug 25 2021
Aug 25

I recently posted on the Globant Medium blog comparing the various Content Staging and Deployment Strategies that I explored. The options explored included Deploy module, Content Sync, Content Synchronizer, Entity Share, and paid services like Content Sync, Acquia Content Hub, and Entity Pilot.

The criteria for the search were:

  • The solution is opensource and not requiring a paid service.
  • Depends on modules that have good community support, active development, usage and maintenance.
  • Allows moving content from one environment to another
  • Allows version control of content
  • Supports most (if not all) field types, including paragraphs to start with
  • Supports translation
  • Supports updation of existing content and not just initial import
  • Recursively picks all dependency content required

The solution we landed on was a combination of

Workflow

The solution provides a simple workflow that now involves
1) Export content from the UI of any environment
2) The exported content is written into the codebase (and thereby version controlled)
3) Git push from that environment, and Git pull on the other environments
3) Import the content by one drush command (drush dcim ) on any environment.

Pics from the contrib module:

image 17

https://miro.medium.com/max/506/0*R8kF0uMi_2lNOWzHhttps://miro.medium.com/max/415/0*12L3__NyNzwgtjO0

Aug 18 2021
Aug 18

D8cards.com (Drupal 8 cards) started as a group study exercise for my team to help the team learn Drupal 8, especially since there was a significant learning curve between D7 and D8. More about it here. More about it here and here.

The domain expired some months ago, which I did not renew. Many people reached out on twitter and email looking for an archive of the same. Someone was looking for it on reddit. Posting an archive of the same here.

The exercises do remain relevant to D9, and can be good challenges for anyone comfortable with Drupal Site Building and getting started with Module Development.

Download the cards here.

Sample Card

Download the cards here.

Additional Resources:

Aug 18 2021
Aug 18

Did Config Management Initiative in Drupal do the exact opposite of what it intended to do? Is the lack of a documented Config Management Strategy creating a barrier for teams to adopt Drupal? Can team be successful with using Drupal without investing heavily to figure out their own Config Management Recipe?

Let us explore with a simulation of what would be an experience of an engineer trying to implement a basic config management strategy on their project, and how it ends up with a chicken-egg problem, ultimately leading to a vortex of config management modules.

Configuration Management in Drupal has been ever changing. Drupal 7 had features as a go-to standard to isolate configuration from database and to version control it. Drupal Configuration Management Initiative resulted in a configuration management interface in core, which was supposed to be the holy grail of all config management problems in Drupal 7. Which it failed to be. Features, which was supposed to be extinct by now due to CME, is now becoming popular again, due to the limitations in Core CMI. And there is a plethora of exploding set of Config Management modules in Drupal 8/9, that make it challenging to decide “What is a good config management strategy for my Drupal project?”

There is no one-size-fits-all documented way of configuration management in Drupal. Which adds to its learning curve. Sticking to core CMI includes challenges of having to depend on a database copy to setup new environments, or overwriting the UUID of the site in some ways, to get the configuration to be imported in a newly setup environment. While this is addressed in Drupal 8.6 to some level, but it still has a chicken-egg problem that we will discuss below.  Further, you can’t pull to your environment config changes that your team member just pushed in, unless you export your configuration before you pull your team mate’s changes.

Trying to simulate here the journey of what would be that of a developer or a tech lead, trying to accomplish basic configuration management on their project, with a very basic objective, looks like.

Objective:

  1. Be able to setup an environment from scratch, with all required configuration, without any dependency of an old import of a database dumps flying around in Slack, but just using the codebase
  2. Ensure changes to configuration are version controlled
  3. Allow incremental changes to configuration to be added, without having to rely on complete dump of configuration, that often have unrequired changes from local environment. 
  4. Allow team members to work in parallel, often on same configuration, allowing them to merge their incremental changes

Initialization of the project:

  • Clone from a composer-based template and not in the legacy way
  • Stack to use : Lando or DDev. Both look great. I picked Lando. But DDev should be equally good. 
  • Do a composer install to get all dependencies
  • Add Config Ignore module, and drush as well (drush may not be required if you used the first template above, will be needed if you used the second one)
    composer require drupal/config_ignore
    composer require drush/drush
  • Proceed with composer install
  • Power up your local server - lando start - if you are using Lando
  • Install the site using drush si command
  • And your local site should be up and running now!
    (If you are using lando, you can use check the url via lando info)
    (If you are using lando, and you see a 404 instead of your Drupal homepage, run these 3 magic commands)
  • Change config sync directory in settings.php to below
    $settings["config_sync_directory"] = "../config/sync";
  • Ensure you have a proper .gitignore file. If you used the first template above, create one manually by copying this from template 2. 
  • Enable config ignore module
  • Add the following to config ignore settings via UI (We will discuss later why we are doing this)
    shortcut.*
    image 8
  • Remove the remnant sites/default/files/config_* directory you may have from the initial setup
  • Make any initial configuration changes that you see required, content types, or other configuration. 
  • Do an export of initial configuration via drush cex. This will populate your initial site config into config/sync directory
  • Note the UUID of the installation -
    drush config-get "system.site" uuid
    Communicate this to your team, or add it to the readmefile. This is required for the rest of the team to setup their local environment later. 
  • Check in your code to the repo that the team would use. 

Setting up local environment by other team members

  • Clone from the repo
  • If using lando - lando init (if lando.yml was checked into the repo during earlier project setup, this is not required. Checking in that file might be required, only if you are trying to freeze specific versions of php, or some custom tooling to lando). Use options - Current Working Directory, Drupal 9, web, any-name for lando init
  • Run composer install
  • Up your servers (lando up if you are using lando)
  • Now, if you run a site install, and try to import the config from the config sync folder you have on your site, the site would not know the existence of config/sync directory. 
  • But, there is a deadlock. settings.php would not exist until we ran install. But if we run install, it would create a site with a different UUID and not honoring the existing configuration. We could run drush si --existing-config , but how would it know about the config/sync folder as we haven’t updated it in the settings.php which doesn’t exist yet.
    image 10
  • We stumbled into the popular chicken-egg problem with Drupal CMI that is discussed here and here in detail.
  • Let us work around this, by doing a regular installation of the site (without using existing config, then manually change the UUID of the site, then update config sync directory in settings.php, and then doing a drush CIM. 
  • Run a simple drush si (for site install)
  • Change the UUID of the site to the UUID mentioned in initial setup
    drush config-set "system.site" uuid  5a5ccb99-8411-42e8-a8fe-3c4b2d827910
  • Now you think you could run configuration import (drush cim). That still won’t work because you there are some configuration related to shortcut module etc, that would throw an error like this
    image 12
  • We added this to config ignore in the project setup, but that config is not imported yet, so it doesn’t know that it should ignore that shortcut config. 
  • So let us enable config ignore manually, and add shortcut.* to config ignore, and try the import again.
  • Now run a config import (drush cmi), and you have your local instance ready, which is a clone of the instance that was setup initially, without any transfer of database dumps, across slack.

So far, so good!! It wasn't straight forward. Had to plug in config ignore to get the config sync to work. Had to work around the chicken-egg problem for getting the site install to work with existing configuration. But we got there!

Workflow for feature development story

Looks like what was a very robust configuration management system that Drupal had with features in Drupal 7, has expanded into a large system of scattered and often abandoned maintained modules, to accomplish a simple objective of having configuration in code, allowing teammates to work in parallel. CMI looks to have accomplished the exact opposite of what it started to do in the first place.

This creates a barrier of entry for organizations to start with Drupal, as there is no documented way of handling configuration management that allows a few team members to work in parallel, unless they are working on completely unrelated items not touching configuration that other team members are working on.

Unless a team have their own recipe figured out, with a combination of techniques and combination of modules that work for them and their customers, they can hardly expect any success with having a sustainable configuration management strategy.

Why is it so hard to have one prescribed configuration management strategy that works for most (if not all) of the Drupal projects, allowing parallel collaboration between team members?

Most teams have their recipes figured out with their own combination of tools and techniques using some part of core CMI, and Features module (yeah, Features again, which comes with its own set of caveats and challenges, some of which you can see in this video), and a set of Config Ignore, Confit Split, and Config Merge, Config Sync, Config Normalizer and other modules.

But there is definitely a need to remove the barrier to entry, allowing more teams to adopt Drupal, without having to invest heavily upfront in discovering a secret sauce combination of modules and techniques to get basic configuration working for a simple team that just a few people working in parallel on configuration.

There are multiple configuration management strategies that I have been exposed to, from the teams that I have worked with in the past few years. Not just calling out the problem. And I acknowledge the tonnes of work that went into CMI from many volunteers. Although, as with anything, we should look at things from the value it adds, and not just the intent and effort. 

As with any opensource community, you have as much access to solve the problem, as you have access to talk about it. As my part to solving this problem, I would try to analyze them against how they fit into the problem statement defined in the objective above, and try to document one such simple strategy either here on somewhere on drupal.org.

Meanwhile, may be, there is already a popular one that I failed to notice. May be, this is not even a problem, and I am just missing some pieces of the puzzle that are not very obvious.

If you know of one documented config management strategy that qualifies the below criteria, drop a link in the comments.

  • Spinning up local instances from repo, without depending on a database dump
  • Version control config
  • Allow 3-way merging of config from local and upstream
  • Is documented with a recipe of modules and techniques to use.
Aug 16 2021
Aug 16

Tried browser-based development with on-demand environments on the fly, using gitpod.

There is an existing private github repo that contained code for a D9 site (this website). The objective that I set out with -

  • Pull the repo code onto gitpod
  • Make some code changes in code
  • Test the change on an on-demand environment
  • Commit the code change to the repo

Started by spinning off a workspace by using gitpod.io/#. Since the repo had the lando file that defined the environment recipe that was needed for this codebase, I was hoping that it would automatically spin up an environment. That, however, did not happen to be the case.

I was able to spin up the environment after pushing to the repo the .gitpod.Dockerfile  .gitpod.yml files, which I grabbed from this repo of Bassam.

Further which once the workspace was spinned up, I could run lando up on the terminal of the online VS code, and could access the Drupal site, make the code change, and commit.

image 5

Overall, that was good.

Would I be happy to swap it with my local workspace?
While this clearly would free your RAM, and probably save your Macbook's fan, which is always spinning due to Docker. And this could be a model to reduce costs for teams as well, by switching from high-end laptops to low-end Chromebooks for development. But at this point, the experience is far from being optimal.

  • There was clearly significant latency while typing commands in the terminal, or during the IDE's autocomplete.

Not sure where is the nearest endpoint for Gitpod near to my location in India, and if that would change anything if the app was being served from a location closer to me.

But this is just the beginning, and the experience will probably evolve with Gitpod and others creating native apps for Android Chromebooks, Windows and Mac, along with access via Browser. And considering the significant cost savings, this is the direction that web development would take in the days to come. This shift would be inevitable, and I am happy to see the tools are progressing in the right direction. But we aren't there yet.

Aug 15 2021
Aug 15

Moved this website (www.tanay.co.in) from an older version of Drupal 7 to Drupal 9. And switched the DNS to this new site, just a while earlier.

The migration was fairly straight forward using the Migrate Drupal UI module. I had attempted moving this site to D8 5 years ago. It was a bit messy, and I chose to leave it in Drupal 7. My observations from back then are detailed here.

I have been away from Drupal for over a couple of years now, until very recently. And I was expecting no smoother experience than last time. But it was surprisingly easy. Zero code. (Although this website doesn't have any custom functionality that I chose to port over.)

OpenLiteSpeed
I had some IMCE editor and upload plugins on D7, that allowed copy-paste of content and images directly by from Google Docs, where I used to draft my posts. And those plugins saved images and rendered them in a not so straight forward way, without extensions. I was expecting that these existing images wouldn't work out of the box, but they did, on Apache at least, with some htaccess directives. I initially setup on the server an OpenLiteSpeed (OLS) server instead of Apache. But these images wouldn't render. Had a thread with OLS team, that tried helping. But it wasn't a comprehensive fix and the fix was breaking a few other things. And after trying multiple things, I chose to stick with good old Apache.

image 6
A snippet from my conversation thread with the LiteSpeed team.

Litespeed is some tech I would watch out for in the years to come, although they are at this point far away from being a dependable Apache alternative. I am especially intrigued by their Drupal caching plugin https://github.com/litespeedtech/lscache-drupal/ - which claims to increase performance of Drupal by rendering cache from the webserver, without invoking PHP. Yet to try it out. Not sure if it works with Apache, probably not. Also, not sure if anything would be preventing it to be ported to work with Apache/Nginx, as well.

KeyHelp
Got introduced to panels that provide a UI on top of Linux servers, when I was trying out Litespeed. Because, the same company that created LiteSpeed web server also build this panel called CyberPanel.  I am not a big fan of such panels and would rather do things myself on the terminal. But wanted to try them out as they made me nostalgic of the days when I tinkered with Cpanel (yet another Panel) and WHMCS, selling small hosting packages via geniehost.com (a domain which I later sold away to the current owner, a hosting company with the same name based out of Australia). While Cyberpanel was nice and flashy, I had to switch to Apache for the reason mentioned above. Found KeyHelp while looking out for alternatives. Seems to work fine so far. Gives the feel of having a fully loaded shared hosting, with all the bells and whistles, while actually being a dedicated server. This server is a $6/month Debian box from DigitalOcean.
Web Hosting Control Panel Comparison 2019 | Woktron Hosting

Drupal Planet - Did the change in term IDs mess up Drupal Planet feed?
After I moved the site to D9, switched the DNS, and it has been a few hours. Then I realized, I may have sent some spam on Drupal Planet feed. Because, Drupal planet feed is based on RSS feeds, and I had used a specific term for tagging content that is relevant to Drupal Planet, and now, the terms IDs would have changed, and now my D9 site would have pushed a bunch of irrelevant posts to Drupal Planet. Was pretty sure this was an embarrassing situation to spam so many users with irrelevant posts. Fortunately, just realized the D9 site has the same term ids as the D7 site prior to migration. That is not the usual out-of-the-box behavior of Drupal Migrate module, back when I used it for migrating content on work projects. Whatever caused that to change, at least in Drupal Migrate UI, is a good change. This would have been a pitfall otherwise.

Setting up a LAMP stack
Setting up a LAMP stack from scratch is something I haven't done in the recent past. This was something I used to do day in day out, with my buddy Ramesh Babu (drupal.org profile), while we worked for Harvest Technologies in Hyderabad, back in the day like 2011-2012. Ramesh passed away due to Covid a couple of months ago, leaving his family in a tough situation. Definitely missing him. He would have been the first one I would have called when I messed up setting this server up right the first time. Working on web development these days makes your more abstracted from LAMP stack due to the likes of Lando, DDev for local, and the likes of Acquia, Pantheon for the cloud.

Feels good to have this site moved to D9. This was long overdue.

Apr 06 2018
Apr 06

NOTE: While I work for a company that is closely related to Drupal, the thoughts expressed here DO NOT, in any way, represent my employer.

 

When the creator of Zen theme of the Drupal CMS chose a logo for the theme, they would have never imagined that this decision would cause such large confusion and probable escalation of heat between two countries years down the lane.

 

What happened:

On April 7 2018 (today), Multiple Indian Government websites, built and maintained by National Informatics Center, went down or were partially unavailable. Some of them showed a maintenance page.

They include:

* https://mod.gov.in/ (Ministry of Defence)

* Multiple others - Law, Home and Labour Ministry websites

News coverage:

* Youtube : TimesNow

* Times Now

* Hindustan Times

* NDTV

* Times of India


What does the Indian Government say?

* "National cybersecurity chief Gulshan Rai said the 10 websites hosted by the National Informatics Centre (NIC) went down after a hardware failure."

* There is no hacking or coordinated cyber attack on website of central ministries. There was a hardware failure in the storage network system at the NIC which resulted in a number of government websites being serviced by that system going down. We are working to replace the hardware and these websites will be up soon,” said Rai.

What caused it?

* Limited information is available in the public domain to be certain. Although there is no information as of now, that any site was compromised.

* While the sites that were down were Drupal ones, NIC builds most of their sites on Drupal. Which explains it.

* The sites were just showing a maintenance page. Nothing suggested they were compromised. A maintenance page is shown on various occasions, while in this case, the MySQL servers being down either due to a hardware failure as the Govt claims or due to large traffic, or due to an orchestrated DDOS attack, could be a reason.

* None of the above instances (including a DDOS attack) would suggest any data being compromised.

 

The Chinese connection:

* Almost every Indian media agency attributed this to hacking by  "Chinese Hackers".

* The maintenance pages of some of these sites showed Drupal Zen Theme's logo, which is has a Chinese-looking (or Japanese?) language character in its logo.

* In the context of strained relationships between China and India, all news agencies interpreted this Drupal maintenance page with a Japanese logo as "defacement by Chinese hackers"

 

 

 

Bad PR for Drupal:

While there is no reason to suspect Drupal was at fault, Drupal’s pictures were splashed all over the TV and news sites today claiming hack by Chinese hackers by misinformed Indian News agencies.

 

Mar 24 2017
Mar 24

Drupal Community is in a tough situation. A series of events had led to a popular contributor and leader from the Drupal community, Larry Garfield, to be asked to step down. Apparently, there was some incriminating evidence against Larry, that has led Drupal Association (DA) to take this decision.

 

I am not going into the details of the issue, which you can understand from here, here, here and here.

 

Several people, over the past day, have asked me if I approve of DA’s decision and Dries’ actions. I had chosen to not take a side, for I believe there has been an imbalance of information available to me from both perspectives to be able to form a sound opinion about the issue.

 

I see the current situation in a deadlock.

  1. A large section of the Drupal community has expressed displeasure and disapproval of DA/CWG’s decision, demanding that any evidence that can prove in any way that Larry has violated the Code of Conduct, or in anyway abused anyone, or used his position in the Drupal community to force his ways of life on anyone, be made public, justifying DA’s decision.

  2. DA/CWG has so far refused to disclose any evidence or supporting details, apparently in the interest of protecting the privacy of the other members who provided the evidence, as well as in the interest of Larry.

 

It is difficult to restore normalcy and trust in DA without releasing more information and evidence. And DA would not want to do it to protect the members who shared the evidence to DA. Hence the deadlock.

 

Drupal Community, as I have known it, has always been the most open and embracing community to people of all races, gender, orientation and ways of life. And I strongly believe it still remains the same.

 

To see something like this break the trust that the community and Drupal Association has earned over the years, is disheartening.

 

Here are a couple of ways, I believe, in which DA can restore the faith of the community on the association and CWG:

  1. Release the evidence, withholding any personal details of any of the personnel who provided the evidence, masking any data that could either directly or indirectly lead to any specific individuals from being recognized.

  2. If the evidence has such personal information scattered all over, making it difficult for DA to make the evidence public, DA could invite a panel of five prominent leaders from Drupal or other Opensource communities all over, who have publicly expressed their disapproval of DA’s decision. DA can then share the evidence with the panel, who could then review the decision and express their opinion about if DA’s decision to ask Larry to step down was reasonable, considering the evidence. The panel members, before being able to access the evidence, should agree to ensure they will keep all evidence shared with them extremely confidential, and will not disclose anything from the evidence, except their opinion about whether the decision taken by DA was reasonable.

Another idea for building such Panel easier would be - DA’s elections for Position of Director at Large have just ended. The list of candidates is here -  Inviting the top 5 contestants, who won the maximum votes, could make such panel formation pretty quick.

 

DA might not be technically accountable to validate every decision of their board by some external panel. However the onus is on DA to restore any lost confidence of the community on DA/CWG and to come out clean.  

 

If there is anything that DA could do, to restore the lost trust and confidence that the community has vested so far on DA, and lost significantly over the past couple of days, I think this would be it.

 

DA/CWG still has my confidence and trust. However, with the data available in front of me, I am inclined to believe that the decision taken by DA was not reasonable or justified. Although I still believe this is because DA hasn’t made public, their perspective of things and events. Would love to see DA go the extra mile to restore everyone’s confidence on the association.

 

Thumbnail Image: Source

 

Mar 16 2017
Mar 16

If there is anything in which #Drupal 7 is better than Drupal 8, it is the learning ecosystem that D7 had around it, which D8 lacks.

But there is a way you can help make the situation better, like I just did. I voted for Prasad Shirgaonkar who is running for the "Director At-Large' position on the board of the Drupal Association!

 

Prasad Shir, fondly called "Prasad Sir” by most people that know him, is one of the best technical trainers and technical content creators that I have ever seen.

He has been involved in building over 200 Drupal projects worldwide, trained hundreds of developers and several corporate teams to bring them onto the Drupal platform, has been a part of the core team at Acquia that built Drupal Certification. He has been a speaker at multiple DrupalCons and DrupalCamps.

Besides designing and running the Drupal certifications, Prasad has produced some of the best technical resources available for D8, some of which you might have already consumed unknowingly, if you have used one of those Drupal certification guides published by Acquia. He leads all our training effort in Acquia India, and is also a regular trainer at most of the community training programs that happen in India camps.

Prasad has volunteered to nominate himself for the Drupal Board's Directory At-Large position on the insistence of a large number of his fans like myself in the Drupal community, and I sincerely believe he can give the much-needed push that the Drupal Learning Ecosystem requires at this point of time.

Should he be elected, he will be the right guy, at the right place to make Drupal learning a better experience for the large and ever-growing Drupal community.

You can vote @ https://assoc.drupal.org/…/2017-directo…/post/director-large by moving Prasad's pic to the top above the orange line!
 

 

May 13 2016
May 13

At my workplace, we had earlier formed a study group to try out some very simple Drupal 8 stuff.

 

As we progressed, we had built a bunch of activity cards that we used for the group.

 

They are now available @ www.d8cards.com.

 

Check them out. Each activity card has a tutorial and an exercise that you could try out. There are 21 cards covering varied Drupal 8 Topics.

Apr 13 2016
Apr 13

At Acquia India, 15 of us had enrolled ourselves in a self-guided D8 study group program. Most of us are developers who are very familiar with D7. Some of us are already working on full time Drupal 8 projects while some of us are trying out some pet projects.

The format of our study group looks like the below:

  1. We meet for 20 mins in the morning every alternate day (Mon, Wed, Fri) to discuss the activity card of the day

  2. We disperse and then complete the prescribed exercise offline during the day

  3. Often, we discuss the challenges or blockers from the day’s exercise on the next call

We have built a set of Activity Cards for this program. These cards assume you are very familiar with D7 and will cover topics that have significantly changed between D7 and D8. Each Activity card consists of:

  1. A small objective

  2. Primary Tutorial

  3. Exercise

  4. Some cards have an additional secondary tutorial / reference material and a bonus exercise

The exercises are crafted so they don’t take more than an hour to complete after reading the prescribed primary tutorial. Sometimes, they do take longer though.

These cards could be a great learning tool for small teams that might want to form a similar D8 study group.

These cards were built by a small team learning D8, than by someone who has already mastered it. So they could be prone to errors. Drop a note to me or comment here, if you see any errors in the cards, or if you have any suggestions on any of the cards, or if you wish to collaborate with us in building new cards.

The cards are available here. An embed of the doc is right below here. We have around ~10 cards as of date.  We will keep adding more cards to the collection as our study group progresses.

Click here to access the D8 Study Group Activity Cards

 

Edit: Removed the iframe embed of the doc.

Cover Pic Courtesy: http://blogs.lawlib.widener.edu/

Mar 07 2016
Mar 07

Starting Monday, you can vote for the next at-large director on our board. Before you do, our candidate sessions: https://t.co/B0lUqmUac4

— Drupal Association (@DrupalAssoc) March 4, 2016

Drupal Association Board Elections are around. So what are these elections? How would it matter to anyone in the Drupal community? Why should one vote?

The At-large Director position is Drupal Association’s way to ensure community representation on the Drupal Association board. ie, you could have a share in shaping the future of Drupal Association by voting for the right candidate whom you think would best represent the community’s interests. You can see the list of candidates competing for this here. More about the election process here.

I have decided to vote for Shyamala Rajaram. I met Shyamala for the first time in November 2008 at a Chennai Drupal Meetup, which she had organized. I had just moved into the city, for my job at TATA Consultancy Services. That was my first weekend in Chennai. Didn’t have many friends around and a lot of time to kill. Drupal, at that time to me, was one of the many CMSs that I had freelanced earlier. Although it was my favorite. But I never saw it as a career option. And was surprised to see a meetup happening in Chennai that weekend and thought of dropping by.

But the meetup definitely had a significant impact on my life and career. I had dabbled a lot with Drupal while in my college (Vellore Institute of Technology). Though Drupal was my favorite, I had always seen it as one of the many CMSs that were mushrooming every day in the PHP ecosystem. This specific meetup gave me an opportunity to see that Drupal and its community existed outside of the internet as well ;-)

And what surprised me the most was that the newspaper portal that I read every day then, one of the largest in India, was actually powered by Drupal, and architected by none other than Shyamala and her team!

Being one of the first adopters of Drupal in India, Shyamala has been organizing meetups in and around Chennai since 2007. She has spearheaded many community initiatives, including taking Drupal to Colleges in and around Chennai.

I believe she has the right mix of leadership and technical capabilities and can best represent the Drupal community in general, and India & Asia in specific, on the board of Drupal Association. All the very best Ma’am!

 

Jan 09 2016
Jan 09

So, Drupal 8 has been out. And Migrate framework is now part of core! I haven’t had a chance to try out a D7->D8 migration so far. Knowing that this would be something I might do probably a hundred times in the coming couple of years, I thought of giving it a try.

I will now attempt to migrate this current Drupal 7 website (www.tanay.co.in) to Drupal 8. I shall be taking the MigrateUpgrade-UI path (than the drush path) as described on https://www.drupal.org/node/2257723 . I don’t expect a full-replica of my current site on D8 at the end of this attempt, but we shall take a look at what worked, what didn’t work.

I used 8.0.2 version of Drupal core, and 8.x-1.x-dev release of Migrate Upgrade module.

These observations might probably NOT reflect the current state of the Migrate Upgrade module. It is highly likely that the module performs better than what is observed below - ie, Some issues noticed in this attempt might have already been fixed in the Migrate Upgrade Module.  Chances are also high that I missed some steps or screwed up something.

  1. Download and enable the migrate_upgrade module

  2. Navigate to the /upgrade path on your website

  3. Populate the Source SQL details and the site url to fetch files from

  4. This will show you a list of available and missing upgrade paths.

  5. Hit the “Perform Upgrade” button. Fingers Crossed!

  6. Still running after 5 mins.. Drupal seems to be doing some serious loads of stuff here..

  7. While I was waiting, I thought of checking out the sites/default/files folder on my Drupal 8 site. As I assumed nodes are now being migrated, probably the assets are being fetched. In which case, the sites/default/files should be filling up. Yep, it indeed is being populated..

  8. Let’s check out what is up with the Drupal 8 Database. Yay! It is being populated as well!

    Well, interesting to see that the node table on D8 doesn’t have the title column. I wonder where the titles sit now in D8. There doesn’t seem to be any node_title, node_field_title tables.. Well there seems to be a new table here though. It is node_field_data which seems to hold the titles of the nodes!

    Hello there node_field_data table! Good to see you. I am sure we are going to bump into each other many times in the coming days!

  9. Cool. Let’s switch back to the browser tab where the upgrade was running and see how things are going.

    Wow,. here we go! The upgrade is now complete.

First Look at the website:

The migration has definitely surprised me. I was expecting a lot of broken stuff. But it already looks good. The site seems to have all the content that I care about. I was surprises to see that some of the blocks of static markup, disqus comments that I had at various positions on the D7 site were migrated as-is into almost similar positions on the D8 site. I never expected that to be the case! I was expecting just the nodes and terms being moved around. THIS IS AMAZING so far...

Blocks were auto-migrated!

URL Aliases also seem to have come through fine!

Let’s edit a node and see how it looks…

Term References look good!

Although I am not sure if this was the case with only the default “tags” vocabulary. Probably even custom term reference fields added to custom types also get migrated just fine. Unfortunately, I don’t have such custom term reference field on my site to verify this.

All the content types look good!

This is amazing that all the content  types were just re-created by D8 using their structures from D7, at the click of a button!

Let’s open a content type, both in D7 and D8 and see how they compare. I am taking the most used content type on my site - The Article content type that I have got, which I use to post blog posts like this one.

D7:

D8:

Discounting Meta Tags field (that came from a contrib module), all fields look good.

The Image Field Attachments are broken :-(

The content type “article” had an image field and a file field. The file field rarely had any files attached but the image field had an image for every blog post. So, what happened to these image attachments:

The Image field was created on the D8 content type automatically by Drupal

The files were fetched and copied from the source site into the D8 sites/default/files folder

An entry was created for each file in the D8 site files table and these files can be managed from “admin/content/files” on the D8 site.

But the images were NOT attached by the migration to the relevant nodes


Let’s see how good things are. Before we check out how things are on the new D8 site with the old content from D7, here are a few things I am interested in:

  1. The content (nodes) obviously

  2. The term references (I don’t have any node references. So I am not bothered about it right now)

  3. Meta Tags (from the D7 Metatags module). This has 2 items of importance

    1. Checking if these tags themselves are migrated. AFAIR, I haven’t used the metatags module to store any per-node keywords on the module’s storage but the meta-tags are made to appear on the node pages using terms from a term reference field attached. So, irrespective of the migration path of metatags module the terms themselves would probably have been migrated into the D8 site if term reference migration worked on #b above

    2. The display of the metatags in the markup - I am not much bothered about them at this point of time. I don’t expect the upgrade to have ported the contrib metatag module configuration as well. Should be good as long as I have the tags available somewhere on the D8 site. I will probably configure the module afresh on the D8 site using tokens similar to those used on the D7 site

      Considering the use of taxonomy for metatags, I could probably discount metatags in defining if the migration was any useful.

  4. Images (Each blog post has an image attached to it on an image field). Also, each blog post has a large number of images embedded in the markup (Usually pasted into the WYSIWIG and retrieved automatically by Drupal 7 using https://www.drupal.org/project/get_image module)

  5. URL Aliases / Clean Urls

As such these would be the items I would care about in the migration and see how Drupal 8 at its current state, using the migrate_upgrade path of migration has fared on these items - Content, Term References, Images, Url Aliases

Content

Was well-migrated. Content types were auto-created on D8 by migration. All nodes were migrated without skipping any. Most of the field and content type display configuration was replicated on the D8 site.

References

Looks good. There was only one vocabulary. It was replicated on D8 and all terms were auto-migrated.

Images

The Image field was created on the D8 content type automatically by Drupal

The files were fetched and copied from the source site into the D8 sites/default/files folder

An entry was created for each file in the D8 site files table and these files can be managed from “admin/content/files” on the D8 site.

But the images were NOT attached by the migration to the relevant nodes

Clean Urls / Aliases

Migrated

NOTE: I am not referring to the pathauto settings. But the existing (generated) aliases for existing nodes were migrated.

Site Configuration

This was the item where I was surprised the most. Blocks, Block Configuration, Content type Configuration (Comments etc), Site-wide configuration (Image Styles) were migrated from the source D7 site to D8 without any effect.

Overall, the migration has surprised me. The only significant issue that stood out for me was that the images were not attached to the nodes. There were a couple of smaller issues that I could stumble upon - Like, some of the migrated image styles had the labels missing. I am pretty sure the issue with the image field attachments is logged somewhere on the Issue queue of core or migrate_upgrade module, wherever it fits best. I haven’t verified that. I will probably check that out later.

Thumbnail Image used on Listing - D7 to D8 - is courtesy of Drupalize.me

 

Dec 22 2015
Dec 22

I had a chance to experience a beta version of the upcoming D8 certification from Acquia. “D8 Foundation” - to be more precise. Thanks to the Learning Services team at Acquia for allowing me to take the exam pre-release.

 

The score is not something I can be proud of. Although it was way higher than what I was expecting it to be. The exam blue print is not published yet. Prior to the exam, I had a chance to look at a draft of the blue print. It isn’t much detailed yet, like the blueprint we have for the Acquia Certified Developer exam. So, it wasn’t much of a help for preparing for the certification.

 

My exposure to D8 has been limited so far. I had ported a couple of modules (simple_fb_connect and FBIP). Built a couple of very small POCs / pet projects on D8 earlier.

 

Like the earlier ones, the exam had questions across all the 3 categories - Site Building, Theming and Module Development.

 

If you are someone who has cleared the Acquia Certified Developer Certification exam, and just diving into Drupal, you will find this exam easy to clear with basic understanding of OOP and Drupal 8.

 

Site Building:

This is the section where Drupal 8 is most similar to Drupal 7. That makes it a very easy section to score even to those who are brand new to Drupal. A few things have changed from D7 to D8 in terms of site building. If you are already a pro in D7 site building,  Chris Shattuck’s Upgrading to Drupal 8 video course (About 1h) will help you bridge the small gap that exists between D7 and D8 site building.

 

Some significant changes in this section between D7 and D8 that you might want to take a loot at would include:

 

Views in core in D8 remains very identical to D7 views. Questions on views would be an easy win if you are familiar with D7 views.

 

Module Development:

Module Development definitely has changed a lot from D7 to D8. Although not as much as Theming. Assuming you are already a D7 Module developer, I am trying to jot down below a few items that I believe will help D8 module development better and score in this section.

 

While that might suffice for the test, I would also recommend going through all the chapters of the book Building Drupal 8 Modules by Thomas Howell.

 

Theming:

Theming is definitely a section that has seen the largest change between D7 and D8.

 

Read about Twig in D8.

 

A good place to start would be Comparison of PHPTemplate and Twig theming paradigms. Adding regions to themes, Adding assets,  the Classy theme, Creating sub-themes are some more items that you could check further on.

 

That should cover just enough to have you covered for the “Foundation” exam. Although I would recommend reading further and taking a deeper dive into D8 theming as below.

 

The D8 theming guide on drupal.org is a good read, covering the below sections.

 

The exam should be an easy one to crack. Leverage the fact that D8 has lot of stuff common to D7, especially in Site Building. That could save your ass. It saved mine.  

 

The exam is expected to be publicly available by Jan 15th 2016.


If you are brand new to D8, consider developing a small hello world module and a basic theme from scratch in D8 before you consider taking up the exam. All the very best!!

 

Nov 19 2015
Nov 19

Drupal Art has always been special for me. Here was today’s work to celebrate the release of D8 Bahubali style. Bahubali is definitely one of the greatest movies Indian cinema has produced so far. If you haven’t had a chance to watch it yet, you should definitely consider doing it. The movie is available on Google Play Store with English Subtitles!

Nov 17 2015
Nov 17

Was trying out D8 and while “Managing Display” of a content type, noticed a new option while choosing the visibility of the label of a field.

 

 

Was wondering how they are different. Apparently when “Visually Hidden” is selected, the label is still there in the markup but not visible on browsers/screen, allowing screenreaders to be able to readout the label of the field!

 

Markup of the field label when set to “Visually Hidden”:

 

The motivation for this feature on d.o issue reads:

“As a site builder managing the display of a node, I want the option to hide field labels from sighted users, but make them visible to screenreaders, so I can make my site as accessible as possible without a custom theme.”

 

Had been hearing a lot about Drupal 8 accessibility features, but was pleasantly surprised to see this on my first brush with D8. Way to go Drupal! Can’t wait to see your new face in a couple of days!

 

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