Does using drush uli in D8 and getting http://default drive you mad?
In Drupal 8, setting your sites domain in settings.php
is no longer possible. In Drupal 7, you could set the base_url
in settings.php
like:
In Drupal 8, setting your sites domain in settings.php
is no longer possible. In Drupal 7, you could set the base_url
in settings.php
like:
Working with external APIs in Drupal has always been possible. Using PHP’s curl
function or drupal_http_request is simple enough, but in Drupal 8 you can build in a lot more flexibility using Drupal::httpClient.
TL;DR: Just here for Browsersync setup? Skip to the steps.
I’m always looking for ways to reduce the time between saving a file and seeing changes on the screen.
When I first started working with Drupal, back in the day, I would ftp changes to a server and refresh the page. Once I found Transmit, I could mount a remote directory locally and automatically save files to the server. At the time, my mind was blown by the efficiency of it. In hindsight, it seems so archaic.
Custom styled form elements are a common thing to see in a design. That’s because default form styles vary visually from browser to browser and OS to OS. It makes sense that we’d want these elements styled consistently. Styling them is pretty straightforward, with the exception of select
dropdowns which can be more complex. Recently, I ran into an unexpected problem when working on a site that needed a branded admin experience.
Quite a bit has changed for the Migrate module in Drupal 8: the primary module is part of core and some of the tools have been split into their own modules. Recently, we migrated a Wordpress site into Drupal 8 and this article will help guide you in that process. If you’re looking for information about Wordpress to Drupal 7 migrations, check out Joel Steidl’s article on that here.
"If you're not testing, you're doing it wrong." I can't remember how many times I've heard those words. Each time, I'd feel a little pang of guilt, a little bit of shame that every day, I wrote code for myself and clients that wasn't tested. I'd be frustrated with the developers who repeated that mantra. Sure, it was easy to say, but hard to live up to. How do I test? What do I test? Should I test? How would I justify the costs?
Testing is a part of every developer’s job. Good tests ensure code we write does what we expect. In Javascript, we have many tools at our disposal, such as the excellent developer panels in Chrome and Firefox.
Nearly a year ago, I wrote a blog called "Drupal Permissions Done Right". I received a lot of excellent feedback and at the end of it I promised to release a module which would make managing permissions in Drupal 8 more sane based on the principles the post outlined. Today, I'd like to announce that module and explain a little bit about it.
For many Drupal web sites setting permissions for anonymous, authenticated, and admin users through the GUI is sufficient. For example, all published content should be visible to all users, authenticated users can leave comments, and admin users are allowed to create content.
As a programmer, I spend almost all my time hanging out with code. This code may be my own, other co-workers’, or code from an open source project. And I may be contributing this code at different points in that project's lifecycle: starting out, initial development, maintenance, debugging, adding new features, etc. Given the amount of time I have been working on various projects as a programmer, I spend more time – and place more value on – considerations around the ability for anyone to step into this code and maintain it, debug it, or refactor it.