onedarnleyroad/craftcms

A Craft CMS starter project using DDEV for local hosting and Vite for front-end bundling and HMR.

craftcms's Issues

Unpoly integration: automatically detect asset changes

Turbo does this quite smartly:

https://turbo.hotwired.dev/handbook/drive#reloading-when-assets-change

Vite won't start up after a fresh install

Installed already a couple of times following your instructions. But I keep getting the following issue.

` VITE v4.5.2 ready in 329 ms

➜ Local: http://localhost:3000/
➜ Network: http://172.27.0.3:3000/
➜ Network: http://192.168.208.3:3000/
➜ press h to show help

Shortcuts
press r to restart the server
press u to show server url
press o to open in browser
press c to clear console
press q to quit
node:events:491
throw er; // Unhandled 'error' event
^

Error: spawn xdg-open ENOENT
at Process.ChildProcess._handle.onexit (node:internal/child_process:285:19)
at onErrorNT (node:internal/child_process:485:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
at onErrorNT (node:internal/child_process:485:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -2,
code: 'ENOENT',
syscall: 'spawn xdg-open',
path: 'xdg-open',
spawnargs: [ 'http://localhost:3000/' ]
}
Failed to execute command npm run serve: exit status 1
make: *** [dev] Error 1`

Add Retcon-Craft

https://github.com/mmikkel/Retcon-Craft

Handy to have in every install.

Add Async Queue

https://github.com/ostark/craft-async-queue

Critical CSS to prevent FUOC

Very cool Project!
have you tried to include critical css? I am currently working on a similar project and have an issue connected to puppeteer on my Mac M1 Max in ddev web container.
This are the containers specs
Linux craftcms-web 5.10.104-linuxkit #1 SMP PREEMPT Thu Mar 17 17:05:54 UTC 2022 aarch64 GNU/Linux

I used the rollup-plugin-critical https://github.com/nystudio107/rollup-plugin-critical Plugin which works perfekt in an MAMP Environment. Did all the necessary configs for ddev/docker described here https://nystudio107.com/docs/vite/#local-development-environment-setup

Replace sass-loader with precss

https://github.com/jonathantneal/precss

Add Queue Manager

https://github.com/lukeyouell/craft-queue-manager

Add Agnostic Fetch

This is a must-have in our toolset: https://github.com/marionnewlevant/craft-agnostic_fetch

Re-write the default index template

Right now it's Craft's default install, but it might be nice to put our own spin on it.

Add support for vite-plugin-compression?

Update ignore rules so that storage folder is created

There are .gitignore rules within storage/ so we should remove it from ours.

Change template file extensions to *.twig

That's our convention now.

Upgrade to support DDEV 1.19

Add support for vite-plugin-manifest-sri

Set @web alias to DEFAULT_SITE_URL

@web shouldn't be dynamically set in production, so the accepted convention right now is:

1. define DEFAULT_SITE_URL environment variable; and
2. assign @web alias to that in general.php, e.g.

'aliases' => [
'@web' => env('DEFAULT_SITE_URL') ?? null
]

Create a static offline HTML file available in /web

On occasion, we need to take a site offline in front of Craft. For instance, if a big deployment is required, and we need to be able to respond to the visitor with an "offline" message without hitting Craft. With a simple, static "offline" HTML file available in /web, it's easy to create a symlink of index.php and point to this offline file during the deployment.

Remove PHP reference in composer.json.default

We should remove this:

"platform": {
      "php": "7.0"
    }

It creates issues when attempting to install the Async Queue plugin.

Help PHPStorm autocomplete craft api in twig

This: https://nystudio107.com/blog/auto-complete-craft-cms-3-apis-in-twig-with-phpstorm

Update to Tailwind 3

Remove `.ddev` from repository

Version-controlling the .ddev folder is a Bad Idea, since the config's contents will change, depending on what version of DDEV is installed locally.

Use URL Manager to get matched element for CP edit button

Instead of this:

{% set element = craft.app.elements().getElementByUri(craft.app.request.getFullUri() ?: '__home__') %}

We should be doing this:

{% set element = craft.app.getUrlManager().getMatchedElement() %}

The URL Manager already has a memoized copy of the element.

Better environment config for things like seomatic.php

Rather than:

// @var $isProduction boolean
$isProduction = env('ENVIRONMENT') == 'production';

We should just be doing traditional multi-environment config.

Move to using PHP8.1 by default

Ignore `/vendor` IFF we turn on project config

I don't know if this is something we code, can add as part of our (currently non-existent) setup script, or just document in the comments...

Add default _errors templates

We should start with boilerplate error template(s) that give us a better-than-default error page. Centre the logo & text, use tailwind, remove any content that might come from the DB.

`if` conditional no longer available in `{% for %}` loops in Craft 4.x

Contents of templates/_layouts/base.twig should be updated to:

{% for key, message in flashes|filter((v,k) => key in ['notice', 'error']) %}
  console.log('{{ key }}:', '{{ message }}');
{% endfor %}

Add config file for Imager

We should ensure that imagerUrl is always absolute, so that image transforms in things like HTML emails use absolute URLs:

<?php

return [
	// absolute URLs so that transformed images in emails work
	'imagerUrl' => '@web/imager/'
];

Add Knock Knock to default install

https://github.com/verbb/knock-knock

Update to Tailwind 1.x

What the title says...

Add a starter config/one.php

Among others we like to set environment, site version, and google analytics ID to a site-specific config file (so keep general.php clean).

Update dotenv

If we upgrade to the latest way that Craft does it, be sure to also:

• update web/index.php
• update craft
• add boostrap.php

Fix typos preventing successful build

Brilliant Craft 3 starter—one of the few that actually works as expected!

When spinning it up on my machine, I noticed two simple typos that prevented successful building, however.

• Extra y snuck in tailwind.css
• @ alias pointing to wrong directory?

I have a branch on my fork with these changes fixed if you'd like a pull-request.

Add Template Comments to default install

Another useful utility when doing development: https://plugins.craftcms.com/templatecomments

Improve mailer component config, default to mailhog

Instead of hard-coding to Postmark, we should use generic SMTP_ environment variables, e.g.:

SMTP_HOST=""
SMTP_PORT=""
SMTP_USERNAME=""
SMTP_PASSWORD=""

Then in our .env.example we can put in place the Mailhog values that are automatic from DDEV: https://ddev.readthedocs.io/en/latest/users/developer-tools/#email-capture-and-review

Add a standard "creater.php" config for SEOmatic

As outlined here:

https://nystudio107.com/blog/tips-for-using-seomatic-effectively#customized-setup

It is possible to use config/ to set some SEOmatic values, and since our "creater" type details (about 1DR) never change, we should just bake it into this boilerplate.

Makefile command for seeding a db instead of install

At a minimum something like this:

install: up build
  ddev exec php craft setup/app-id \
    $(filter-out $@,$(MAKECMDGOALS))
  ddev exec php craft setup/security-key \
    $(filter-out $@,$(MAKECMDGOALS))
  ddev import-db --src=seed.sql
  ddev exec php craft up

But it might be cool to modify install to accept a flag? e.g. install --seed=snapshot.sql

Use `expose` instead of `port`

See nystudio107/craft-vite#38

Move composer & npm install from Makefile to DDEV hooks

Add this to .ddev/config.yaml:

hooks:
  post-start:
    - exec: composer install
    - exec: npm install

And then our Makefile up command only needs to concern itself with DDEV.

Module idea: a better `knock-knock`

We often need to password-protect a site during development, and while there is this: https://github.com/verbb/knock-knock/

It has some shortcomings, namely that the login template is not at all customisable. And while it isn't too difficult to spin up a basic front-end login form for Craft users, it requires sharing a username/email and password, but typically during the development phase it's preferred to share a memorable and simple password only (so no username/email combo and no need to have a system user).

The boilerplate version could use cdn-hosted Tailwind that could likely be swapped out for a real site's tailwind with little customising necessary. It might also pair nicely with some boilerplate error pages... perhaps there is a possibility of sharing layouts?

`element.isEditable` no longer exists in Craft 4.0

See craftcms/cms#11094 (comment)

allowAdminChanges seems incorrect setting for production

Our general.php config has this:

'allowAdminChanges' => false

Which seems wrong. It makes sense using project config, but we do not use projectConfig, and I can't see us using it any time soon, so we just end up being unable to administer the Production database, which is always supposed the single source of truth in the long run.

Remove our env() function

As of 3.1.18, Craft::parseEnv() will now cast "true" and "false" to boolean values (see craftcms/cms@d2cd439#diff-d8ddf65622d053c914bb35ebd32ae05c). This largely satisfies the needs we were trying to address with the function env() found within modules/onedarnleyroad/functions.php.

Use `@web` for site url

Change from using $PRIMARY_SITE_URL to @web, which I believe is more like the Craft convention. We do explicitly set @web in our general/config.php which is the important thing.

Error w/Default Mail Setup

Are there subsequent steps one should take to have mail working or has something broken? I am not doing more than testing the email config of a default installation.

Add CP Field Inspect plugin

This thing is amazing and I can't believe we've never discovered it before:

https://github.com/mmikkel/CpFieldInspect-Craft

Add watcher to run vite build any time contents of `src/public` change

It's a minor issue, but during HMR dev, Vite won't re-copy contents of src/public. So using something like chokidar to set up a simple watcher, run via concurrently, might be nice.

"with git" proposal: recommend degit over clone, and add init steps to Makefile

Great to see someone's ddev Craft CMS setup!

I tried it out, installing via Composer, and immediately hit #38. Saw the fix was merged, so tried again following your instructions for installing with Git.
My impression: two changes would make it even easier for people to start from the unreleased bleeding edge

• using degit instead of git-clone would obviate the need to manually remove the .git directory
• moving the "clean up and set" commands into the Makefile (not sure what name would be best. make init?) would reduce 4 steps to 1

I can make a pull request if you like the idea.