Reconsolidate images, update paths
|
@ -13,12 +13,12 @@ availability:
|
|||
full: no
|
||||
|
||||
avatar:
|
||||
url: /dist/images/me-precedent.jpg
|
||||
url: /images/me-precedent.jpg
|
||||
|
||||
email: oliver+url@oliverdavies.uk
|
||||
|
||||
favicon:
|
||||
url: /dist/images/me-phpnw.png
|
||||
url: /images/me-phpnw.png
|
||||
|
||||
irc:
|
||||
name: opdavies
|
||||
|
|
|
@ -1,26 +1,26 @@
|
|||
<div class="flex items-center md:block text-center">
|
||||
<div class="widget w-1/2 md:w-full">
|
||||
<a href="https://assoc.drupal.org/membership" title="I’m a Drupal Association member." class="block mb-4 px-4 md:px-0 lg:w-3/4 lg:mx-auto">
|
||||
<img src="{{ site.images_url }}/dist/images/badges/da-individual-member.png" alt="Drupal Association Individual Member"/>
|
||||
<img src="{{ site.images_url }}/images/badges/da-individual-member.png" alt="Drupal Association Individual Member"/>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
<div class="widget w-1/2 md:w-full">
|
||||
<div class="mb-4 flex flex-wrap">
|
||||
<div class="w-full lg:w-1/2 leading-none px-4 md:px-0">
|
||||
<img src="{{ site.images_url }}/dist/images/badges/acquia-d8-grand-master.png" alt="Acquia Certified Grand Master - Drupal 8 Exam Badge" />
|
||||
<img src="{{ site.images_url }}/images/badges/acquia-d8-grand-master.png" alt="Acquia Certified Grand Master - Drupal 8 Exam Badge" />
|
||||
</div>
|
||||
|
||||
<div class="w-full lg:w-1/2 leading-none px-4 md:px-0 hidden lg:block">
|
||||
<img src="{{ site.images_url }}/dist/images/badges/acquia-d8-developer.png" alt="Acquia Certified Developer - Drupal 8 Exam Badge" />
|
||||
<img src="{{ site.images_url }}/images/badges/acquia-d8-developer.png" alt="Acquia Certified Developer - Drupal 8 Exam Badge" />
|
||||
</div>
|
||||
|
||||
<div class="w-full lg:w-1/2 leading-none px-4 md:px-0 hidden lg:block">
|
||||
<img src="{{ site.images_url }}/dist/images/badges/acquia-d8-back-end.png" alt="Acquia Certified Back End Specialist - Drupal 8 Exam Badge" />
|
||||
<img src="{{ site.images_url }}/images/badges/acquia-d8-back-end.png" alt="Acquia Certified Back End Specialist - Drupal 8 Exam Badge" />
|
||||
</div>
|
||||
|
||||
<div class="w-full lg:w-1/2 leading-none px-4 md:px-0 hidden lg:block">
|
||||
<img src="{{ site.images_url }}/dist/images/badges/acquia-d8-front-end.png" alt="Acquia Certified Front End Specialist - Drupal 8 Exam Badge" />
|
||||
<img src="{{ site.images_url }}/images/badges/acquia-d8-front-end.png" alt="Acquia Certified Front End Specialist - Drupal 8 Exam Badge" />
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<a href="{{ url }}">
|
||||
<img
|
||||
class="h-16"
|
||||
src="/dist/images/meetups/{{ logo }}"
|
||||
src="/images/meetups/{{ logo }}"
|
||||
title="{{ name }}"
|
||||
alt="{{ name }} logo"
|
||||
>
|
||||
|
|
|
@ -21,7 +21,7 @@ Logging in to the Stripe account, I was able to confirm that the specified custo
|
|||
|
||||
After some investigation, I found a table in the database named `user__commerce_remote_id` which stores the remote customer ID for each payment method (again, the customer ID has been redacted).
|
||||
|
||||
![A screenshot of a row in the user__commerce_remote_id table](/assets/images/blog/commerce-stripe-error/remote-id-table.png){.border.p-1}
|
||||
![A screenshot of a row in the user__commerce_remote_id table](/images/blog/commerce-stripe-error/remote-id-table.png){.border.p-1}
|
||||
|
||||
The `entity_id` and `revision_id` values in this case refer to the user that the Stripe customer has been associated with.
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@ A system user isn’t an account that we’d expect a person to log in with and
|
|||
|
||||
System User module adds a base field to Drupal’s User entity, which determines whether or not each user is a system user - i.e. if this field is `TRUE`, that user is a system user. This means that users can easily be queried to identify which are system users, without having to rely on magic, environment and site specific user IDs. This also means that we can have multiple system users, if needed.
|
||||
|
||||
![](/assets/images/blog/null-users-system-users/drupal-8-users-field-data-table.png){.border .p-1}
|
||||
![](/images/blog/null-users-system-users/drupal-8-users-field-data-table.png){.border .p-1}
|
||||
|
||||
In the Drupal 8 version of the module, a `SystemUser` is a custom entity, that contains it’s own `create` method for creating new system users. This is a essentially a wrapper around `User::create()` that automatically sets the value of the system user field as part of the creation.
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ I’ve been experimenting with moving some of the code to Drupal 8, and I’m qu
|
|||
{% block content %}
|
||||
Here is how this module is currently structured:
|
||||
|
||||
![](/assets/images/blog/events-drupal-8/1.png){.border .p-1}
|
||||
![](/images/blog/events-drupal-8/1.png){.border .p-1}
|
||||
|
||||
Note that there is no `opdavies_blog.module` file, and rather than calling actions from within a hook like `opdavies_blog_entity_update()`, each action becomes it’s own event subscriber class.
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ Here is the original tweet and my initial response. I also have a lot of PhpStor
|
|||
|
||||
On the PhpStorm welcome screen that displays when you first open it, your recent projects are displayed on the left-hand side of the screen, and are filterable. That means that I can start typing a project name, e.g. `oli`, and I will only see projects that start with that input.
|
||||
|
||||
![The PhpStorm welcome screen with filters applied to the project list](/assets/images/blog/quick-project-switching-phpstorm/welcome-screen.png){.with-border .with-padding}
|
||||
![The PhpStorm welcome screen with filters applied to the project list](/images/blog/quick-project-switching-phpstorm/welcome-screen.png){.with-border .with-padding}
|
||||
|
||||
That’s great when opening a project from scratch, but what about when we’re already within a project and just want to be able to switch to another?
|
||||
|
||||
|
@ -29,19 +29,19 @@ There’s also a way to access this list once PhpStorm is open, by clicking 'Ope
|
|||
|
||||
You can also access this list using the keyboard, though the 'Search everywhere' or 'Find action' panes, and these are filterable.
|
||||
|
||||
![Using the 'find action' pane to find 'Open Recent'](/assets/images/blog/quick-project-switching-phpstorm/find-action.png){.with-border .with-padding}
|
||||
![Using the 'find action' pane to find 'Open Recent'](/images/blog/quick-project-switching-phpstorm/find-action.png){.with-border .with-padding}
|
||||
|
||||
Once the 'Open Recent' option is selected, you see the same project list as on the welcome screen, which is filtered in the same way by starting to type potential project names.
|
||||
|
||||
![The filtered project list](/assets/images/blog/quick-project-switching-phpstorm/open-recent.png){.with-border .with-padding}
|
||||
![The filtered project list](/images/blog/quick-project-switching-phpstorm/open-recent.png){.with-border .with-padding}
|
||||
|
||||
## Adding a Keyboard Shortcut
|
||||
|
||||
We can make this easier by adding a new keyboard shortcut. Within the Keymap preferences, you can search for 'Open Recent' and right-click it to add a new keyboard shortcut and define the key combination.
|
||||
|
||||
![Finding the 'Open Recent' shortcut in the Keymap preferences](/assets/images/blog/quick-project-switching-phpstorm/adding-keyboard-shortcut-1.png){.with-border .with-padding}
|
||||
![Finding the 'Open Recent' shortcut in the Keymap preferences](/images/blog/quick-project-switching-phpstorm/adding-keyboard-shortcut-1.png){.with-border .with-padding}
|
||||
|
||||
![Assigning a keyboard shortcut](/assets/images/blog/quick-project-switching-phpstorm/adding-keyboard-shortcut-2.png){.with-border .with-padding}
|
||||
![Assigning a keyboard shortcut](/images/blog/quick-project-switching-phpstorm/adding-keyboard-shortcut-2.png){.with-border .with-padding}
|
||||
|
||||
This this shortcut added, you can now use it to instantly bring up your recent projects list, filter it and switch project.
|
||||
{% endblock %}
|
||||
|
|
|
@ -14,7 +14,7 @@ For the past few weeks I’ve been working on a personal side project, based on
|
|||
{% endblock %}
|
||||
|
||||
{% block content %}
|
||||
![](/dist/images/blog/drupalvm-generate-repo.png)
|
||||
![](/images/blog/drupalvm-generate-repo.png)
|
||||
|
||||
## What is Drupal VM?
|
||||
|
||||
|
@ -38,7 +38,7 @@ Based on the options passed to it and/or answers that you provide, it generates
|
|||
|
||||
Here’s an example of it in action:
|
||||
|
||||
!['An animated gif showing the interaction process and the resulting config.yml file'](/dist/images/blog/drupalvm-generate-example-2.gif)
|
||||
!['An animated gif showing the interaction process and the resulting config.yml file'](/images/blog/drupalvm-generate-example-2.gif)
|
||||
|
||||
You can also define options when calling the command and skip any or all questions. Running the following would bypass all of the questions and create a new file with no interaction or additional steps.
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ As we don’t need any write access back to the repo, using the HTTP URL rather
|
|||
|
||||
Also, as I knew that I’d be working a lot with feature branches, I entered `*/master` as the only branch to build. This meant that pushing changes or making edits on any other branches would not trigger a build.
|
||||
|
||||
![Defining the Git repository in Jenkins](/dist/images/blog/oliverdavies-uk-jenkins-git-repo.png)
|
||||
![Defining the Git repository in Jenkins](/images/blog/oliverdavies-uk-jenkins-git-repo.png)
|
||||
|
||||
I also checked the **Poll SCM** option so that Jenkins would be routinely checking for updated code. This essentially uses the same syntax as cron, specifying minutes, hours etc. I entered `* * * * *` so that Jenkins would poll each minute, knowing that I could make this less frequent if needed.
|
||||
|
||||
|
@ -92,7 +92,7 @@ After originally thinking that I'd have to split the build steps into a separate
|
|||
|
||||
I set this to `@daily` (the same `H H * * *` - `H` is a Jenkins thing), so that the build would be triggered automatically each day without a commit, and deploy any updates to the site.
|
||||
|
||||
![Setting Jenkins to periodically build a new version of the site.](/dist/images/blog/oliverdavies-uk-jenkins-git-timer.png)
|
||||
![Setting Jenkins to periodically build a new version of the site.](/images/blog/oliverdavies-uk-jenkins-git-timer.png)
|
||||
|
||||
## Next Steps
|
||||
|
||||
|
|
|
@ -59,7 +59,7 @@ touch .docksal/commands/phpunit
|
|||
|
||||
This will create a new, empty `.docksal/commands/phpunit` file, and now the `phpunit` command is now listed under "Custom commands" when we run `fin`.
|
||||
|
||||
![](/dist/images/blog/docksal-phpunit-command/1.gif)
|
||||
![](/images/blog/docksal-phpunit-command/1.gif)
|
||||
|
||||
You can write commands with any interpreter. I’m going to use bash, so I’ll add the shebang to the top of the file.
|
||||
|
||||
|
@ -84,7 +84,7 @@ fin interprets lines starting with `##` as documentation - the first of which it
|
|||
|
||||
Now when I run it, I see the new description.
|
||||
|
||||
![](/dist/images/blog/docksal-phpunit-command/2.gif)
|
||||
![](/images/blog/docksal-phpunit-command/2.gif)
|
||||
|
||||
Any additional lines are used as help text with running `fin help phpunit`. Here I’ll add an example command to demonstrate how to run it as well as some more in-depth text about what the command will do.
|
||||
|
||||
|
@ -101,7 +101,7 @@ Any additional lines are used as help text with running `fin help phpunit`. Here
|
|||
|
||||
Now when I run `fin help phpunit`, I see the new help text.
|
||||
|
||||
![](/dist/images/blog/docksal-phpunit-command/3.gif)
|
||||
![](/images/blog/docksal-phpunit-command/3.gif)
|
||||
|
||||
## Adding some content
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ meta:
|
|||
description: 'It’s with heavy hearts that we are announcing there won’t be a DrupalCamp Bristol 2018.'
|
||||
type: website
|
||||
image:
|
||||
url: /dist/images/blog/drupalcamp-bristol-17-logo.jpg
|
||||
url: /images/blog/drupalcamp-bristol-17-logo.jpg
|
||||
width: 228
|
||||
height: 448
|
||||
type: image/img
|
||||
|
|
|
@ -17,7 +17,7 @@ meta:
|
|||
slug: drupalcamp-bristol-early-bird-tickets-sessions-sponsors
|
||||
---
|
||||
{% block excerpt %}
|
||||
<p class="text-center" markdown="1">![DrupalCamp Bristol 2017 logo](/dist/images/blog/drupalcamp-bristol-17-logo.jpg)</p>
|
||||
<p class="text-center" markdown="1">![DrupalCamp Bristol 2017 logo](/images/blog/drupalcamp-bristol-17-logo.jpg)</p>
|
||||
|
||||
In less than two months time, [DrupalCamp Bristol][0] will be back for our third year! (July seems to come around quicker each year). This is this year’s schedule and venues:
|
||||
{% endblock %}
|
||||
|
|
|
@ -32,7 +32,7 @@ This differs slightly different for each Drupal user, and the code can be found
|
|||
|
||||
If this is added to the end of the commit message, the resulting commit will show that it was committed by the maintainer but authored by a different user. This will then display on Drupal.org that you’ve made a commit to that project.
|
||||
|
||||
![A screenshot of a commit that was authored by rli but committed by opdavies](/dist/images/blog/git-format-patch.png)
|
||||
![A screenshot of a commit that was authored by rli but committed by opdavies](/images/blog/git-format-patch.png)
|
||||
|
||||
The problem is that some project maintainers either don’t know about this option or occasionally forget to add it. [Dreditor](http://dreditor.org) can suggest a commit message and assign an author, but it is optional and, of course, not all maintainers use Dreditor (although they probably should).
|
||||
|
||||
|
|
|
@ -6,7 +6,7 @@ tags:
|
|||
- php
|
||||
---
|
||||
{% block excerpt %}
|
||||
<p class="text-center" markdown="1">![](/dist/images/blog/drupal-meetups-twitterbot.png)</p>
|
||||
<p class="text-center" markdown="1">![](/images/blog/drupal-meetups-twitterbot.png)</p>
|
||||
|
||||
The [Drupal Meetups Twitterbot][0] is a small project that I worked on a few months ago, but hadn't got around to promoting yet. It’s intention is to provide [one Twitter account][1] where people can get the up to date news from various Drupal meetups.
|
||||
{% endblock %}
|
||||
|
|
|
@ -68,7 +68,7 @@ dependencies[] = system (>=7.36)
|
|||
|
||||
Because we need to check for Drupal's core version, we're using the system module as the dependency and specifying that it needs to be either equal to or greater than 7.36. If this dependency is not met, e.g. Drupal 7.35 is being used, then the module cannot be enabled rather than showing a function not found error for `user_has_role()` when it is called.
|
||||
|
||||
![A screenshot of the modules page showing System as a dependency for a custom module.](/dist/images/blog/minimum-drupal-version-d7.png)
|
||||
![A screenshot of the modules page showing System as a dependency for a custom module.](/images/blog/minimum-drupal-version-d7.png)
|
||||
|
||||
## External Links
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ return 301 https://www.example.com$uri$is_args$args;
|
|||
|
||||
Here is an demo of it working on this website:
|
||||
|
||||
![](/dist/images/blog/nginx-redirect-with-args.gif)
|
||||
![](/images/blog/nginx-redirect-with-args.gif)
|
||||
|
||||
## Resources
|
||||
|
||||
|
|
|
@ -6,13 +6,13 @@ meta:
|
|||
description: 'How I moved my Sculpin site to GitHub Pages.'
|
||||
og:
|
||||
image:
|
||||
url: '/dist/images/blog/jackson-octocat.png'
|
||||
url: '/images/blog/jackson-octocat.png'
|
||||
type: 'image/png'
|
||||
height: 200
|
||||
width: 451
|
||||
---
|
||||
{% block excerpt %}
|
||||
<p class="text-center" markdown="1">![](/dist/images/blog/jackson-octocat.png)</p>
|
||||
<p class="text-center" markdown="1">![](/images/blog/jackson-octocat.png)</p>
|
||||
|
||||
Earlier this week I moved this site from my personal Linode server to [GitHub Pages][0].
|
||||
|
||||
|
@ -25,7 +25,7 @@ I’ve seen different implementations of this, mostly where the Sculpin code is
|
|||
This has been made simpler and tidier now that we can use a `docs` directory within the repository to serve content.
|
||||
|
||||
<img
|
||||
src="/dist/images/blog/github-pages.png"
|
||||
src="/images/blog/github-pages.png"
|
||||
alt=""
|
||||
class="is-centered"
|
||||
style="margin-top: 20px; margin-bottom: 20px"
|
||||
|
|
|
@ -39,7 +39,7 @@ $queuer->queue($recipients, $message, $owner);
|
|||
|
||||
These three pieces of data are then saved as part of the queued item. You can see these by checking the "queue" table in the database or by running `drush queue-list`.
|
||||
|
||||
![](/dist/images/blog/private-message-queue.png)
|
||||
![](/images/blog/private-message-queue.png)
|
||||
|
||||
```
|
||||
$ drush queue-list
|
||||
|
|
|
@ -56,7 +56,7 @@ Now PhpStorm can connect to Docksal, I can configure it to do so by adding a new
|
|||
- Click 'Add' to configure a new deployment server.
|
||||
- Enter a name like 'Docksal', and select SFTP as the server type.
|
||||
|
||||
![Adding a new deployment server](/assets/images/blog/phpstorm-phpunit-docksal/deployment-1.png){.with-border .sm:max-w-sm}
|
||||
![Adding a new deployment server](/images/blog/phpstorm-phpunit-docksal/deployment-1.png){.with-border .sm:max-w-sm}
|
||||
|
||||
### Connection settings
|
||||
|
||||
|
@ -68,33 +68,33 @@ On the Connection tab:
|
|||
|
||||
You should now be able to click "Test SFTP connection" and get a successfully connected confirmation message.
|
||||
|
||||
![Configuring a new deployment server](/assets/images/blog/phpstorm-phpunit-docksal/deployment-2.png)
|
||||
![Configuring a new deployment server](/images/blog/phpstorm-phpunit-docksal/deployment-2.png)
|
||||
|
||||
### Mapping settings
|
||||
|
||||
On the Mappings tab, add `/var/www` as the deployment path so that PhpStorm is looking in the correct place for the project code.
|
||||
|
||||
![Add mappings to the deployment server](/assets/images/blog/phpstorm-phpunit-docksal/deployment-3.png){.with-border}
|
||||
![Add mappings to the deployment server](/images/blog/phpstorm-phpunit-docksal/deployment-3.png){.with-border}
|
||||
|
||||
## Configuring the PHP Interpreter
|
||||
|
||||
In Preferences, search for 'PHP' within 'Languages & Frameworks', and add a new CLI interpreter.
|
||||
|
||||
![The PHP preferences in PhpStorm](/assets/images/blog/phpstorm-phpunit-docksal/cli-interpreter-1.png){.with-border}
|
||||
![The PHP preferences in PhpStorm](/images/blog/phpstorm-phpunit-docksal/cli-interpreter-1.png){.with-border}
|
||||
|
||||
In this case I’ve called it 'Docksal PHP 7.1', used the Docksal deployment configuration, and set the path to the PHP executable to `/usr/local/bin/php` (the same path that we would get if we ran `fin run which php`). You should see both the deployment host URL displayed as well as the remote PHP version and configuration filenames.
|
||||
|
||||
![Configuring a new CLI interpreter](/assets/images/blog/phpstorm-phpunit-docksal/cli-interpreter-2.png){.with-border}
|
||||
![Configuring a new CLI interpreter](/images/blog/phpstorm-phpunit-docksal/cli-interpreter-2.png){.with-border}
|
||||
|
||||
This can now be selected as the CLI interpreter for this project.
|
||||
|
||||
![Selecting the new CLI interpreter in the PHP preferences](/assets/images/blog/phpstorm-phpunit-docksal/cli-interpreter-3.png){.with-border}
|
||||
![Selecting the new CLI interpreter in the PHP preferences](/images/blog/phpstorm-phpunit-docksal/cli-interpreter-3.png){.with-border}
|
||||
|
||||
## Set up PHPUnit in PhpStorm
|
||||
|
||||
In Preferences, search for 'Test Frameworks' and add a new framework.
|
||||
|
||||
![Adding a new test framework (PHPUnit) in PHPStorm](/assets/images/blog/phpstorm-phpunit-docksal/phpunit-1.png){.with-border}
|
||||
![Adding a new test framework (PHPUnit) in PHPStorm](/images/blog/phpstorm-phpunit-docksal/phpunit-1.png){.with-border}
|
||||
|
||||
Select 'PHPUnit by Remote Interpreter' and then the 'Docksal PHP 7.1' that we created in the last step.
|
||||
|
||||
|
@ -102,33 +102,33 @@ Select 'Use Composer autoloader' for the PHPUnit library setting so that PhpStor
|
|||
|
||||
Also specify the path to the default (phpunit.xml) configration file. This will depend on how your project is structured, in this case it’s at `/var/www/web/core/phpunit.xml`.
|
||||
|
||||
![Configuring PHPUnit in PHPstorm](/assets/images/blog/phpstorm-phpunit-docksal/phpunit-4.png){.with-border}
|
||||
![Configuring PHPUnit in PHPstorm](/images/blog/phpstorm-phpunit-docksal/phpunit-4.png){.with-border}
|
||||
|
||||
## Running tests
|
||||
|
||||
With PHPUnit configured, next to each test class and method, you can see a green circle (or a red one if the test failed the last run). You can click the circle and select to run that test class or method. You can also right-click directories in the project sidebar to run all of the tests within that directory.
|
||||
|
||||
![Running a test within PhpStorm](/assets/images/blog/phpstorm-phpunit-docksal/running-tests-1.png){.with-border}
|
||||
![Running a test within PhpStorm](/images/blog/phpstorm-phpunit-docksal/running-tests-1.png){.with-border}
|
||||
|
||||
When the tests start running, a new tool window will open that shows you all of the selected tests, how long each test took to run and whether it passed or failed. You can also see the CLI output from PHPUnit itself next to it.
|
||||
|
||||
![The tests results being displayed](/assets/images/blog/phpstorm-phpunit-docksal/running-tests-2.png){.with-border}
|
||||
![The tests results being displayed](/images/blog/phpstorm-phpunit-docksal/running-tests-2.png){.with-border}
|
||||
|
||||
From here, you also have the ability to re-run all of the tests, as well as a single test method or a specific test class.
|
||||
|
||||
Any test failures are shown here too, and for some failures like differences between two arrays you can use PhpStorm’s internal comparison tools to view the difference rather than needing to do so on the command line.
|
||||
|
||||
![Showing a failing test](/assets/images/blog/phpstorm-phpunit-docksal/test-failure-1.png){.with-border}
|
||||
![Showing a failing test](/images/blog/phpstorm-phpunit-docksal/test-failure-1.png){.with-border}
|
||||
|
||||
![Displaying the difference between two arrays](/assets/images/blog/phpstorm-phpunit-docksal/test-failure-2.png){.with-border .sm:max-w-md}
|
||||
![Displaying the difference between two arrays](/images/blog/phpstorm-phpunit-docksal/test-failure-2.png){.with-border .sm:max-w-md}
|
||||
|
||||
### Keyboard shortcuts
|
||||
|
||||
As per the video, I’ve also added some keyboard shortcuts to my keymap, so I can press ⌘T to run the current test method or class that I’m in, and ⇧⌘T to re-run the last test.
|
||||
|
||||
![Adding a keyboard shortcut to run the current test](/assets/images/blog/phpstorm-phpunit-docksal/keyboard-shortcuts-1.png){.with-border}
|
||||
![Adding a keyboard shortcut to run the current test](/images/blog/phpstorm-phpunit-docksal/keyboard-shortcuts-1.png){.with-border}
|
||||
|
||||
![Adding a keyboard shortcut to re-run the last test](/assets/images/blog/phpstorm-phpunit-docksal/keyboard-shortcuts-2.png){.with-border}
|
||||
![Adding a keyboard shortcut to re-run the last test](/images/blog/phpstorm-phpunit-docksal/keyboard-shortcuts-2.png){.with-border}
|
||||
|
||||
### Database issues
|
||||
|
||||
|
|
|
@ -113,7 +113,7 @@ In this case, the new branch will be `8.x-1.x`.
|
|||
|
||||
Here is a screenshot of example module that I’ve split and pushed to GitLab. Notice that there are multiple commits in the history, and each still attributed to it’s original author.
|
||||
|
||||
![Screenshot of a split project repo on GitLab](/dist/images/blog/subtree-split-drupal-module.png)
|
||||
![Screenshot of a split project repo on GitLab](/images/blog/subtree-split-drupal-module.png)
|
||||
|
||||
Also, as this is standard Git functionality, you can follow the same process to extract PHP libraries, Symfony bundles, WordPress plugins or anything else.
|
||||
{% endblock %}
|
||||
|
|
|
@ -10,13 +10,13 @@ meta:
|
|||
description: "How to write tests and follow TDD for Drupal applications."
|
||||
type: website
|
||||
image:
|
||||
url: /dist/images/talks/test-driven-drupal-development.png
|
||||
url: /images/talks/test-driven-drupal-development.png
|
||||
width: 2560
|
||||
height: 1440
|
||||
type: image/png
|
||||
---
|
||||
{% block excerpt %}
|
||||
<p class="text-center" markdown="1">![](/dist/images/blog/drupalcamp-dublin.jpg)</p>
|
||||
<p class="text-center" markdown="1">![](/images/blog/drupalcamp-dublin.jpg)</p>
|
||||
|
||||
I recently gave a [talk on automated testing in Drupal][0] talk at [DrupalCamp Dublin][1] and as a lunch and learn session for my colleagues at Microserve. As part of the talk, I gave an example of how to build a Drupal 8 module using a test driven approach. I’ve released the [module code on GitHub][2], and this post outlines the steps of the process.
|
||||
{% endblock %}
|
||||
|
@ -119,11 +119,11 @@ Now we can make it pass by adding the page. For this, I will use the Views modul
|
|||
|
||||
To begin with, I will create a view showing all types of content with a default sort order of newest first. We will use further tests to ensure that only the correct content is returned and that it is ordered correctly.
|
||||
|
||||
![](/dist/images/blog/tdd-drupal-1.png) { .with-border }
|
||||
![](/images/blog/tdd-drupal-1.png) { .with-border }
|
||||
|
||||
The only addition I will make to the view is to add a path at `pages`, as per the acceptance criteria.
|
||||
|
||||
![](/dist/images/blog/tdd-drupal-2.png) { .with-border }
|
||||
![](/images/blog/tdd-drupal-2.png) { .with-border }
|
||||
|
||||
### Exporting the View
|
||||
|
||||
|
@ -458,7 +458,7 @@ Tests: 1, Assertions: 3, Failures: 1.
|
|||
|
||||
We can fix this by adding another condition to the view, to only show content based on the node type - i.e. only return page nodes.
|
||||
|
||||
![](/dist/images/blog/tdd-drupal-3.png) { .with-border }
|
||||
![](/images/blog/tdd-drupal-3.png) { .with-border }
|
||||
|
||||
Once the view is updated and the configuration is updated within the module, the test should then pass - and it does.
|
||||
|
||||
|
@ -547,7 +547,7 @@ Tests: 1, Assertions: 2, Failures: 1.
|
|||
|
||||
This can be fixed by removing the default sort criteria and adding a new one based on "Content: Title".
|
||||
|
||||
![](/dist/images/blog/tdd-drupal-4.png) { .with-border }
|
||||
![](/images/blog/tdd-drupal-4.png) { .with-border }
|
||||
|
||||
Again, once the view has been updated and exported, the test should pass - and it does.
|
||||
|
||||
|
|
|
@ -26,7 +26,7 @@ features[features_api][] = api:2
|
|||
|
||||
After clearing the cache, the module is now visible in the Features list - and ready to have the appropriate configuration added to it.
|
||||
|
||||
!['The features list showing the custom module'](/dist/images/blog/custom-module-as-a-feature.png)
|
||||
!['The features list showing the custom module'](/images/blog/custom-module-as-a-feature.png)
|
||||
{% endblock %}
|
||||
|
||||
[0]: https://www.drupal.org/project/features
|
||||
|
|
|
@ -55,12 +55,12 @@ $ git push origin master
|
|||
This seems to have worked OK - the commits are still authored by the correct people and at the correct date and time - and I went ahead and created a new feature branch and pull request based on that master branch.
|
||||
|
||||
<figure>
|
||||
<img src="/dist/images/blog/forked-github-repo-commits.png" alt="The commits on my master branch after rebasing">
|
||||
<img src="/images/blog/forked-github-repo-commits.png" alt="The commits on my master branch after rebasing">
|
||||
<figcaption>The commits on my forked master branch after rebasing and pushing. All good!</figcaption>
|
||||
</figure>
|
||||
|
||||
<figure>
|
||||
<img src="/dist/images/blog/my-commit-to-the-rebased-branch.png" alt="The new feature branch with my additional commit.">
|
||||
<img src="/images/blog/my-commit-to-the-rebased-branch.png" alt="The new feature branch with my additional commit.">
|
||||
<figcaption>The new feature branch with the new commit.</figcaption>
|
||||
</figure>
|
||||
|
||||
|
@ -76,7 +76,7 @@ I believe that it will use an existing "upstream" remote if it exists, otherwise
|
|||
|
||||
Once you’ve completed the rebase, you can then push your updated branch either from the terminal, or using the *Push* command from the same menu.
|
||||
|
||||
![Rebasing a forked repository in PhpStorm using the VCS menu.](/dist/images/blog/github-fork-rebase-phpstorm.png)
|
||||
![Rebasing a forked repository in PhpStorm using the VCS menu.](/images/blog/github-fork-rebase-phpstorm.png)
|
||||
|
||||
It would be great to see something similar added to [hub](https://hub.github.com) too (I’ve created [an issue](https://github.com/github/hub/issues/1047))!
|
||||
|
||||
|
|
|
@ -193,7 +193,7 @@ Override node options 213 passes, 0 fails, 0 exceptions, and 60 debug messages
|
|||
Test run duration: 25 sec
|
||||
```
|
||||
|
||||
<img src="/dist/images/blog/override-node-options-refactor-tests-new-passing.png" alt="">
|
||||
<img src="/images/blog/override-node-options-refactor-tests-new-passing.png" alt="">
|
||||
|
||||
[Here][3] are my full changes from the previous patch, where I added the new tests as well as some small refactors.
|
||||
{% endblock %}
|
||||
|
|
|
@ -58,11 +58,11 @@ By adding a prefix like `tw-`, we can ensure that the Tailwind classes don’t c
|
|||
|
||||
No prefix:
|
||||
|
||||
![](/dist/images/blog/using-tailwind-drupal/prefix-1.png){.with-border}
|
||||
![](/images/blog/using-tailwind-drupal/prefix-1.png){.with-border}
|
||||
|
||||
With prefix:
|
||||
|
||||
![](/dist/images/blog/using-tailwind-drupal/prefix-2.png){.with-border}
|
||||
![](/images/blog/using-tailwind-drupal/prefix-2.png){.with-border}
|
||||
|
||||
### Important
|
||||
|
||||
|
@ -78,11 +78,11 @@ For example: if I had this core markup then the left margin added by `tw-ml-4` w
|
|||
</div>
|
||||
```
|
||||
|
||||
![](/dist/images/blog/using-tailwind-drupal/important-1.png){.with-border}
|
||||
![](/images/blog/using-tailwind-drupal/important-1.png){.with-border}
|
||||
|
||||
With the `!important` rule enabled though, the Tailwind’s class takes precedence and is applied.
|
||||
|
||||
![](/dist/images/blog/using-tailwind-drupal/important-2.png){.with-border}
|
||||
![](/images/blog/using-tailwind-drupal/important-2.png){.with-border}
|
||||
|
||||
## Example
|
||||
|
||||
|
|
|
@ -11,7 +11,7 @@ meta:
|
|||
description: "You've built your PHP application, now learn how to deploy it with Fabric."
|
||||
type: website
|
||||
image:
|
||||
url: /assets/images/talks/deploying-php-fabric.png
|
||||
url: /images/talks/deploying-php-fabric.png
|
||||
width: 2560
|
||||
height: 1440
|
||||
type: image/png
|
||||
|
|
|
@ -13,7 +13,7 @@ meta:
|
|||
og:
|
||||
title: Getting Started with Drupal 8 Module Development
|
||||
image:
|
||||
url: /assets/images/talks/dclondon16.png
|
||||
url: /images/talks/dclondon16.png
|
||||
type: 'image/png'
|
||||
height: 540
|
||||
width: 960
|
||||
|
|
|
@ -13,7 +13,7 @@ meta:
|
|||
description: "How I migrated the Drupal Bristol website onto Drupal 8."
|
||||
type: website
|
||||
image:
|
||||
url: /assets/images/talks/getting-your-data-into-drupal-8.png
|
||||
url: /images/talks/getting-your-data-into-drupal-8.png
|
||||
width: 2560
|
||||
height: 1440
|
||||
type: image/png
|
||||
|
|
|
@ -17,7 +17,7 @@ meta:
|
|||
description: An introduction to utility CSS and Tailwind.
|
||||
type: website
|
||||
image:
|
||||
url: '/assets/images/talks/taking-flight-tailwind.png'
|
||||
url: '/images/talks/taking-flight-tailwind.png'
|
||||
width: 2560
|
||||
height: 1440
|
||||
type: 'image/png'
|
||||
|
|
|
@ -14,7 +14,7 @@ meta:
|
|||
description: "How to write tests and follow TDD for Drupal applications."
|
||||
type: website
|
||||
image:
|
||||
url: /assets/images/talks/test-driven-drupal-development.png
|
||||
url: /images/talks/test-driven-drupal-development.png
|
||||
width: 2560
|
||||
height: 1440
|
||||
type: image/png
|
||||
|
|
|
@ -120,7 +120,7 @@ experiences:
|
|||
<div class="mb-12">
|
||||
{% if company.logo %}
|
||||
<div class="float-right mt-2 mb-4 ml-4 w-16 sm:w-24 lg:w-32">
|
||||
<img src="{{ site.images_url }}/dist/images/experience/{{ company.logo }}" alt="{{ company.name }} logo">
|
||||
<img src="{{ site.images_url }}/images/experience/{{ company.logo }}" alt="{{ company.name }} logo">
|
||||
</div>
|
||||
{% endif %}
|
||||
|
||||
|
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 36 KiB |
Before Width: | Height: | Size: 94 KiB After Width: | Height: | Size: 94 KiB |
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 37 KiB |
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 31 KiB |
Before Width: | Height: | Size: 811 KiB After Width: | Height: | Size: 811 KiB |
Before Width: | Height: | Size: 854 KiB After Width: | Height: | Size: 854 KiB |
Before Width: | Height: | Size: 257 KiB After Width: | Height: | Size: 257 KiB |
Before Width: | Height: | Size: 285 KiB After Width: | Height: | Size: 285 KiB |
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 106 KiB After Width: | Height: | Size: 106 KiB |
Before Width: | Height: | Size: 884 KiB After Width: | Height: | Size: 884 KiB |
Before Width: | Height: | Size: 275 KiB After Width: | Height: | Size: 275 KiB |
Before Width: | Height: | Size: 249 KiB After Width: | Height: | Size: 249 KiB |
Before Width: | Height: | Size: 323 KiB After Width: | Height: | Size: 323 KiB |
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 46 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
Before Width: | Height: | Size: 88 KiB After Width: | Height: | Size: 88 KiB |
Before Width: | Height: | Size: 74 KiB After Width: | Height: | Size: 74 KiB |
Before Width: | Height: | Size: 5.9 KiB After Width: | Height: | Size: 5.9 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 236 KiB After Width: | Height: | Size: 236 KiB |
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 37 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
Before Width: | Height: | Size: 213 KiB After Width: | Height: | Size: 213 KiB |
Before Width: | Height: | Size: 392 KiB After Width: | Height: | Size: 392 KiB |
Before Width: | Height: | Size: 71 KiB After Width: | Height: | Size: 71 KiB |
Before Width: | Height: | Size: 160 KiB After Width: | Height: | Size: 160 KiB |
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 54 KiB |
Before Width: | Height: | Size: 114 KiB After Width: | Height: | Size: 114 KiB |
Before Width: | Height: | Size: 94 KiB After Width: | Height: | Size: 94 KiB |
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 176 KiB After Width: | Height: | Size: 176 KiB |
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
Before Width: | Height: | Size: 250 KiB After Width: | Height: | Size: 250 KiB |
Before Width: | Height: | Size: 482 KiB After Width: | Height: | Size: 482 KiB |
Before Width: | Height: | Size: 539 KiB After Width: | Height: | Size: 539 KiB |
Before Width: | Height: | Size: 165 KiB After Width: | Height: | Size: 165 KiB |
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 652 KiB After Width: | Height: | Size: 652 KiB |
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 51 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 9.2 KiB After Width: | Height: | Size: 9.2 KiB |
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
Before Width: | Height: | Size: 316 KiB After Width: | Height: | Size: 316 KiB |
Before Width: | Height: | Size: 406 KiB After Width: | Height: | Size: 406 KiB |
Before Width: | Height: | Size: 394 KiB After Width: | Height: | Size: 394 KiB |
Before Width: | Height: | Size: 367 KiB After Width: | Height: | Size: 367 KiB |
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 7.9 KiB After Width: | Height: | Size: 7.9 KiB |
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 10 KiB |
Before Width: | Height: | Size: 5.3 KiB After Width: | Height: | Size: 5.3 KiB |