DEV Community: James Candan

Shout out to freeCodeCamp's distraction-free VS Code settings

James Candan — Mon, 27 Jan 2025 15:39:28 +0000

Inspired by freeCodeCamp's use of CodeRoad, while building tutorials for Stack Elevate, I came across this gem: a distraction-free VS Code settings configuration.

This is perfect for students engaged in a provided-for-you development environment, to create an engaging, distraction-free coding environment. Good for minimalists too, but may not be suited for those ready to take on the day-to-day work of software development.

# .vscode/settings.json
{
  "breadcrumbs.enabled": false,
  "debug.internalConsoleOptions": "neverOpen",
  "debug.showInStatusBar": "never",
  "editor.acceptSuggestionOnCommitCharacter": false,
  "editor.acceptSuggestionOnEnter": "off",
  "editor.autoClosingBrackets": "never",
  "editor.codeActionsOnSave": {
    "source.fixAll": "explicit"
  },
  "editor.hover.enabled": false,
  "editor.inlineSuggest.enabled": false,
  "editor.minimap.enabled": false,
  "editor.parameterHints.enabled": false,
  "editor.quickSuggestions": {
    "other": false,
    "comments": false,
    "strings": false
  },
  "editor.referenceInfos": false,
  "editor.snippetSuggestions": "none",
  "editor.suggest.statusBar.visible": false,
  "editor.suggestOnTriggerCharacters": false,
  "editor.tabSize": 2,
  "explorer.autoReveal": false,
  "explorer.openEditors.visible": 0,
  "extensions.autoCheckUpdates": false,
  "extensions.ignoreRecommendations": true,
  "files.autoSave": "afterDelay",
  "files.exclude": {
    "**/.git": true,
    "**/.svn": true,
    "**/.hg": true,
    "**/CVS": true,
    "**/.DS_Store": true,
    ".vscode": true,
    ".gitignore": true,
    "freeCodeCamp": true,
    "learn-bash-by-building-a-boilerplate": true,
    ".gitpod.Dockerfile": true,
    ".gitpod.yml": true,
    "CHANGELOG.md": true,
    "coderoad.yaml": true,
    "tutorial.json": true,
    "TUTORIAL.md": true
  },
  "html.autoClosingTags": false,
  "npm.fetchOnlinePackageInfo": false,
  "task.slowProviderWarning": false,
  "terminal.integrated.allowChords": false,
  "terminal.integrated.commandsToSkipShell": ["coderoad.enter"],
  "terminal.integrated.enableFileLinks": false,
  "terminal.integrated.environmentChangesIndicator": "off",
  "terminal.integrated.macOptionIsMeta": true,
  "terminal.integrated.showExitAlert": false,
  "telemetry.enableTelemetry": false,
  "update.mode": "none",
  "update.showReleaseNotes": false,
  "workbench.enableExperiments": false,
  "workbench.startupEditor": "none",
  "workbench.colorTheme": "Tomorrow Night Blue",
  "workbench.colorCustomizations": {
    "[Tomorrow Night Blue]": {
      "menu.background": "#0a0a23",
      "menu.foreground": "#ffffff",
      "activityBar.background": "#0a0a23",
      "activityBar.foreground": "#ffffff",
      "activityBar.activeBorder": "#ffffff",
      "activityBar.border": "#2a2a40",
      "editorWidget.background": "#0a0a23",
      "editorWidget.foreground": "#ffffff",
      "sideBar.background": "#1b1b32",
      "sideBarTitle.foreground": "#858591",
      "sideBar.foreground": "#f5f6f7",
      "sideBar.border": "#2a2a40",
      "editor.background": "#2a2a40",
      "editor.foreground": "#dfdfe2",
      "tab.activeForeground": "#ffffff",
      "tab.inactiveBackground": "#1b1b32",
      "tab.inactiveForeground": "#d0d0d5",
      "tab.border": "#2a2a40",
      "editorGroupHeader.tabsBackground": "#0a0a23",
      "editorIndentGuide.background": "#3b3b4f",
      "terminal.background": "#0a0a23",
      "terminal.foreground": "#ffffff",
      "terminal.ansiBrightGreen": "#ffffff",
      "panel.background": "#1b1b32",
      "panelTitle.inactiveForeground": "#858591",
      "panelTitle.activeBorder": "#f5f6f7"
    }
  },
  "workbench.iconTheme": null,
  "workbench.statusBar.visible": false,
  "workbench.tips.enabled": false,
  "workbench.tree.renderIndentGuides": "none",
  "zenMode.centerLayout": false
}

source: freeCodeCamp: learn-bash-by-building-a-boilerplate: .vscode/settings.json

Here’s a detailed breakdown of the provided VS Code settings.json configuration, as summarized by ChatGPT:

General Settings

breadcrumbs.enabled: false

Disables the breadcrumb navigation bar at the top of the editor.
debug.internalConsoleOptions: neverOpen

Prevents the debug console from automatically opening during a debugging session.
debug.showInStatusBar: never

Hides the debug status bar item.

Editor Behavior

editor.acceptSuggestionOnCommitCharacter: false

Prevents auto-completion when pressing commit characters (e.g., ;, ,).
editor.acceptSuggestionOnEnter: off

Disables accepting suggestions by pressing Enter.
editor.autoClosingBrackets: never

Disables automatic closing of brackets.
editor.codeActionsOnSave: { "source.fixAll": "explicit" }

Runs all applicable code fixes explicitly marked as fixable on save.
editor.hover.enabled: false

Disables the hover tooltip feature.
editor.inlineSuggest.enabled: false

Disables inline suggestions.
editor.minimap.enabled: false

Disables the minimap (code overview bar).
editor.parameterHints.enabled: false

Disables parameter hints when typing function arguments.
editor.quickSuggestions: { "other": false, "comments": false, "strings": false }

Disables suggestions in all contexts: other code, comments, and strings.
editor.referenceInfos: false

Disables reference information in the editor.
editor.snippetSuggestions: none

Disables snippet suggestions.
editor.suggest.statusBar.visible: false

Hides the suggestion widget status bar.
editor.suggestOnTriggerCharacters: false

Disables suggestions triggered by specific characters (e.g., .).
editor.tabSize: 2

Sets the tab width to 2 spaces.

Explorer and Files

explorer.autoReveal: false

Prevents automatically revealing the active file in the file explorer.
explorer.openEditors.visible: 0

Hides the "Open Editors" section in the explorer.
files.autoSave: afterDelay

Saves files automatically after a short delay.
files.exclude: { ... }

Hides specific files and folders from the explorer, including .git, .vscode, .DS_Store, and several specific files like CHANGELOG.md.

Extensions

extensions.autoCheckUpdates: false

Disables automatic extension update checks.
extensions.ignoreRecommendations: true

Ignores extension recommendations.

HTML and NPM

html.autoClosingTags: false

Disables automatic closing of HTML tags.
npm.fetchOnlinePackageInfo: false

Prevents fetching online package info when working with npm.

Terminal Settings

terminal.integrated.allowChords: false

Disables key chord detection in the terminal.
terminal.integrated.commandsToSkipShell: ["coderoad.enter"]

Skips processing coderoad.enter command in the shell.
terminal.integrated.enableFileLinks: false

Disables clickable file links in the terminal.
terminal.integrated.environmentChangesIndicator: off

Disables indicators for environment variable changes.
terminal.integrated.macOptionIsMeta: true

Treats the Option key as Meta on macOS.
terminal.integrated.showExitAlert: false

Disables alerts when a terminal process exits.

Telemetry and Updates

telemetry.enableTelemetry: false

Disables telemetry data collection.
update.mode: none

Disables automatic updates for VS Code.
update.showReleaseNotes: false

Prevents showing release notes after an update.

Workbench Settings

workbench.enableExperiments: false

Disables experimental features.
workbench.startupEditor: none

Prevents the startup editor (welcome page) from opening.
workbench.colorTheme: Tomorrow Night Blue

Sets the color theme to "Tomorrow Night Blue."
workbench.colorCustomizations: { ... }

Customizes the colors for the selected theme (e.g., background, foreground, sidebar, tabs, etc.).
workbench.iconTheme: null

Disables the file icon theme.
workbench.statusBar.visible: false

Hides the status bar.
workbench.tips.enabled: false

Disables tips and recommendations in the workbench.
workbench.tree.renderIndentGuides: none

Disables indent guides in tree views.

Zen Mode

zenMode.centerLayout: false Prevents centering the editor layout in Zen mode.

This configuration is designed to minimize distractions by disabling most UI elements, suggestions, and automatic behaviors. It’s ideal for users who prefer a clean, highly customized workspace focused solely on code. Let me know if you'd like further details on any specific part!

VS Code Minimalist Configuration

This settings.json file is designed to create a clean, distraction-free coding environment for developers, educators, or learners who prefer simplicity and focus. It disables many of VS Code’s default features that might feel overwhelming or unnecessary, allowing you to concentrate on the code itself.

Key Features

Distraction-Free Editor
- Removes extra visual elements like the minimap, breadcrumbs, and hover tooltips.
- Disables inline suggestions, auto-closing brackets, and parameter hints to avoid interruptions.
- Keeps the interface simple by hiding the status bar and startup editor.
Streamlined Workflow
- Focuses on manual control by turning off auto-completion, suggestion pop-ups, and snippet suggestions.
- Simplifies the explorer by hiding unnecessary files and folders (e.g., .git, .vscode, temporary files).
Privacy and Stability
- Disables telemetry (tracking and data sharing with VS Code).
- Prevents automatic updates to extensions or the editor itself, ensuring a consistent experience.
Custom Theme and Appearance
- Uses the Tomorrow Night Blue theme, a dark and low-contrast color scheme that’s easy on the eyes.
- Further customizes the theme for a cohesive and polished look (e.g., sidebar, tabs, terminal colors).
Terminal Tweaks
- Adjusts terminal behavior for simplicity, like disabling clickable links and environment change notifications.

Who Is This For?

This setup is ideal for:

Developers who prefer minimalism: Perfect if you want to focus on writing code without the noise of extra features.
Educators or workshop hosts: Simplifies the interface, making it easier for learners to follow along without distractions.
Privacy-conscious users: Reduces data sharing and unnecessary online activity from the editor.
Those maintaining legacy projects or tutorials: Optimized for working in environments with specific file structures.

How It Feels to Use

You’ll notice fewer pop-ups, suggestions, and visual elements cluttering your screen.
The editor stays calm and focused, encouraging manual coding and problem-solving rather than relying on hints or automation.
It feels lightweight and stable, making it an excellent choice for long coding sessions.

Customizations

This configuration has been tailored with specific preferences in mind:

Certain files and folders (like .git, .DS_Store, and FreeCodeCamp-related files) are hidden from the file explorer.
The terminal and editor are simplified, but basic functionality remains intact.
The color scheme is soothing and consistent, designed for extended use.

How to Use This Configuration

Copy the contents of settings.json.
Open VS Code and go to File > Preferences > Settings (or press Ctrl + ,).
Click the {} icon in the top-right corner to open the settings editor in JSON format.
Paste the configuration and save the file.

Enjoy a cleaner, distraction-free coding experience!

A ChatGPT About Drupal Conventional Commits

James Candan — Tue, 02 May 2023 16:04:13 +0000

Intro

I have implemented Semantic Releases and an autogenerated Change Log into Drupal projects. The effort has surprised me at times, thinking about what a commit message should be categorized as, whether it should be noted in the change log, how and whether it affects a release version bump, and whether it is appropriate to squash merge requests.

Since I haven't found any forum posts, issues, or articles on this problem space as it relates to CMSs generally and to Drupal projects specifically, I decided to pick ChatGPT's brain on the subject. The following is the result of this conversation.

A Chat About Drupal Conventional Commits

Me:

What are conventional commits?

ChatGPT

Conventional Commits is a specification for structuring commit messages in a standardized way. The idea is to make it easier for developers to understand the purpose and context of a commit, and to automate certain parts of the software development process, such as generating changelogs or triggering automatic deployments.

A conventional commit message consists of a header, a body, and a footer. The header includes a type, a scope, and a subject, which together describe the change being made. The body and footer are optional and provide additional information about the change.

The type of a commit message is a keyword that specifies the general nature of the change. For example, the type might be "feat" for a new feature, "fix" for a bug fix, or "docs" for documentation updates. The scope is optional and is used to further specify the location or component of the change, such as a specific file or module.

Here's an example of a conventional commit message:
feat(authentication): add support for OAuth2 authentication

This commit adds support for OAuth2 authentication using the Google API.

BREAKING CHANGE: The previous authentication method has been removed.
In this example, the type is "feat", the scope is "authentication", and the subject is "add support for OAuth2 authentication". The body provides additional details about the change, and the footer includes a "BREAKING CHANGE" section indicating that the change is backwards-incompatible.
By following the Conventional Commits specification, developers can ensure that their commit messages are consistent, informative, and machine-readable, making it easier to collaborate and automate certain parts of the software development process.

Me:

I can see how this can be useful to autogenerate a change log. That might work for libraries or packages. But, is this applicable to web applications and content management systems?

ChatGPT

Yes, Conventional Commits can be used for web applications and content management systems as well, especially if they are built using a version control system such as Git.

In web development, changes to the codebase can have a direct impact on the user experience, and it's important to be able to communicate those changes effectively to users, stakeholders, and other developers. By using a standardized commit message format, such as Conventional Commits, developers can provide more context and clarity around the changes they are making, which can help reduce confusion and improve collaboration.

For example, if a developer is working on a web application and makes a change to the login process, they might use a commit message like this:
feat(login): add support for two-factor authentication

This commit adds support for two-factor authentication to the login process, improving security for users.

BREAKING CHANGE: Users will need to set up two-factor authentication before logging in.
This message makes it clear that the change is related to the login process, what the change is (adding two-factor authentication), why the change is important (improving security), and any breaking changes that might affect users (they will need to set up two-factor authentication before logging in).

By using Conventional Commits, developers can create commit messages that are consistent, informative, and easy to understand, making it easier to collaborate and manage changes to web applications and content management systems.

Me:

Semantic Release is an NPM package with plugins that can generate release notes based on commit messages. By default, it treats breaking changes as major, feature enhancements as minor, and bug fixes as patch releases. Angular has its own set of conventional commit types for web applications. What are some appropriate commit types for a CMS? And how might each affect the release version?

ChatGPT

The appropriate commit types for a CMS will depend on the specific features and functionality of the CMS, but here are some common types of commits that may be applicable:

feat: This commit type can be used for new features or functionality added to the CMS. Depending on the significance of the feature, it could result in a minor or major release.

fix: This commit type can be used for bug fixes within the CMS. This would typically result in a patch release.

docs: This commit type can be used for documentation changes, such as updating the user manual or adding inline comments. This type of commit would not usually affect the release version.

style: This commit type can be used for changes to the look and feel of the CMS, such as updating the CSS or layout. This type of commit would not usually affect the release version.

refactor: This commit type can be used for code changes that do not add any new functionality or fix any bugs, but are done for other reasons such as improving code readability or maintainability. This type of commit would not usually affect the release version.

test: This commit type can be used for changes to the testing infrastructure, such as adding new unit tests or fixing broken tests. This type of commit would not usually affect the release version.

In terms of how each type of commit might affect the release version, it would depend on the specific rules and guidelines set by the CMS development team. Typically, breaking changes would result in a major release, new features would result in a minor release, and bug fixes would result in a patch release. However, this may vary depending on the significance of the changes and the development team's release management process.

Me:

Do style, docs, refactor, and test types typically affect the release version?

ChatGPT

In general, commit types like style, docs, refactor, and test are not expected to have a significant impact on the release version of a project. These commit types are typically considered as non-breaking changes, as they don't add new features, fix bugs, or change the behavior of the software.

However, in some cases, these types of changes may indirectly impact the release version. For example:

style: Changes to the style or formatting of the code may affect the behavior of the software, particularly if there are syntax errors introduced. While unlikely, it's possible that such changes may require a patch release.

docs: Changes to documentation are usually independent of the software functionality and shouldn't affect the release version, unless the documentation is incorrect, incomplete, or unclear and is causing issues for the users.

refactor: Changes to code structure, organization, or naming conventions don't usually change the functionality of the software, but in some cases, they may indirectly impact the behavior of the software. For example, refactoring may remove duplicate code, which could affect performance or memory usage.

test: Changes to the test suite shouldn't impact the release version, as long as they don't introduce new bugs or issues that are not caught during the testing phase.

Ultimately, the decision of whether a particular commit should trigger a release or not depends on the project's specific release management process and guidelines. The release manager should consider the impact of each commit on the software, the severity of the changes, and the project's release schedule to decide whether a new release is necessary or not.

Me:

So, the default behavior from Semantic Release's plugin should be configured to treat each type's release version change as appropriate for the project. The Drupal ecosystem has a number of possible software projects associated with it: modules, NPM packages, composer packages, etc. When each is developed independently, I can see how semantic versioning and commit types can be used very clearly. It is not so clear for Drupal CMS projects as a whole. A CMS project has several types of end users and stake holders. If the change log is meant to communicate to editors and possibly site visitors, what conventional commit types do you think might be most appropriate?

ChatGPT

For Drupal CMS projects that are meant to be used by multiple types of end users and stakeholders, the commit types should be selected carefully to ensure that the release notes are easy to understand and useful for all stakeholders. Here are some commit types that might be most appropriate:

feat: This commit type can be used for new features or functionality that are relevant to end users or stakeholders. For example, adding a new content type or user role could be considered a feature that should be communicated to stakeholders.

fix: This commit type can be used for bug fixes that are relevant to end users or stakeholders. For example, fixing a broken link or resolving a permission issue could be considered a fix that should be communicated to stakeholders.

docs: This commit type can be used for changes to documentation that are relevant to end users or stakeholders. For example, updating the user manual or adding inline help text could be considered a documentation change that should be communicated to stakeholders.

style: This commit type can be used for changes to the look and feel of the CMS that are relevant to end users or stakeholders. For example, updating the color scheme or typography could be considered a style change that should be communicated to stakeholders.

refactor: This commit type can be used for code changes that improve the CMS's performance, security, or maintainability, which may not be immediately visible to end users but still have an impact on their experience. For example, optimizing database queries or refactoring legacy code could be considered a refactor that should be communicated to stakeholders.

chore: This commit type can be used for changes to the build process, dependencies, or other non-functional aspects of the CMS that are relevant to developers or site administrators. For example, upgrading to a new version of PHP or updating a third-party library could be considered a chore that should be communicated to stakeholders.

Ultimately, the choice of commit types depends on the specific features and functionality of the CMS and the priorities of its stakeholders. The goal should be to provide clear and concise release notes that communicate the changes in a way that is relevant and useful to all stakeholders.

Me:

What about development specific features? For example, we are adding a set of modules and configurations for local development of a data migration. This doesn't affect editors or site visitors, but lays the groundwork for developers to begin building custom data migration tools. What commit type seems most appropriate here?

ChatGPT

For development-specific features like adding modules and configurations for local development of a data migration, the most appropriate commit type would be feat, as it represents the addition of new features or functionality. Specifically, you could use a prefix to distinguish the commit as being relevant to developers only, such as dev-feat or internal-feat. This communicates to stakeholders that the commit is related to a feature that is only relevant to the development team, and not to end users or site visitors.

While this commit type may not directly impact the CMS's end users or stakeholders, it is still important to communicate these changes in the release notes to keep everyone informed and up-to-date with the progress of the project. This also helps to build transparency and trust within the development team and with external stakeholders who may be interested in the project's development process.

Me:

Should a refactor affect the release version--major, minor, patch, or none?

ChatGPT

Whether a refactor should affect the release version depends on the scope and impact of the changes made. In general, refactors that have a significant impact on the functionality or stability of the codebase should result in a version change. However, if the refactor only improves the code quality or maintainability without changing the external behavior of the system, then it might not require a version change.

If the refactor introduces new features or breaks existing ones, it should result in a major version change. If it includes performance improvements or adds functionality in a backward-compatible way, it should result in a minor version change. If the refactor only fixes bugs or includes small improvements, it should result in a patch version change.

It's important to note that the decision to increment the version number should be made based on the impact of the refactor on the external behavior of the system, rather than the effort put into the refactor. The version number should accurately reflect the changes made and the impact they have on the system.

Me:

How can we tell semantic release to treat refactor commits differently?

ChatGPT

To tell Semantic Release to treat refactor commits differently, you can use a custom configuration for the @semantic-release/commit-analyzer plugin. This plugin is responsible for analyzing the commit messages and determining the appropriate version number to assign to the release. By default, it treats refactors as patch releases, but you can customize this behavior by configuring the plugin to consider refactor commits as minor or major releases instead.

To do this, you can use the "preset" option in your semantic-release configuration file and specify a custom commit message preset that defines how refactor commits should be handled. For example, you could create a custom preset that treats refactor commits as minor releases by adding the following to your configuration file:
{
  "preset": "angular",
  "plugins": [
    "@semantic-release/commit-analyzer",
    {
      "preset": "angular",
      "releaseRules": [
        {"type": "refactor", "release": "minor"}
      ]
    },
    "@semantic-release/release-notes-generator",
    "@semantic-release/github"
  ]
}
In this configuration, we're using the "angular" preset as a base, which defines the default behavior for commit types. Then, we're configuring the commit analyzer plugin to consider refactor commits as minor releases by adding a custom release rule that matches commits with the "refactor" type and sets the release type to "minor".

With this configuration, Semantic Release will assign a minor version number to any release that includes a commit with the "refactor" type, as long as there are no other breaking changes or major features included in the release.

Me:

Are there any commits that should skip a release version change?

ChatGPT

Yes, there are certain types of commits that may not require a release version change. For example, commits that only update documentation, code formatting, comments, or other non-functional changes that don't impact the system's behavior or features may not need to trigger a new release version.

In general, any commit that doesn't add new functionality or modify existing functionality in a significant way could be considered a candidate for skipping a release version change. However, it's ultimately up to the project team to decide which types of commits should trigger a version change and which should not.

It's worth noting that skipping a release version change for certain commits can be a useful strategy for avoiding unnecessary version number increments, especially for projects with frequent releases or small changes. This can help to prevent confusion among users and stakeholders who may expect major version increments to signal significant changes or new features. On the other hand, if a commit does impact the system's behavior or features in a meaningful way, it's important to update the version number accordingly to ensure clarity and transparency.

Me:

When is it appropriate to bump a major version of a CMS website? Is it appropriate to consider removing a feature a breaking change? This is not an API, it's a web application provided to editors in order to communicate with site visitors. What might be considered a breaking change for a CMS website? Should the site's major version only be bumped if a strong visual or organizational change is made?

ChatGPT

In a CMS website, it's appropriate to bump a major version when there are significant changes that affect the overall functionality, usability, or compatibility of the website. Some examples of changes that might warrant a major version bump include:

Removing a core feature that is widely used by site editors or visitors

Changing the way that content is structured or displayed, such as reorganizing menus or changing the layout of pages

Upgrading to a new major version of the CMS software itself, which may introduce significant changes to the underlying architecture or APIs

In general, any change that significantly impacts the user experience or requires significant effort for editors or developers to adapt to could be considered a candidate for a major version bump.

Regarding removing a feature, it depends on the feature itself and how widely it is used. If it's a core feature that many editors or visitors rely on, removing it could be considered a breaking change. However, if it's a less frequently used feature or one that can be replaced with a similar feature, it may not be necessary to consider it a breaking change.

It's important to communicate any breaking changes clearly to editors and other stakeholders and to provide guidance on how to adapt to the changes. In some cases, it may be appropriate to provide a transitional period where both the old and new features are available, to allow users to adjust at their own pace.

As for when to bump the major version of the site, it's ultimately up to the project team to decide based on the scope and impact of the changes being made. If there are strong visual or organizational changes that significantly affect the user experience or require a significant amount of effort to adapt to, then it may be appropriate to bump the major version. However, if the changes are more incremental or focused on bug fixes and minor enhancements, it may be more appropriate to bump the minor or patch version instead.

Conclusion

This was a fun exercise. I do hope to nail down and contribute a conventional-changelog-drupal package one day. In the meantime, I suggest you familiarize yourself with the default Angular change log preset.

Do leave comments giving me your thoughts. Hopefully, we can come up with a shared convention that makes sense for broader CMS web implementations. Again, this is a challenge, not for libraries, packages, distributions, or frameworks--all of which I think are covered well in the available online discussion on the topic--, but for the implementation of a web CMS project: the thing that is released, deployed, and edited by editors on production and contains content meant for a website visitor. It seems there are several layers of stakeholders. How do we communicate release changes to each in a way that makes sense to them?

Drupal 9+ SEO

James Candan — Sat, 22 Apr 2023 16:20:16 +0000

A while back, the Varbase distribution turned me on to Real-time SEO for Drupal for SEO analysis in Drupal.

However, I recently tried it out for a Drupal 9 project, and it failed to capture Layout Builder content. Also, it has a 2.0-alpha that's been halted.

I just found this gem, and it does the trick really well, even with Layout Builder:

Yoast Analysis

It supports Drupal 9 and Drupal 10.

Drupal Install with Configs and hook_install()

James Candan — Tue, 04 Apr 2023 21:15:55 +0000

I was able to perform the following steps to fix a config dependency error and then do a fresh install with config.

First, in order to bypass the --existing-config restriction on install profiles with a hook_install(), comment out web/core/profiles/standard/standard.install.

Then, do the following:

# A clean install to work with
lando drush si standard -y

# Export any individual missing configs.
# Example:
lando drush config:get comment.type.comment > config/sync/comment.type.comment.yml
lando drush config:get field.field.comment.comment.comment_body > config/sync/field.field.comment.comment.comment_body.yml

# Re-install with existing configs.
lando drush si standard --existing-config -y

At this point, you have a working Drupal install with the imported existing configs.

We still want to run the standard profile's installation hook. So, copy the contents of standard_install(). In a text editor, paste and edit the PHP statements. Ensure the full paths are supplied to the class names. Copy this set of statements.

-  $user = User::load(1);
+  $user = Drupal\user\Entity\User::load(1);

-  $shortcut = Shortcut::create([
+  $shortcut = Drupal\shortcut\Entity\Shortcut::create([

-  $shortcut = Shortcut::create([
+  $shortcut = Drupal\shortcut\Entity\Shortcut::create([

Hop into a PHP REPL, paste and run the PHP statements.

$ lando drush php
Psy Shell v0.10.12 (PHP 8.0.27 — cli) by Justin Hileman
Caonline Rebuild - Workbench Access (Drupal 9.4.5)
>>>   $user = Drupal\user\Entity\User::load(1);
...
  $shortcut->save();
=> 1
>>> exit

At this point, you can export configs and commit.

lando drush cex -y

Secure SSO with Drupal

James Candan — Wed, 22 Mar 2023 10:53:11 +0000

SimpleSAMLphp in Drupal is great, but documentation around a secure setup is lacking. So, here's that.

tldr;

Set a SIMPLESAMLPHP_CONFIG_DIR environment variable to point to a committed config directory (typically, I set it to config/simplesaml/config).
In that config directory, copy the the appropriate template config files with the sensitive data set to look at environment variables (e.g. Replace the original saml20-idp-remote.php hash value with getenv('SIMEPLE_SAML_METADATA_CERT_KEY')).
supply saml.crt and saml.pem SSL uncommitted certs to the certdir configured in config/simplesamlphp/config/config.php.

Full-width, Drupal core Remote Video with YouTube parameters

James Candan — Thu, 05 Jan 2023 05:52:50 +0000

Drupal core supplies us a Remote Video media type. To display Media items of this type in a block, full-width, with desired YouTube parameters, you'll need the following.

Note: This was tested on Drupal 10 in January 2023. The latest FitVids library release is 1.2.0.

Overview

Modules

Entity Block

  composer require drupal/entity_block

Entity Block will allow you to add Remote Videos to a Layout Builder section block.

FitVids

  composer require drupal/fitvids

The FitVids module relies on a package that detects video embeds and widens them to fill their respective HTML container.

A custom module for YouTube parameter handling Drupal core's oEmbed does not currently support YouTube Embedded Players and Player Parameters. We'll need a custom module to make this happen.

Tips and Additional Bits

FitVids Library

The FitVids module will require you to have the FitVids library. This has not been released to Packagist. So, we'll need to specify a special package repository in Composer.

To get the FitVids library, add this to your composer.json, within your repositories list:

        {
            "type": "package",
            "package": {
                "name": "davatron5000/fitvids",
                "version": "1.2.0",
                "type": "drupal-library",
                "source": {
                    "url": "https://github.com/davatron5000/FitVids.js.git",
                    "type": "git",
                    "reference": "v1.2.0"
                },
                "require": {
                    "composer/installers": "^2.0"
                },
                "extra": {
                    "installer-name": "fitvids"
                }
            }
        }

You may then run:

composer require davatron5000/fitvids:1.2.0

FitVids oEmbed Patch

Add the Not applying to oEmbed videos patch (as of this writing, tested successfully with comment #2's patch).

Configure FitVids for youtu.be

FitVids doesn't recognize the https://youtu.be embed URL, but the module allows us to fix that.

Simply add a FitVids setting for custom vendor:

Handle YouTube Parameters

Add this to a custom .module file.

<?php

/**
 * @file
 * Helper module for Media oEmbed YouTube player parameters.
 *  
 * @see https://www.drupal.org/project/2788249/issues/3266590
 */ 

use Drupal\Component\Utility\UrlHelper;
use Drupal\media\IFrameMarkup;

/**
 * Implements hook_preprocess_HOOK().
 */ 
function HOOK_preprocess_media_oembed_iframe(array &$variables) {
  $url = \Drupal::request()->query->get('url');
  $params = UrlHelper::parse($url)['query'];
  $query = http_build_query($params);

  $original = $variables["media"]->__toString();
  if (!empty($params)) {
    $original = str_replace('feature=oembed', 'feature=oembed&' . $query, $original);
  }

  $variables["media"] = IFrameMarkup::create($original);
}

Conclusion

This produced a clean implementation of remote video for full-width, YouTube videos with parameters. This has not been tested on Vimeo or other providers. I hope you've found this helpful.

Cheers!

Vuex Airbnb JS ESLint

James Candan — Mon, 04 Apr 2022 19:27:12 +0000

I found the following useful when working with VueJS and using the Airbnb ESLint rules.

# .eslintrc.yml

rules:
  # Airbnb Eslint sets the no-param-reassign props option to true, which warns
  # against the modification of parameter properties. However, in order to
  # control the state (using Vuex), one must use mutations/actions.
  # Set it to false.
  'no-param-reassign':
    - error
    -
      props: false

reCAPTCHA + Laravel + Vue

James Candan — Mon, 13 Dec 2021 19:10:22 +0000

We'll implement a reCAPTCHA Vue package in the frontend and a PHP package for the backend. We'll ensure each step is working as expected along the way.

Prerequisites
1. Provide reCAPTCHA keys
2. Prepare the front-end
3. Error Handling

Prerequisites

Assumes you have a working Laravel 8 and Vue 2.0 project, Composer and NPM, and a Vue form to which you want to add reCAPTCHA.

This was built onto a project that uses InertiaJS. However, I believe this should work on a separated front-end and back-end. As such, each sub-section is prefixed with either (Laravel) or (Vue) to indicate to which side the changes belong.

1. Provide reCAPTCHA keys

We'll need a valid SITEKEY and SECRET from Google.

(Laravel) Store environment variables

Add keys to your .env file.

NOTE: Do not commit your .env file. You should commit a .env.example with secure values redacted.

RECAPTCHAV2_SITEKEY=<yoursitekeyhere>
RECAPTCHAV2_SECRET=<yoursecrethere>

WARNING: Do not expose RECAPTCHAV2_SECRET to the front-end.

If using VueCLI, environment variables are embedded into the build, meaning anyone can view them by inspecting your app's files. If using VueCLI, Do not store this value in any .env file on Production, not even .env.production. They are auto-loaded by VueCLI. It is okay to expose the SITEKEY, but for the SECRET, use some other secure method in Production, such as setting environment variables without this dotenv file.

Define these environment variables in Laravel's configuration.

Create a config/recaptchav2.php file:

<?php
return [
    'origin' => env('RECAPTCHAV2_ORIGIN', 'https://www.google.com/recaptcha'),
    'sitekey' => env('RECAPTCHAV2_SITEKEY', ''),
    'secret' => env('RECAPTCHAV2_SECRET', '')
];

(Laravel) Share environment variable with front-end

Here's that InertiaJS piece mentioned in the prerequisites above.

The gist of this change is that we want to share the RECAPTCHAV2_SITEKEY environment variable with the front-end.

If not using InertiaJS, you should be able to provide the environment variable to Vue some other way (such as mentioned above if using VueCLI).

Here's an InertiaJS way of doing it:

We do this with InertiaJS middleware in app/Http/Middleware/HandleInertiaRequests.php.

 public function share(Request $request)
 {
     return array_merge(parent::share($request), [
+        // Provide the reCAPTCHA site key to the front-end.
+        'recaptchav2_sitekey' => config('recaptchav2.sitekey'),
+        // DO NOT SHARE RECAPTCHAV2_SECRET.
     ]);
 }

(Vue) Ensure successful share to front-end

In your Vue form somewhere, we'll temporarily plop in the following to ensure the key is being passed successfully from the backend.

 <template>
+  {{ $page.props.recaptchav2_sitekey }}
   ...
 </template>

This may be different depending on the route taken to expose the environment variable. With VueCLI it would be {{ process.env.RECAPTCHAV2_SITEKEY }}.

Browsing the page should display your site key.

2. Prepare the front-end

We have a securely stored secret key, and can display the site key on the page. Now, let's get a working reCAPTCHA to appear on the page.

(Vue) Add reCAPTCHA Vue

Require the reCAPTCHA Vue package.

npm install --save @vue/composition-api vue-recaptcha

Add the reCAPTCHA to your component.

 <template>
-  {{ $page.props.recaptchav2_sitekey }}
   <form>
     ...
+    <vue-recaptcha 
+      :sitekey="$page.props.recaptchav2_sitekey" 
+    />
   </form>
 </template>

+<script>
+import { VueRecaptcha } from 'vue-recaptcha';
+
+export default {
+  components: {
+    VueRecaptcha,
+  },

At this point, you should have a visible, working reCAPTCHA on your page.

3. Prepare the back-end

(Laravel) Add middleware

composer require google/recaptcha

Define a reCAPTCHA middleware class.

<?php
/**
 * @file app/Http/Middleware/Recaptcha.php
 */

namespace App\Http\Middleware;

use Closure;
use ReCaptcha\ReCaptcha as GoogleRecaptcha;

class Recaptcha
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        $response = (new GoogleRecaptcha(config('recaptchav2.secret')))
            ->verify($request->input('g-recaptcha-response'), $request->ip());

        if (!$response->isSuccess()) {
            return redirect()->back()->with('status', 'Recaptcha failed. Please try again.');
        }

        return $next($request);
    }
}

List this new middleware in /app/Http/Kernel.php:

 'password.confirm' => \Illuminate\Auth\Middleware\RequirePassword::class,
+'recaptcha' => \App\Http\Middleware\Recaptcha::class,
 'signed' => \Illuminate\Routing\Middleware\ValidateSignature::class,

Then, attach this middleware to your form's submit route.

 Route::post('/my-form-action', [
     MyFormController::class, 
     'submitForm'
-]);
+])
+    ->middleware('recaptcha');

(Vue) Pass the reCAPTCHA response

The reCAPTCHA backend expects a token response from the front-end.

-    <vue-recaptcha 
-      :sitekey="$page.props.recaptchav2_sitekey" 
+      @verify="onCaptchaVerify"
-    />
 ...
 methods: {
+  onCaptchaVerify(token) {
+    // Provide the token response to the form object.
+    this.form['g-recaptcha-response'] = token;
   },

Note: This assumes you are using a form data object.

At this point, you can verify you are human and submit the form. If you fail to check the CAPTCHA box, submitting the form should redirect you back with a Recaptcha failed. Please try again. status.

3. Error Handling

On submit, if the reCAPTCHA has failed or has not been attempted, we want to indicate that to the visitor.

Make the following additions:

 <vue-recaptcha
   :sitekey="$page.props.recaptchav2_sitekey"
   @verify="onCaptchaVerify"
 />
+<span
+  v-if="recaptcha_error"
+  class="error-message"
+>
+  Please confirm you are not a robot.
+</span>
 ...
   data() {
     return {
+      recaptcha_error: false,
       form: {
         ...
       }
     }
   },
   methods: {
     onSubmit() {
+      if (!this.form['g-recaptcha-response']) {
+        // Show error after submit.
+        this.recaptcha_error = true;
+      } else {
+        // Proceed with submission.
+      }
     }

Enjoy your functioning reCAPTCHA.

Lando + WSL2 via Hyperdrive

James Candan — Fri, 27 Aug 2021 15:48:05 +0000

UPDATE 7/8/2024

Lando has released v3.21.0! This includes a backport of Lando 4 installation process and plugin handling. Hyperdrive--Lando's previous install script helper--is no longer needed.

It also seems Lando has removed the "Setup Lando on Windows with WSL2" article. So, you'll have to rely on Microsoft's own How to install Linux on Windows with WSL.

Only recently, WSL2 was made default, run wsl -l -v to ensure you are running WSL2. If not, you need to follow Upgrade version from WSL 1 to WSL 2.

All you need to do is:

Get WSL2 (see above).
Open the Windows Store and get the latest Ubuntu (e.g. 22.04).
Follow the Linux link within Lando's Installation in a WSL2 Linux Environment.

This is the final update this article will receive. I hope it was helpful!

UPDATE 9/15/2023

Hyperdrive supported up to Ubuntu 18.04.
Docker Engine supports Ubuntu 20.04+.

Suggestions to get Lando on Windows via WSL2:

Get WSL2. Typically WSL1 is default, you need to be sure to follow the Windows docs to get WSL2.
Get Ubuntu 20.04 or 22.04 via the Windows Store.
Follow Docker's Install using the Apt repository.
Follow the Then, Get The Latest Lando section below.
You may additionally wish to update curl and git, and configure your git user and SSH keys.

UPDATE 6/7/2022

Updated the command lines to be copy/paste-ready for Ubuntu terminal in Windows. I noticed that it had trouble with the multi-line commands broken up by the back-slash (\) character.

Also, added a section to handle Docker version updates.

Intro

Falling short

If you've recently followed the awesome instructions to Setup Lando on Windows with WSL2, then you may have noticed your version of Lando is quite behind, or may not have completely worked at all.

Hyperdrive hasn’t seen a lot of love, so while it’s super awesome, it’s not up-to-date. They’re about to revamp it to be even more awesome, but until then, we need to jump through a couple hoops to install the latest stable release of Lando.

While Hyperdrive is being revamped, we need to use the last stable version, v0.6.1. However, even that hadn't received a relatively recent change to the stable release link.

Here’s what you need to do.

First, Run Hyperdrive

If you've already run Hyperdrive, you likely won't need this step.

If it failed to complete, you may have missed the instruction to sudo apt --fix-broken install without any specified package. Once that's done, run it again. You'll find a working Hyperdrive install command below.

Follow the documentation if you want to change the customizations included below, but this will work for most folks. Pop a --vim flag on there too if you wish.

IMPORTANT!

Don't forget to change your name and email address. This is used to populate Git config.

curl -Ls https://github.com/lando/hyperdrive/releases/download/v0.6.1/hyperdrive > /tmp/hyperdrive; chmod +x /tmp/hyperdrive; /tmp/hyperdrive --name "YOUR NAME HERE" --email your.email@thisismyawesomedomainnameandyoucanthave.one -y

Update Docker

It doesn't look like Hyperdrive grabs the latest Docker version. You may want to check if Lando supports the latest Docker, then use the following 3 commands to remove Docker and re-install the latest.

sudo apt-get remove docker docker-engine docker.io containerd runc -y; sudo apt-get update -y; sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y;

Visit https://docs.docker.com/engine/install/ubuntu/ for resources on specifying Docker version if the latest is not yet supported by Lando.

Then, Get The Latest Lando

Head over to Lando Releases and make a note of the version from the latest stable release.

Copy/paste the command below into a text editor. Be sure to replace the Github releases link with the one from the releases page.

curl -f#SL -o /tmp/lando.deb https://github.com/lando/lando/releases/download/v3.18.0/lando-x64-v3.18.0.deb; sudo dpkg -i --ignore-depends=docker-ce /tmp/lando.deb; rm -f /tmp/lando.deb;

Once you have made the edit to the command line above, run it.

That does it. Run lando version to see you are on the latest. Cheers!

Install Terminus Plugins In Lando

James Candan — Mon, 18 May 2020 18:12:37 +0000

Background

When you use Lando with Pantheon, and you want to install a Terminus plugin to your Lando local development environment, you'll want to go with something like the following.

Do it

services:
  appserver:
    build:
      - /bin/sh -c "[ -d /var/www/.terminus/plugins ] || mkdir -p /var/www/.terminus/plugins"
      - /bin/sh -c "[ -d /var/www/.terminus/plugins/terminus-secrets-plugin ] || composer create-project -d /var/www/.terminus/plugins pantheon-systems/terminus-secrets-plugin:~1"

Why this way?

This avoids an error:

Creating a "pantheon-systems/terminus-secrets-plugin:~1" project at "./terminus-build-tools-plugin"


  [InvalidArgumentException]                                                                
  Project directory "/var/www/.terminus/plugins/terminus-secrets-plugin" is not empty.

The problem is that it is trying to override already existing directory and files.

Cron with Lando

James Candan — Thu, 27 Feb 2020 12:43:29 +0000

Update Feb 28, 2020: It turns out that cron runs within it's own limited environment. See below for more details.

In Laravel, we want the following cron configuration to fire the framework's scheduler. Place this in a file somewhere within your project code base. I went with resources/config/cron.txt.

* * * * * php /app/artisan schedule:run

Note: The cron daemon was designed in such a way that it does NOT execute commands within your normal shell environment. That means your $PATH will not match your container's, and your php.ini memory limit may not be set. That said, we need to supply the full path from within the Lando container to php. Typically, this will be /usr/local/bin/php. In that case, use the following:

* * * * * /usr/local/bin/php -d memory_limit=-1 /app/artisan schedule:run

Next, we need to get cron installed. You'll want to perform this as root during build.

    build_as_root:
      - apt-get update -y
      - apt-get install cron -y

Now, we're ready to fire the cron service. Because cron services all users in a system, it must be started with root priviliges.

    run_as_root:
      - service cron start

Here we are, born to be kings; we're the princes of the the universe.

Oh, sorry, off on a tangent. Okay, we can now store our cron config with crontab.

    run:
      - crontab /app/resources/config/cron.txt

Put this altogether, and you will have arrived.

name: my-project
recipe: laravel
config:
  webroot: public
services:
  appserver:
    build_as_root:
      - apt-get update -y
      - apt-get install cron -y
    run_as_root:
      - service cron start
    run:
      - crontab /app/resources/config/cron.txt

Check that things have gone as planned.

$ lando ssh
www-data@ba70770a45a1:/app$ service cron status
[ ok ] cron is running.
www-data@ba70770a45a1:/app$ crontab -l
* * * * * php /app/artisan schedule:run
www-data@ba70770a45a1:/app$

Enjoy.

Lando and Flask

James Candan — Wed, 12 Feb 2020 14:14:47 +0000

Requirements

You'll need Lando installed, and that's it.

Setting up Lando

Get into your project directory, and get things started with a Lando file.

cd my-project
touch .lando.yml

Name your Lando project and define a python service.

name: flask-example
services:
  python:
    type: python:3.5

Expose python and pip command line tools.

tooling:
  pip:
    service: python
  python:
    service: python

Install Flask

Fire up the container, and let's get the requirements going. From the command line, run:

lando start
lando pip install Flask
lando pip freeze > requirements.txt

Note: It may be the case that this will add carriage return characters to your requirements.txt file. In that case, you may have to run lando ssh -s python -c 'pip freeze > requirements.txt' instead.

Now tell lando that we want it to install requirements during build.

services:
  python:
    type: python:3.5
    build:
      - 'pip install -r /app/requirements.txt'

Build an app

Build your app.py file, specifying the host as 0.0.0.0, with no port.

from flask import Flask
app = Flask(__name__)


@app.route('/')
def hello():
    return "Hello World!"


if __name__ == '__main__':
    app.run(host = '0.0.0.0')

Flask defaults to port 5000, so let's set up our Lando proxy with that port exposed internally.

proxy:
  python:
    - flask-example.lndo.site:5000

Tell lando to run the python app at startup.

services:
  python:
    type: python:3.5
    build:
      - 'pip install -r /app/requirements.txt'
    run:
      - python /app/app.py

Conclusion

Your Lando file will finally look like the following.

name: flask-example
proxy:
  python:
    - flask-example.lndo.site:5000
services:
  python:
    type: python:3.7
    build:
      - 'pip install -r /app/requirements.txt'
    run:
      - python /app/app.py
tooling:
  pip:
    service: python
  python:
    service: python

Enjoy!

DEV Community: James Candan

Shout out to freeCodeCamp's distraction-free VS Code settings

General Settings

Editor Behavior

Explorer and Files

Extensions

HTML and NPM

Terminal Settings

Telemetry and Updates

Workbench Settings

Zen Mode

VS Code Minimalist Configuration

Key Features

Who Is This For?

How It Feels to Use

Customizations

How to Use This Configuration

A ChatGPT About Drupal Conventional Commits

Intro

A Chat About Drupal Conventional Commits

Me:

ChatGPT

Me:

ChatGPT

Me:

ChatGPT

Me:

ChatGPT

Me:

ChatGPT

Me:

ChatGPT

Me:

ChatGPT

Me:

ChatGPT

Me:

ChatGPT

Me:

ChatGPT

Conclusion

Drupal 9+ SEO

Drupal Install with Configs and hook_install()

Secure SSO with Drupal

Full-width, Drupal core Remote Video with YouTube parameters

Overview

Modules

Tips and Additional Bits

FitVids Library

FitVids oEmbed Patch

Configure FitVids for youtu.be

Handle YouTube Parameters

Conclusion

Vuex Airbnb JS ESLint

reCAPTCHA + Laravel + Vue

Table of contents

Prerequisites

1. Provide reCAPTCHA keys

(Laravel) Store environment variables

(Laravel) Share environment variable with front-end

(Vue) Ensure successful share to front-end

2. Prepare the front-end

(Vue) Add reCAPTCHA Vue

3. Prepare the back-end

(Laravel) Add middleware

(Vue) Pass the reCAPTCHA response

3. Error Handling

Lando + WSL2 via Hyperdrive

UPDATE 7/8/2024

UPDATE 9/15/2023

UPDATE 6/7/2022

Intro

Falling short

First, Run Hyperdrive

Update Docker

Then, Get The Latest Lando

Install Terminus Plugins In Lando

Background

Do it

Why this way?