In the last blog post, I started to talk about the process of upgrading the Viewport module from Drupal 7 to Drupal 8. While the module is now fully ported and has a stable version for Drupal 8, I didn’t cover all the steps and new things that I came across while working on it.
This time I’ll go through the notes I took while working on the settings page, the creation of a proper schema for configuration management, and the conversion of procedural code into PHP classes. Let’s get into it:
Image taken from Phase2 website
Viewport is one of the modules I maintain for Drupal 7. It’s a very small and simple module that does a very specific thing: it allows site admins to specify the values they want for the HTML meta tag that specifies the viewport settings for browsers. It also allows admins to choose the pages in which they want this custom viewport applied.
Back in the day a client required this functionality to embed some browser games that required very specific settings. Nowadays it’s not really common for a site admin to set those values, and developers don’t really require any UI to set them.
A few weeks ago, I wrote a blog post about what the first quarter of 2015 had been like. That was, in a way, to track my progress on the different projects and objectives I had set out to complete during the year. It was also a way to remind myself that I should keep working on them, and structure a bit better the time spent on each one. However, I wasn’t completely honest when writing up that list. And when I say completely honest, I’d like to stress the first part of it.
Yes, that’s right: completely. Of course there wasn’t a single dishonest bit on that blog post, but it’s fair to say that the list of objectives wasn’t 100% complete. I deliberately left out an important one: I wanted to speak at a conference, too. But that list was meant to cover the second quarter of 2015, and I wasn’t confident enough that with all the other things I wanted to do, I could also prepare a presentation for a software conference. I chose the easy thing: leaving it out the list wouldn’t require that I took action on it. Everyone knows that if you don’t write something down, you’re not commiting to it! Continue reading
A few weeks ago I wrote a blog post about Yeoman and the existing Yeoman generators for Drupal. As someone who loves and rants a lot about code generation, it was a tool that I had been wanting to try out for quite some time, and the experience after having spent a couple of hours with the tool, figuring out which generators could be useful for me, was rather satisfactory.
Now, beyond having some generators that I can benefit from, my interest in Yeoman was mostly in the APIish side of it. In other words, I wanted to see how easy it is to create my own generators for whatever tasks I find myself repeating a lot. The best way to find that out is, of course, to try and write a generator plugin for it, facing the usual challenges of being a total newcomer to a language or a framework. One of the most common pieces of code I have to write in my projects, are ctools plugins, in particular, Content Type plugins, so I decided to write a generator for just those type of plugins. This post will explain the basics of the tool and how to create a basic generator. If you want to get the most out of it, I’d recommend you to open your IDE or text editor of choice, and follow along, so that you can experiment with Yeoman at the same time.
One more year, DrupalCamp Spain is getting closer and closer. This year, it’ll take place in Jerez de la Frontera, and it’ll be during the second half of May (22nd, 23rd and 24th of May, to be precise). Last year’s camp in Valencia was a bit of a miss for me, as I had some troubles with the schedule, and could only attend to a couple of sessions, so I’m more excited this time, given that it’s been a while (2 years, I could say!) since my last DrupalCamp. And it’s always a great pleasure to meet and talk to friend made on previous camps, as well as new people of the Spanish community. Continue reading
“Probatura” (Spanish word): Test, trial, experiment.
If you’re a web developer, chances are that you’ve come across Emmet before. If you haven’t, chances are that you’re wasting time whenever you get to write some html in your favorite code editor or IDE. You should really check it out and see the options on the project page, but let me show you a quick example of how Emmet can help you. Let’s say you’re prototyping a simple page and know the markup you need. It would look like this:
Easy, right? Because you’re a cool front-ender with great and fancy text editors like Sublime or Atom, and fancy features like tag autocompletion, attribute suggestions, etc… surely just a few seconds to write. For you too, phpstorm guy, because nobody beats your all-terrain IDE, capable of even preparing pop-corn for you while you’re churning out the most beautiful PHP lines ever written with, you know… a real programming tool. Not to mention the vim players out there. You really are on another level of the game. HTML ain’t nothing for you, is it? Well, whatever built-in support you have for writing html, Emmet’s going to be better. Continue reading
One of the major disadvantages of entities in Drupal 7, is the lack of support for built-in comments. This is due to the model of the core comments module, which is heavily tied to nodes -node comments are essentially settings of each content type-, and not available for other entity types. In Drupal 8 this has changed already, and comments are considered fields that can be attached to any entity type.
For Drupal 7, in the meantime, there’s been a similar solution for a while, which is the reply module. The reply module leverages the Entity API to define a “reply” entity type, and offers a UI to create “reply” bundles. Then, via the Field API, you can add a “Reply” field to any entity type, choosing the reply bundle that should be used by that particular field. The flexibility that gives is huge, since it means that you’re not restricted to just a comment type for your application. Continue reading
I’ve been recently involved in a Symfony project where the login process had to support 2-factor authentication with Yubikeys for certain users of the application. This post describes the steps that I followed to implement this feature in Symfony.
Before diving into the details and code snippets, I’ll describe the two main requirements of the task:
- Not every user in the system has a Yubikey, so 2-factor authentication (2FA) is not enforced sitewide.
- The fact that a user has a Yubikey and is required to authenticate with it, is private information, which means a partial authentication has to be performed before asking the user to perform the Yubikey authentication.
- Basic authentication is already implemented in the application against an LDAP instance, via the IMAG LdapBundle.
2014 wasn’t a bad year. I could say it was a reasonably ok year for me in some aspects, althought I didn’t make, by any means, as much progress as I wanted in many of my side projects. To say that I got a bit stagnated would be in fact to say too much, though, because while I didn’t progress as much as wanted in some things, I did progress on other things not initially planned.
That raised for me an obvious thing (or two) to address as soon as possible: planning and focus. Planning, so that I have a clear path to follow in order to achieve what I want to achieve, and by the time I want to get it done. Focus, so that I can successfully push out of my plate anything that is not related to the things I want to do or the things I want to learn. Or, seeing it from a different perspective, so that I can avoid one of the endemic ills most software developers out there suffer: (not) finishing things. While I don’t consider myself a non-finisher, I truly believe I can become a much better finisher. Continue reading