I've been hiding, it seems, underground, for the past 4 years. What happened? Well, it doesn't matter that much I guess. Let's just say that I worked on 2 big Drupal migration projects and there was not a lot of time and energy left to work on my stuff. Maybe this was related to the pandemic aftermath - crazy times - during which Web development tech kept moving at its usual crazy pace. Today, Pantheon.io is a thing of the past, my clients that were using it moved on to other things, and so I did; same with Lando which had replaced MAMP. Time never stays still. Heraclitus, the ancient Greek philosopher, once famously proclaimed, “There is nothing permanent except change.”

I'm enjoying a bit of time off after a 27 month stint at MLL, I decided that I would resolve all the technical issues and blockers that stand in the way of me writing about the stuff I'm interested in - that also changes all the time, like a river.

The following is an attempt to document (that's a big word) my intentions and the processes that finally got the better of those blockers and cancelled my technical debt.

Main Components

• Ddev is Drupal's local web development platform of choice, going with the flow here has its advantages, no good reasons not to;
• GitLab for version control, CI/CD, project management and collaboration; I've never got around using it for my personal projects, the time has come;
• cPanel for hosting small web projects; the tech stack has been around forever, is flexible, affordable and ubiquitous; let's make it work; I just need to figure out its Git deployment workflow;

DDEV - The only trick here was to first replicate the production environment in order to import a prod database:

• ddev config --project-type=drupal8 --docroot=web --create-docroot --php-version=7.4
• ddev composer create "drupal/recommended-project:8.9.20" --no-install
• ddev composer require drush/drush
• ddev composer install
• ddev start

GITLAB - That's the easy part, no need to go into details here. But if you're looking for a quick tutorial, this one will do just fine.

CPANEL - That was my biggest black box, devops is not really my thing. I found some helpful and also some slightly misleading information; sifting through the good and the bad (relative to my context) is never easy, especially when I'm outside my comfort/knowledge zone. This video and the cPanel doc helped me figure out how to create and connect to my private GitLab repo. But my initial deploy script (.cpanel.yml), was somewhat messy. And then I got some help from claude.ai. Trial and error is also a good friend. Between the two of them I managed to refine the script that made it possible to deploy a Drupal website running in a sub-directory (web). I did this as I was going through the 252 core releases that separate 8.9.20 from 11.1.6. And, yes, I obviously went through Composer dependency hell a few times.

After all this, my personal website is now happily purring on the latest Drupal release. Now that my technical debt is zero, I can freely ponder on what I might write that would be interesting…

The idea of creating a temporary Under Construction home page made me smile because it reminded me of the ubiquitous nature of these pages when the Web was just starting out in the early '90. Under Construction pages were of course everywhere. So I thought it would fun to try to replicate some of that esthetic and indulge in a little Electronic Frontier nostalgia. Anyway, in case you're curious, that's where the black & yellow stripes come from.

In the end and after a day's work I'm pretty happy with the result. Especially because it's all done in the Wysiwyg of a basic field - in the spirit of those long gone days when we created entire websites using raw HTML -- sorry, no custom Twig template here. You can see it all if you inspect the source of the page.

For example, the black & yellow stripes are empty DIVs with classes, the CSS is injected thanks to Asset Injector, same for the radial striping separator. The layout is of course responsive thanks to a few more DIVs and Bootstrap.

I have to admit that initially I was planning to create a custom content type with a dedicated Twig template. But I soon realized this was cumbersome and that I could more playfully achieve my objectives using the Basic Page content type and a bit of HTML coding.

Which raises the question: are we not too often conditioned to create according to rigid standards and best practices to the detriment of simpler, out-of-the-box and perfectly acceptable solutions?

This is a follow-up to: Vue.js and Decoupling Drupal » Update from Vue 1.x

The initial setup is from One Page App With Drupal 8 and Vue.js:

• Vue.js 1.0.11
• vue-resource.js v0.1.17
• vue-router v0.7.7
• app.js is where all the code is

Now trying to manually update the Vue.js app to:

• Vue.js v2.6.12
• vue-resource v1.5.1
• vue-router v2.8.1

Of course, after applying these updates nothing works anymore. I need to find out what has changed since 2016, here's an incomplete list.

• The Vue coding standards have evolved quite a bit since then.
• Fortunately the Vue docs are quite helpful: Migration from Vue 1.x
  • ready replaced by mounted
  • Computed properties new
  • Replacing the filterBy Filter
  • etc.

In the end it was a slow process, a long series of small steps (iterations) that allowed me to update the code as well as the knowledge I had acquired the first time around. In time, I was able to display and filter the movies just like in the original 1.x app.

But I eventually put an end to this re-make when I realized that updating the implementation of the routing was going to be quite difficult because of the manual install. There is no point in trying to fix the code, it makes more sense to do this in the next step: Update to Vue 2.x, keep RESTful Web Services but do a proper Vue install.

For now, you can still see the Vue.js 1.x app here. Note that it's sometime a bit slow to load because the API runs on a dev server that quickly falls asleep.

To be continued…

Back in the February 2019 I started experimenting with decoupled Drupal and Vue.js. After a basic search I then decided to tag along with Ivan Dorić in One Page App With Drupal 8 and Vue.js. Although this 14 part series was already a bit dated (2016) I liked Ivan's casual tone and his user friendly approach which uses Drupal core's RESTful Web Services to create the API.

Fast-forward to today (09-2020), Vue.js 2.x has been out since 09-2016, Vue 3.x was released last month (09-2020) and JSON:API was committed to Drupal core on 03-2019 (drupal 8.7.0-beta1). Time to catch up.

After some quick thinking, I decide to update to Vue 2.x which I assume to be more stable and, more importantly, for which there's likely a lot more documentation available. Nothing wrong with making my life easier.

In his series, Ivan cuts to the chase - which I liked - and manually installed vue.js, vue-resource.js and router.js. Here's my plan going forward.

1. Update to Vue 2.x, keep RESTful Web Services (manual Vue install)
2. Update to Vue 2.x, keep RESTful Web Services but do a proper Vue install
3. Update to 2.x and JSON:API

For now, you can still see the Vue.js 1.x app here. Note that it's sometime a bit slow to load because the API runs on a dev server that quickly falls asleep.

Last steps:

• transpose the re-rewriting I attempted to do in Views' fields into a new node--review--teaser.tpl.php
• update theme_preprocess_node() in template.php to add theme hook suggestion for the Teaser view mode; otherwise node--review.tpl.php is always used
  • stackexchange.com/a/152220/12860

That's it. This is a good example where view modes make your life easier.

After deploying this home-made Star Rating system, the client had only this to say: «Looks perfect!»

Initial solution to display the star rating is based on a w3schools.com How To:

• in the Review node, create field_review_rating of type Integer and add the star options
• the custom HTML markup for this field is provided by theme_preprocess_field() in template.php
• create/add field--field-review-rating.tpl.php to the theme's template folder and use the custom HTML markup to override its display
• Font Awesome Icon Library is loaded in html.tpl.php
• add the CSS to color the stars in the theme's CSS folder

This works fine when a node is displayed. But what about a list of reviews produced by Views?

How can I reproduce the node's custom display in a Views' display? It's definitely possible but it quickly gets more complicated. It also means that our system will have 2 templates to handle these 2 separate contexts, duplication is rarely ideal and often leads to more work and errors...

AH! a better solution would be to use a content view mode e.g. Teaser instead of fields, that way there is no need to work with Views' templates + the work done in field--field-review-rating.tpl.php 100% recyclable :)

One of my clients needs a star rating system for his product reviews. There is an old module for that: FiveStar. And that's fine because he's still running Drupal 7. But he has expressed ambitions to migrate to Drupal 8 and the latest version of FiveStar for Drupal 8 is still in alpha.

The easy solution would be not to worry and install one more module on his website. But wait a minute, in the module admin page Module Filter says: «311 of 593». Yikes! Also, FiveStar was created 14 years ago for solving a specific use case: letting members of a community rate content while browsing a website (i.e. when content is displayed in Default/Full content view mode).

In the present use case, a customer is invited to edit a node linked to the product he recently purchased. That's a much simpler use case, one that does not require a very sophisticated UI, in a node edit form, a simple select with options 1 to 5 stars will do just fine. Where we want this system to shine is in how it displays the rating, not in how it lets users set the rating.

Finally, if a simple and static home-made system can be produced then migrating it to Drupal 8 will be trivial.

Blaire, a Digital Communications VP, reaches out to me for help in creating 80 pages of content in a soon to be launched Drupal 8 multilingual corporate website.

The first challenge is that these pages need to be created on an island of sort i.e. in an environment which is completely separate from the main contractor's environment - «in fact without them knowing about it would be best for a while...».

The second challenge is where it gets… exponentially? complicated: most of the multilingual nodes' content resides in nested Paragraphs, three (3) levels deep, that's a lot of referenced entities.

NODE
- Title
- field_paragraphs_level_1
	- field_padding
	- field_container_size
	- field_paragraphs_level_2
		- field_padding
		- field_title
		- field_paragraphs_level_3
			- field_padding
			- field_wysiwyg_content

The closest I go to this was 5 years ago when I used Feeds to import 1000 products into a Drupal Commerce 1.x store. The way to do this is to first import/create the referenced entities (product variations) before importing the host entities (product display nodes). To be clear, that's equivalent to just 1 level of nesting.

Although I have successfully used Feeds for importing flat content (no nesting) into Drupal 8 websites I'm a little weary about the multilingual nested Paragraphs. Also, the content is not yet final and the client wants to be able to update it in Google Sheets.

A few months before, I spent quite a bit of time learning about Drupal's Migration API by going through the excellent series 31 Days of Drupal Migrations written by Mauricio Dinarte. This series gave me the confidence I needed to get started with a simple Paragraphs migration and work my way into Migration API deep dive.

To be continued…

A client of mine needs a one-page Drupal website for selling a unique product. We quickly agree on a simple formula whereby he can build individual slices and stack them. This is quite a common design, lots of websites are built that way.

Ok so what's the best way to do this? The most common answer to this is: Paragraphs. And here's what we're looking for.

+=================================+==================================|
|           Left Column           |           Right Column           |
+=================================+==================================|
|                      FULL WIDTH HEADER BANNER                      |
+---------------------------------+----------------------------------|
|             [image]             |         Insert text here         |
+---------------------------------+----------------------------------|
|         Insert text here        |             [image]              |
+---------------------------------+----------------------------------|
|             [image]             |         Insert text here         |
+---------------------------------+----------------------------------|

You get the picture… Now here's the question: how many Paragraph types do you think we need to create this 2-column layout?

To be continued…