Pluralizing and singularizing words got very easy with the inclusion of the Doctrine Inflector class in Drupal 8 core.
The task at hand here is to allow the client to create a classed wrapper around multiple elements using CKEditor in Drupal 8.
The fundamental problem here is the CKEditor's built in "Styles" dropdown classes each
<p> individually, while we need a class wrapping them.
You could probably make or install your own CKEditor plugin, but that's not what I did.
Client has a bunch of static landing pages that are mobile-friendly and need to remain that way.
But what is to be done about srcset? Read on, oh reader, for the solution.
First, I created a gulp build task which makes a bunch of different sizes.
Install dependencies like this:
npm install -D gulp-load-plugins gulp-responsive sharp
The task looks like this:
There're a lot of really complicated descriptions of srcset out there.
As a result, I thought srcset was more complicated than it actually is.
Here's the all-purpose srcset code I used in my static HTML. This covers 1x, 1.5x, 2x, and mobile optimization in a fine-grained way:
You never know when you're going to encounter data ravaged by clients, cast aside and mauled, an antelope passed by lions to jackals.
But fortunately, data is much easier to repair than a gaping wound.
Here's the SQL query I'd use to replace non-breaking spaces with regular spaces. You'll need to replace it with whatever your search term is:
Here's the controlling issue for adding timezone support to Drupal core. As of now, August 1st, 2017, it doesn't appear to be ready.
Instead, I just added a timezone field to the node using the Timezone module, then appended it to the date range on field preprocess.
This won't work for you if you have multiple dates on an entity with different timezones (you might want to try the patch linked above), but it will fit most use cases.
Over the last several days, I've railed in my head against the matroshka structure of Drupal entities. But when I tried to break out some helper functions, and when I realized what each of the different properties each entity had, I realized the complexities of entities were warranted. Life is complex, and thus Drupal is complex.
Entity references load a Media Entity, which load an Image from an image field, which load a File. The alt and title are on the Image, while the file URI is on the file.
This is pretty simple, but it took me a minute, because I kept trying to use the base
Entity class, like an angry baby trying to remove a clenched fist from a bottle.
This function gets all the Media ID's from the database whose names begins with a specific string. I'm using this for an array of default images.
It can take a minute to figure out what method to use to get the file URL from the file URI.
Here's what I did:
Zebras. (I just wanted to use my "z" illumination.)
In general, it's not necessary to add a timezone to both start and end dates. But if you modify the date format, that's exactly what will happen.
So how do we add the site timezone just to the end of the DateTimeRange?
Here's how I did this:
Another day learning Drupal 8, but today is troubling.
Here's where I'm at. I'm theming search results, and I need to load field values to pass to twig templates—specifically a styled url for img
Entities values are not loaded on search results, only little snippets, so I have to load them the hard way, because we want images and nice theming on our search results.
Well, that's because you can't. For whatever reason.
I can't modify the variables in
search-result.html.twig like so:
Sometimes, I've had a rule that fails continually, because data on it is bad.
Maybe it was created in development, maybe it's just gone rogue—data with a broken-off arrowhead lodged in its side, tearing through trees until, foam crusting its lips, it lays down to die.
Quite the problem—Drupal config management on local and prod.
Drupal 8 can be punctilious: it will simply refuse to work if there's a mismatch between database and config objects on the filesystem.
So... how do we manage two sets of configurations—one for local, and one for production?
I have modules like varnish installed on production that shouldn't be enabled on local, and modules that are enabled on local that shouldn't be enabled on production.