🇺🇸United States @eojthebrave

Thanks @mortona2k.

eojthebrave → made their first commit to this issue’s fork.

In #3095736: Create content for Drupal's initial "Getting started" page (after minimal or standard profile installation) → we added some friendly welcoming content to people's first experience with Drupal (at least if they install the Standard profile). And I think something like this could fit well into the new installer experience. For example maybe a welcome message ("Congratulations and welcome to the Drupal community!"), a CTA to "join the community" and a link to resources for finding more help and relevant documentation could be included in the landing page / dashboard in wireframe #4.

This could act as both a way to recruit people into the community. And, as a way to reinforce that Drupal is backed by a large community and that when you "buy" Drupal you get access to that as well.

This makes sense to me. Thanks for the fix.

eojthebrave → made their first commit to this issue’s fork.

You're correct, the module doesn't currently handle this. It looks like this is a setting that you add that is specific to the recurly hosted pages configuration. And I'm not seeing anything about it in the Recurly.js docs https://recurly.com/developers/reference/recurly-js/, or any way to get at the setting via the API https://recurly.com/developers/api/v2021-02-25/index.html. So I'm interpreting this as something that should be done in the implementation code (aka Drupal in this case). Maybe via hook_form_alter()?

We could add a setting to the Recurly module that includes a terms of service field and then add that to the form on the Drupal end as an option.

There's also this page https://www.drupal.org/docs/official_docs/local-development-guide → which which was originally written as part of an earlier initiative to be opinionated and brief. This page is currently linked in the top level "Resources" tab in the navigation. And I think provides a good foundation for the documentation that would get someone from zero to DDEV + Drupal running the fastest with the least amount of documentation duplicated from the official DDEV docs.

I think this page, or its content moved somewhere else, should be the page that we link to when we first tell someone to setup a local environment.

+1. This isn't something I'm likely to work on in the near future but if you or someone else wants to that would be great. I think making some kind of plugin type for doing the embeddings, and leveraging that, would probably be the best way to handle this. Also in my little bit of looking into this earlier I noted that you'll need to use one of the 2 newer Open AI embedding models because those ones support a configurable vector size. The older models do not, and they default to a vector that is too large to store in a Dense Vector field.

I'm going to mark this as fixed. But feel free to re-open if it you still need help getting this working.

This looks good. Thanks.

eojthebrave → made their first commit to this issue’s fork.

The test failures are due to this error:

Drupal\Core\Render\Component\Exception\InvalidComponentException: [avatar] NULL value found, but an object is required in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 203 of core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).

Caused by the fact that the `author_picture` variable in the node template file is sometimes set, and sometimes not. For example if the feature is disabled in the theme, or if the user has no picture. This results in the `avatar` prop getting set to NULL, and the above error. The fix appears to be to not pass an `avatar` prop if we have no value for author_picture. I've added a commit that does that, though it's possible there are better approaches I couldn't figure out a way using Twig to conditionally set just one key in an object.

Let's see if there are any more failures after fixing that.

eojthebrave → made their first commit to this issue’s fork.

"Book: Drupal 7 – the Essentials". I'm not opposed to migrating this but wanted to point out that a lot of this content is duplicated elsewhere in the existing Drupal 7 wiki. My hang up is that this becomes something we move now but that it just continues to remain as archival content (which maybe is fine?).

And while it's maybe historically interesting I think people coming into Drupal at this level today are better served by the User Guide and other more up-to-date resources.

Fix menu weighting

Fix menu weighting

What version of the Recurly library is installed? This might have to do with the fact that this module still relies on an older version of the Recurly PHP library (v2), that isn't currently compatible with PHP 8.1.

If you're getting the newer Recurly library installed it's going to cause issues because things like classes being moved and renamed.

Ultimately this module needs to be updated to use a more modern version of the Recurly library. See ✨ Compatibility with PHP Library 2.10 and above Postponed: needs info .

I’ve done some exploration of Solr’s dense vector fields as a possible way to do neural searching, and things like RAG. And while I was able to get something working with Search API Solr, I think that it’s not a great fit for Drupal until Solr (Lucence) implements some kind of multi-value dense vector fields.

Right now a dense vector field can only store a single vector of up to 1024 dimensions. But, in most neural search and RAG implementations that involve large bodies of text (like a Drupal node) it’s best practice to chunk your text into sentences or paragraphs and generate vectors for those chunks rather than one vector for the entire article. As of Solr 9.1 if you chunk your node into sentences you would either need a field per sentence on the solr document, or a solr document per sentence. Both of these approaches seem … not awesome. Search API very much wants to create a Solr document per node.

There’s ongoing work to add the multi-value vector fields to Lucene but it’s not ready yet - https://github.com/apache/lucene/issues/12313 - Once that’s done however I think this could work well.

It’s potentially still useful today if your use case is vectorizing text that is a paragraph or less. Or things like creating an embedding for an image to make images searchable.

I created this sandbox module as a proof of concept: https://www.drupal.org/sandbox/eojthebrave/3444194 →

Here’s my notes from trying to put together a POC for future me or whoever they might be useful for.

• requires Solr 9+ which added dense vector field support
• add the dense vector field type
  • must be configurable since you need to be able to set the dimensions depending on the vector embedding implementation (e.g. 384 for sentence-transformers/all-MiniLM-L6-v2), and you probably also want to be able to configure similarity type cosine vs. dot_product.
• at index time, convert a field’s text to vectors, and store in the field using a processor plugin similar to the current date range field implementation
  • clean, and chunk, text to send to the thing that transforms it to a vector (maybe chunking and cleaning should be part of the job of the thing that creates vectors?)
  • must be pluggable (openai v. hugging face v. word2vec, etc.)
  • must be configurable - e.g. what hugging face model to use, what chunk size, chunk overlap, etc.
  • This could be a new plugin type that creates embeddings
• at query time use a !knn query
  • Right now the module supports lexical search via edismax, etc. But we need to allow for a K-Nearest Neighbors search q = {!knn ...}.
  • how does this interact with the normal dismax query?
  • do we implement a new parse_mode plugin? Basically, at some point we need to convert the search query string provided by the user (probably pretty much verbatim) into a vector.
    • This can’t be done in a contrib module because \Drupal\search_api_solr\Utility\Utility::flattenKeys will thrown an error when parse_mode_id isn’t in the hard coded lists of parse modes the module supports.
    • If there’s a new parse mode then SearchApiSolrBackend can use that to detect what kind of query to use.
    • It’s possible to combine the results of both lexical and vector searches into a sort of hybrid search - https://sease.io/2023/12/hybrid-search-with-apache-solr.html
    • Maybe modify \Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::search and add in an if/else that checks the parse_mode plugin used and creates a knn search for a new Vector parse_mode. Maybe something like is currently done with more like this queries would work? Tag a query as ‘knn’ and then add a getKnnQuery() method to SearchApiSolrBackend
  • A contrib module could subscribe to PostConvertedQueryEvent events and do something like $solarium_query->setQuery($knn_query); But that’s inefficient as it would just negate all the work the search_api_solr module did to build the edismax query already.
• maybe add the choice of vector embedding creation plugin and configuration for it at the index level because it’s used both when indexing, and when searching, and you have to use the same one for both. You need to use the same logic to create vectors for the index that you use to vectorize the search query if you want any decent results.

Change menu item weight to 0 so it sorts alphabetically.

Remove invalid entity reference from related content.

Thanks for making the updates @sickness29. I've just committed the patch from #15. So I think we can call this fixed now.

Thanks for everyone who has help work on this.

I believe this is resolved in the latest deployment, and the 10.2.x branch. But I can't say for sure. When comparing the 10.2.x and 9.1.x branches (https://git.drupalcode.org/project/user_guide/-/compare/9.1.x...10.2.x?f...) I can see changes between them, and the 10.2.x branch seems to contain bunch of spelling and grammar fixes.

The content currently on Drupal.or is from the 10.2.x branch. Example https://www.drupal.org/de/docs/user_guide/de/preface-scenario.html → (this shows some changes between 9.1.x and 10.2.x in the diff https://git.drupalcode.org/project/user_guide/-/compare/9.1.x...10.2.x?f...).

When you get a chance could you let me know if if you think the currently visible on Drupal.org content is the correct content? Thanks.

I updated the link. Thanks for pointing this out.

Hi @aaron.ferris. I've added you as a maintainer. If you've got questions about the project at all feel free to ping me in Slack. Thank you!

This module hasn't been updated for Drupal 9/10 and off hand I'm not sure what that would require. However, probably not much. The Recurly 5.x module still invokes the same hook that this module uses to do it's job, so I would think that if you update this modules code for Drupal 9/10 it would work fine with the current version of the Recurly module. And I would be happy to give over maintainership of this module to anyone else who wants to actively work on updating it. It's not something I'm using anymore so haven't had the time to work on it.

I added a test that proves this new logic is working. And a message that gets displayed on the page that the user gets redirected too. If you think this is a good approach we can merge this in. Otherwise I'm open to other ideas about how to best guide users.

I wonder if we should add a message ($this->messenger()->setMessage()) and either display it on the page that you are redirected too, or instead of automatically displaying a redirect display a link to the change subscription page instead? I feel like it could be kind of confusing if you click a link that says "Signup" and you end up on a "Edit your existing plan" page without any other context. Thoughts?

Otherwise, yeah I agree this is a bug and should get fixed.

Thanks @loze. Good catch.

eojthebrave → made their first commit to this issue’s fork.

Ha. I have seen this so many times and kept forgetting to fix it. Thank you for cleaning this up.

eojthebrave → made their first commit to this issue’s fork.

My issue ended up being related to the insert_media module. See 🐛 Insert Media sub-module missing .insert-template class on added elements Needs review

I was able to get media_insert working again after making a few changes.

I refactored the code in insert_media.module to make use of hook_insert_styles, hook_insert_render, and hook_insert_variables instead of relying on hook_insert_process to do all the the work. Amongst other things this solves an issue where the insert-template elements that the JS code is looking for where not getting added to the page with the correct class.

I modified Drupal.insert.Inserter.#insert so that it passes the `event` when called and then if successful calls `event.preventDefault()`. Without this, when used with a media library widget, the 'click' on the Insert button would propagate to the "Remove" button for the media entity card. So after the embed code is inserted it would then remove the entity from the media field, and cause the form to reload.

In order to handle the fact that the media library widgets can have multiple values, and each one requires a different insert-template, I added the `$insertElement` as an argument to hook_insert_render(). This allows access to the media entity associated with each Insert button.

Without these changes when you try and use media_insert it:

• Won't insert the embed code because the Handler.js code can't find the template element
• The page is refreshed every time you click the Insert button

eojthebrave → created an issue.

I've done a bit of digging into this today, no solution yet, but what I did find is:

One issue I see is that Drupal.insert.Inserter() gets called 2x in insert.js. The 2nd time it is called with what is essentially and empty `insertContainer`. And the code in the constructor errors out because it can't find the button element in the container because the container is empty.

I worked around that with some hacks just to see if that solved it. That brings up another error though. When you press the Insert button there is a fatal JS error and it causes the page to reload.

The class 'insert-template' isn't getting added to the element, but the JS is looking for it. This is what I see in the page source using Claro theme:

<input data-drupal-selector="edit-field-blog-post-images-selection-0-insert-templates-full" type="hidden" name="template[full]" value="&lt;drupal-media data-entity-type=&quot;media&quot; data-view-mode=&quot;full&quot; data-entity-uuid=&quot;701ec770-c75b-410e-aa60-a5eba282c996&quot;&gt;&lt;/drupal-media&gt;"/>

But it looks like in the JS it's looking for `input.insert-template` and can't find it.

.querySelector('input.insert-template[name$="[' + style + ']"]').value;

I'm not sure why the class isn't present as it's added in the PHP:

      $insertElement['insert']['insert_templates'][$styleName] = [
        '#type' => 'hidden',
        '#value' => _insert_render($styleName, $vars),
        '#id' => $vars['id'] . '-insert-template-' . str_replace('_', '-', $styleName),
        '#name' => $element['#name'] . '[insert_template][' . $styleName . ']',
        '#attributes' => ['class' => ['insert-template']],
      ];

And that's as far as I'm going to get today. :)

It looks like this has been resolved elsewhere. Notably 📌 Add Drupal Gitlab CI Fixed . I just ran phpcs locally to very there are no issues with the current codebase.

joe@10xcontrib-web:/var/www/html$ ./vendor/bin/phpcs -p --standard=Drupal,DrupalPractice web/modules/contrib/consumers/
............... 15 / 15 (100%)

Thank you everyone who helped work on the patch in this issue even though it wasn't the one that ended up getting committed your help is still appreciated.

The update path test was removed in 📌 Remove deprecated UpdatePathTest test Fixed . And the rest of this update looks good to me. Thanks for working on it @IT-Cru.

It looks like you're probably using a patch from this issue 🐛 Cacheability issue when using _consumer_id query in JsonApi responses. Needs work which adds the ConsumeRouteEnhancer class that is causing this error. I'm going to close this as a duplicate and we can sort of the error in parent issue.

Thanks for working on this. I've finally been able to take a look at the code and do a little testing.

When testing this out locally it looks like the code in \Drupal\consumers\ConsumerRouteEnhancer assumes that JSON:API is enabled. Without it enabled I get this error when trying to view a node Error: Class "Drupal\jsonapi\Routing\Routes" not found in Drupal\consumers\ConsumerRouteEnhancer->enhance() (line 50 of modules/contrib/consumers/src/ConsumerRouteEnhancer.php).

Additionally, in that class, this constant is set but never used \Drupal\consumers\ConsumerRouteEnhancer::CONSUMER_QUERY_PARAMETER so could probably be removed?

And maybe I'm just not clear on how this works, but if we're going to set a Vary: X-Consumer-ID header, should we also set an X-Consumer-ID header so that it knows what value to vary on?

This is a great addition. Thanks for working on cleaning up all the hard-coded text.

I agree that we can remove this test now. I've committed the patch from #3 to the 8.x-1.x branch. Thanks @sickness29.

Update for latest version of the module.

Adding to the Entity API guide's menu. Update description to remove "Drupal 8".

Personally I'm fine with fixing any phpstan suggestions in a separate issue. And I'm also fine with removing the Drupal 8 upgrade path tests. It seems to me like they are covering a scenario which isn't really something people are likely to encounter anymore.

I've got the tests running in GitLab CI now and with the exception of some deprecation notices they are passing. However the job fails because GitLab CI doesn't provide as much space for saving testing artifacts as this job uses. See errors from a recent run:

Unsilenced deprecation notices (9)
Remaining self deprecation notices (7)
Remaining direct deprecation notices (3)
Remaining indirect deprecation notices (1)
Other deprecation notices (1)
Fail      run-tests. Unknown              0 Unknown                            
    FATAL
    Drupal\Tests\user_guide_tests\FunctionalJavascript\UserGuideDemoTestCa:
    test runner returned a non-zero error code (2).
---- Drupal\Tests\user_guide_tests\FunctionalJavascript\DrupalScreenshotTest ----
Status    Group      Filename          Line Function                            
--------------------------------------------------------------------------------
Pass      Other      DrupalScreenshotT   27 Drupal\Tests\user_guide_tests\Funct
    
$ cp /var/log/apache2/test.apache.access.log $CI_PROJECT_DIR/apache.access.log.txt
$ cp /var/log/apache2/test.apache.error.log $CI_PROJECT_DIR/apache.error.log.txt
$ exit $EXIT_CODE
Uploading artifacts for failed job
00:15
Uploading artifacts...
WARNING: junit.xml: no matching files. Ensure that the artifact path is relative to the working directory (/builds/project/user_guide_tests) 
/builds/project/user_guide_tests/web/sites/default/files/simpletest: found 25 matching artifact files and directories 
/builds/project/user_guide_tests/web/sites/simpletest/browser_output: found 5167 matching artifact files and directories 
apache.access.log.txt: found 1 matching artifact files and directories 
apache.error.log.txt: found 1 matching artifact files and directories 
ERROR: Uploading artifacts as "archive" to coordinator... 413 Request Entity Too Large  id=909322 responseStatus=413 Request Entity Too Large status=413 token=glcbt-64
FATAL: too large                                   
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: command terminated with exit code 1
mand terminated with exit code 1

This is probably because the test suite saves DB snapshots of all the chapters so that it's easier to debug and only run certain sections of the tests. I think there are two possible solutions:

- Increase the GitLab max allowed size of artifacts for this project
- Disable saving of backups by default, and instead make that an option for when the tests are run locally

Looks good to me. Thanks @owenmck.

eojthebrave → made their first commit to this issue’s fork.

Merging this initial pass at tests in so we can run them. This configuration should restrict the tests to just being run manually instead of running on every MR since we only use them to create screenshots and not really to test the module itself.

I updated the e-book build scripts to remove the steps for creating the .mobi and .azw3 files.

I uploaded new ebook files to the linked docs page. So I think we can close this issue.

I also opened a new issue to start tracking any updates that will need to be made for Drupal 11 here 📌 Update user guide for Drupal 11 Active . Thanks for the suggestion.

eojthebrave → created an issue.

Fix heading format.

Add downloads for Drupal 10.

Remove "8" from the description and summary since this isn't specific to Drupal 8.

Switch to using automatic URL alias and remove docs/8/ from the path.

Change status to "No known problems" after reviewing.

Removing 8, since this applies to all modern versions of Drupal. Updating summary.

Thanks for the reminder. I looked into recreating the ebook files this morning and the toolchain is a bit out of date so it's taken a bit more to figure out. I opened a new issue to track progress on getting the ebook files update though 📌 Update ebook files for Drupal 10 Active .

And I think we can go ahead and close this issue since it's superseded by 🐛 Update user Guide content for Drupal 10.2 Active .

eojthebrave → created an issue.

eojthebrave → created an issue.

Good catch. Most of the content was updated in 🐛 Update user Guide content for Drupal 10.2 Active but looks like I missed this one. I've updated it now though. Thanks.

Thanks for continuing to work on this. It would be helpful for me if someone could give me a quick set of instructions for testing this patch. And, should we include tests for this in the code? It looks like there was an attempt at writing tests in #2 but there are no tests in the latest patch.

The 'secret' field is added, and managed, by the simple oauth module. So I'm going to move this issue to that queue where it's more likely to get fixed. Setting the version to 5.2.x-dev as that's the current supported branch. But @borrison_ perhaps you could chime in and let us know what version of the Simple Oauth module you're using when you encounter this.

I like this direction too and was going to suggest maybe Drupal.org isn't the right place for the full nitty-gritty details version and a post elsewhere that's linked to might be better. So +1. Trying to strike the right balance between I can't find the info I need because it's not here, and I can't find the info I need because it's here but buried. Which is something that varies wildly throughout the pages on Drupal.org. :)

Thanks again for your continued effort. So awesome!

There's also this page https://www.drupal.org/docs/official_docs/local-development-guide → which walks you through the steps required to install Drupal using DDEV once you've successfully installed DDEV. Personally I think it would be best to consolidate as much of the "how to use DDEV" documentation into a single page as possible since in theory once you've got it installed for your OS of choice the using DDEV part of it should be basically the same. And there ends up being a lot of duplication if these steps are documented individually for each OS.

Update the guide description to recommend DDEV for anyone just getting started or looking for a recommendation.

Add file path above example code to make it clearer where the code should go. Edit intro for clarity.

I just completed updating the English version of the guide with changes required for Drupal 10.2.x. The two big things were related to the updated UI for adding a field ([#2393181], 🐛 Improve re-use an existing field user experience Fixed . And the changes to custom blocks, which are now under the Content menu item instead of Structure. ✨ Move Custom block library to Content Fixed .

You can find the relevant text changes in this commit. https://git.drupalcode.org/project/user_guide/-/commit/0c9df1d4d123c9c55.... Use this as a reference to know what to updated for translated versions of the text.

I've also updated the screenshots for all languages with new 10.2.x images.

Removing "Drupal 8" from page title since this content is relevant for Drupal 8+.

eojthebrave → created an issue.

eojthebrave → created an issue.

I was able to work around this by adding a new hasCourseInstance field to the Course type and then populating in an implementation of hook_metatags_alter(). My solution adds the 'hasCourseInstance' field, and via the module UI you can add a 'CourseInstance' to the field. But I haven't yet been able to figure out how to add CourseInstance specific fields to the type. Right now it just uses those defined by the Event type.

Do I need to create a new PropertyType of CourseInstance that duplicates the existing Event type and adds the custom fields? Or is there a better way to handle the CourseInstance specific fields like 'courseMode' and 'instructor'?

Here's the plugin code I used for the hasCourseInstance field:

namespace Drupal\dme\Plugin\metatag\Tag;

use Drupal\schema_metatag\Plugin\metatag\Tag\SchemaNameBase;

/**
 * Provides a plugin for the 'schema_course_hasCourseInstance' meta tag.
 *
 * Custom schema.org field for CourseInstance data. Can be removed when
 * https://www.drupal.org/project/schema_metatag/issues/3410151 is resolved.
 *
 * @MetatagTag(
 *   id = "schema_course_hasCourseInstance",
 *   label = @Translation("hasCourseInstance"),
 *   description = @Translation("RECOMMENDED BY GOOGLE. The course instance(s)."),
 *   name = "hasCourseInstance",
 *   group = "schema_course",
 *   weight = "0",
 *   type = "string",
 *   secure = FALSE,
 *   multiple = TRUE,
 *   property_type = "event",
 *   tree_parent = {
 *     "CourseInstance"
 *   },
 *   tree_depth = 0,
 * )
 */
class SchemaCourseHasCourseInstance extends SchemaNameBase {

}

And the code I used to fill it in with the custom fields:

/**
 * Implements hook_metatags_alter().
 */
function dme_metatags_alter(array &$metatags, array &$context) {
      $courseInstance = [
        '@type' => 'CourseInstance',
        'courseMode' => 'online',
      ];
      $metatags['schema_course_hasCourseInstance'] = serialize($courseInstance);
  }
}

In case this is helpful for anyone else.

lostcarpark → credited eojthebrave → .

> GitLab pages site automation seems very cool. Will this eventually replace the Drupal.org documentation areas? If so, we should definitely look at that. If not, the User Guide approach may be better.

I don't think there is a definitive answer to any of these questions yet. As the maintainer of the User Guide I can say that it's a bit of a one off approach, and I'm not sure we should replicate it again. Right now it requires converting the asciidoc to HTML and then using Feeds to import the HTML to Drupal.org nodes ... and it's prone to breaking. Long term I think we'll move to something else, but what that is remains to be seen.

Using asciidoc for the content has been great. It supports a whole bunch of features that Markdown doesn't and that the guide makes use of. Cross references, admonitions, ebook publication, etc. It's just that having a custom to Drupal.org build system means there are very few people who know how it works and can help keep things updated.

I can try and help answer questions about the user guide process though if you've got any.

I wonder if this is related to the default configuration in config/install/datalayer.settings.yml.

And maybe lines like this:

current_user_meta:
  - ''

Should be changed to something like this instead?

current_user_meta: []

I just marked 🐛 Language problem (Russian) Closed: duplicate as a duplicate of this. This isn't something I've had any time to investigate yet FWIW.

Thanks for reporting this. It's a known issue, so I'm going to mark this one as a duplicate. You can follow the other issue here 🐛 Problem with encoding on Drupal.org user Guide for all chars except latin. Active .

I think this is a good idea, and will help lower the burden/barrier of keeping your Drupal sites up-to-date. The proposal seems well thought out. Maybe build in some kind of regular review step? Like at the start of each new release cycle take some time to reflect back on the previous cycle and identify any policies or steps that might need udpating.

Overall a big +1 from me though.

If we're not using the old plan for anything I can think we can probably just remove that from the test? Or maybe update the test so that it will verify that you can change your subscription both with an existing old plan, and a deleted old plan. Which would help to ensure we don't re-introduce this bug in the future.

I'm guessing this is related too 🐛 Problem with encoding on Drupal.org user Guide for all chars except latin. Active . Which despite having good intentions I have no yet had a chance to dig into at all yet.

The changes in MR5 allow me to install and use this module with Drupal 10. The few changes in the MR look fine. And a quick scan through of the code doesn't show any other obvious changes that would be needed to make this D10 compatible.

Once this is merged we should probably also update the documentation on the main project page as the module now puts its settings on the field settings form, and not the field display settings form.

Works for me.

eojthebrave → made their first commit to this issue’s fork.

I wasn't sure if what following that link would do so I clicked it and ... it just brings you to this discuss tab, with a note that says you should add a comment to request being a maintainer.

@dcam, I've added you as a maintainer to the guide. I'm currently listed as one, but that's just because I helped move this content around when it was originally created. I'll remove myself as a maintainer, but feel free to ping me in Slack if there's anything I can help with. Thanks for helping out with the documentation.

One of the original goals of the evaluator guide was to make it easy to throw away when you're done. #2993155: Draft "Evaluator Guide" Outline & Guide → . Versus the local development guide which currently recommends ddev where the expectation is you're spinning up a site with the intent of coming back again tomorrow and doing more.

And I think at that time anyway the agreement was that installing Docker + DDEV meant it was no longer easy to just throw everything away when you're done. That said, I also think there's an argument to be made for differentiating between an evaluator who just wants to see what Drupal looks like and poke around in the UI a little (https://simplytest.me ...) versus I guess an evaluator who wants to spend a day or two poking around at some contributed modules and custom code and is looking for something that's a little more permanent than single use. And for whom tooling like Docker, etc. is likely already at least somewhat familiar.