jon pugh → created an issue.
Color module is no longer included in core, so the example is not installable unless you require it.
@mglaman yep. I thought "Basic site info" would be a good place for it because email is there too. It feels like that form is the core identity of the site.
Also, if Drupal core had this feature, it could set DRUPAL_ENV to prod only if the URL matches. It would be a very simple way to detect environment on any system. No more if/then/else clutter in settings.php.
A comment by Ryan Price on linkedin brought up "trusted hosts"... Maybe we need a "trusted prod hosts"?
I coincidentally installed metatags on my site yesterday, and it has a field "Canonical URL".
Did a little digging. Seems like this could be useful for printing these tags.
https://developers.google.com/search/docs/crawling-indexing/canonicaliza...
Matt: Yes, this is specifically for the prod URL. Can be used both for showing admin users in the status report page, and for detecting if a site is "live" or not.
Added "category" to plugin definition to tell it where to display.
"site" category is for things that don't change across environments, like install profile or install time.
"environment" category is for things that are specific to that environment, such as PHP version and Drupal version.
SiteProperty plugins have been added.
The SiteProperty plugins can replace hook_requirements() for most things.
See https://git.drupalcode.org/project/site/-/tree/2.x/src/Plugin/SiteProper...
Development on this feature has moved to ✨ Add "system.site" service to access information about the site. Active . Keeping this issue for discussing the Main URL field specifically.
Update: After thinking a few days I think "Main URL" is the best human-readable name for this property.
"Canonical URL" is still good for the backend, I think. "Main URL" is a little vague when used in code.
Thoughts?
Like
SiteService::isCanonical() as a universal way to see if a site is "live" or not.
Matt: I'm thinking Main URL is a good human label, but like canonical for the property name.
Open to whatever.
@matt: is the APP_URL for the current site? Or as a reference for the live site?
This is to store the live site so users can see it in status reports etc.
I think the screenshot is confusing. The default value is whatever site you are on, hence "localhost" because I was using PHP CLI server, but normally you would put in a separate domain.
Jon Pugh → created an issue.
Jon Pugh → created an issue. See original summary → .
Could we send this to the new contributors team?
Would make a great first contribution for someone!
Jon Pugh → created an issue. See original summary → .
Jon Pugh → created an issue.
Jon Pugh → created an issue.
I made a library to try and set settings.php for all host providers.
If the host provider doesn't set the env var, we can putenv() from the host vendor code. (Platform, ddev, etc)
Then $databases can always be set from envs.
https://github.com/operations-project/drupal-settings/blob/2.x/Settings%...
Jon Pugh → created an issue.
The file is for devshop, it will need to be updated for aegir.
I'll try to set aside some time this week to do this.
MathMadd I think that can happen if migrate_tools is not enabled which can happen if you installed path_redirect_import before version 2.
Is that a problem people are having? Migrate Tools is not installed?
The dependency on migrate_tools was only added a year ago and I am not seeing an update hook to enable it.
https://git.drupalcode.org/project/path_redirect_import/-/commit/b0c4dd1...
Both modules have made the change needed in dev branches only.
Until there is a new release, you have to require the dev versions.
composer require drupal/path_redirect_import:2.0.x-dev drupal/migrate_tools:6.0.x-dev
To confirm, open up the files PathRedirectImportCommands.php and MigrateToolsCommands.php, and check the namespace.
In path_redirect_import, it reads:
use Drupal\migrate_tools\Drush\Commands\MigrateToolsCommands;
In MigrateToolsCommands it should read:
namespace Drupal\migrate_tools\Drush\Commands;
HOWEVER....
It still doesn't work on my site, because somehow, Migrate Tools was disabled but path_redirect_import is still enabled.
Maybe this will work for you?
Passing to Drupal.org project queue.
Jon Pugh → made their first commit to this issue’s fork.
This is a crazy hack. This patch has to be used in devshop control (composer-based hostmaster.)
I didn't patch against the right repo. new patches attached.
I'm not sure if bad path mappings should be ignored or exceptions should be thrown.
Here are two patches for each possibility.
Attached is a patch for drush 8 to make it compatible with symfony/console 5+, which allows hostmaster commands to run against drupal 10 sites.
Provision has a composer.json file, which can include patches.
Hostmaster can be built using a composer.json file. See https://github.com/opendevshop/devshop/blob/1.x/src/DevShop/Control/comp...
Came across this issue when upgrade a site from 9 to 10.0 using bricks.module.
From debugging I traced it down to this: Bricks.module is now showing a field "revision_id" that does not exist in $field_definitions.
The error comes when trying to run the update hooks so I can't update any schemas.
Applying the patch worked.
Attached is a new patch for 10.0.x
Jon Pugh → made their first commit to this issue’s fork.
Fixed. rc2 coming up.
Patch applied. Thanks!
Removed the patch completely. It's only needed when using views.
I added help text to the README about the patches.
To test:
composer require drupal/site:2.x-dev
For anyone looking, the patch for the above MR can be viewed here: https://git.drupalcode.org/project/drupal/-/merge_requests/4953.patch
Uploading it here for testing.
You can work around this by setting the intercom/intercom-php library version in your composer:
composer require drupal/intercom intercom/intercom-php:"^3 || ^4" -W
Marking needs review to get some attention.
Thanks apaderno!
Strange thing, though ... I'm not seeing content on the planet feed? I went back 3-4 pages.
Can I get this reviewed again? New content is up.
Thanks!
Jon Pugh → created an issue.
DevShop runs hosting 4.x and provision 4.x in a composer platform, which includes drush8.
Then, drush 10/11 is installed globally.
Running drush @hostmaster works, properly passes from drush 11 to site-local drush8 in hostmaster.
https://github.com/opendevshop/devshop/blob/1.x/src/DevShop/Control/comp...
It uses provision 4.x and hosting 4.x branch, which is just a stopgap for current generation. Lots of hacks to get DevShop more stable. I added drush9+ yml alias ge eration so "drush sa" works with both drush 8 and 9+.
If someone wants to take this back to aegir, feel free.
It works.
It looks like the fix to webprofiler in devel never made it to webprofiler:
https://gitlab.com/drupalspoons/devel/-/merge_requests/59/diffs?commit_i...
FWIW I am still getting the error. I had to fully remove the .behat.inc files to get bin/behat to run.
drupal/lightning_core * 5.14.0
behat/behat v3.13.0
drupal/drupal-extension v5.0.0rc1
laura.gates → credited Jon Pugh → .
The problem is that the entity that is referenced is missing.
The new MR is against 3.2.x. It simply returns "" for a label if none is found. This is important because the relation entity still exists, so in order to be clickable, label has to be something.
See https://git.drupalcode.org/project/group/-/merge_requests/107
This is what it looks like:
Jon Pugh → made their first commit to this issue’s fork.
For clarity, this is what I did to cause this error:
In a custom Deriver class, getDerivativeDefinitions method, I changed this:
$this->derivatives[$name]->set('label', t('Organization site (@type)', ['@type' => $label]));
to this:
$this->derivatives[$name]->set('label', t($label));
Instead of doing logic checks, I think it would be simpler to create a setLabel() method so that you could force the parameter to be TranslatableMarkup. There is already a getLabel() method.
Add specifics about Site UUID and config exports.
In order for this to be accepted, please include changes to automated tests to check for additional violations.
I am with you on DDEV. It has much better MacOS support, right? I use ubuntu for daily driver. Even then installing lando takes a deb tweak.
I struggled to get multisite to work in Lando. It would not work properly with a single container.
If you had the bandwidth to submit a MR with ddev config, I would merge it.
Actually I think I fixed this in my most recent branch.
I'm planning on merging today.
See feature/project-fields branch
Check settings.php at the bottom. Sometimes drush adds the MySQL credentials which is wrong. The creds are set automatically for each separate site.
Remove the $databases array and try.again.
Just to confirm, using 2.x branch?
Catch missing user and improve messaging.
Here's what it looks like:
www-data@7840126ff815:~$ drush key:set admin
In KeyAuthCommands.php line 64:
User already has API key. Use --force option to overwrite it.
www-data@7840126ff815:~$ drush key:set admin --force
! [NOTE] User's existing API key was removed.
[success] API key for user admin was set to 9a99e567bbd5983beb318274baf96273.
www-data@7840126ff815:~$ drush key:set admin abc123 --force
! [NOTE] User's existing API key was removed.
[success] API key for user admin was set to abc123.
I created a new branch and merge request to add a drush command: 'key:set'
Patch attached.
MR here: https://git.drupalcode.org/project/key_auth/-/merge_requests/13
I don't recommend this approach in the core module.
However I too need the ability to insert an existing key.
My use case is for testing and development of a number of sites at once. I want to hard code a key into the development settings so that I don't have to generate a new one and set it in the client everytime I install or sync the site in.
To add a key, just set the api_key field on users. Custom code or an add on module for managing keys could be created.
See UserKeyAuthForm::submitForm():
// Generate a new key.
User::load($form['#uid'])
->set('api_key', $this->keyAuth->generateKey())
->save();
Jon Pugh → created an issue.
I would like to take over this project namespace for a different purpose, to track back-end tasks for site module → .
There is a Drupal 9+ replacement for this module, Tasks Module → .
There was a 8.x development release here, but virtually zero usage.
Is it ok to start something new here?
Fixed it! (I think?)
The crazy bundle field definitions we are doing. We needed to reset the keyvalue cache for fields.
Not sure why. Looks like we could make some core improvements here.
I believe this was fixed in the rewrite: https://git.drupalcode.org/project/operations/-/blob/2.x/src/modules/sit...
Please re-open if needed!
Other thoughts...
I would like to separate Site.module from the Site API & Manager connection stuff at some point.
Some sites will just use Site.module for the content entity. I don't think we should force them to enable JSONAPI unless they need to.
Closed as duplicate of 📌 Fix the issues reported by phpcs Needs work
2.x is the new branch. Please rebase the MR.
Same thing happens when saving a view.
Drupal Config API converts these complex config objects to YAML at some point, storing it or writing it to files.
We should research how that happens and do the same when saving it.