🇺🇸United States @eojthebrave

Thanks for your work on this @wylbur.

Adding note about this being docs for D7 and linking to the documentation for current version of the theme.

Approving and adding to the menu for D10/11 contributed themes guide.

Moving to Drupal 8+ themes section.

Approving and adding to the menu.

Approving and adding to the menu.

Approving and adding to the menu.

Approving and adding to the menu.

Approving and adding to the menu.

Updating guide so that sub-pages are automatically approved.

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

Thanks for the reporting this, and for the fix. I've applied it to the dev branch and will get a new release out shortly.

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

Thank you.

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

This looks good to me. Thanks.

Thank you. 🙌

There's an issue for the documentation track here 📌 [META] Track 3: Drupal Starshot documentation Active . And technically Lenny is the track lead, though I've been helping out with the writing work. Right now, my (and Amber's) involvement is with the adopt-a-document initiative where we've helped develop an outline for a getting started with Drupal CMS guide, and the DA has been fundraising to pay for the creation of the content which Drupalize.Me is helping to produce. So it's kind of a weird slice of documentation and honestly I'm not sure how to go about including other people in the process. Though I do think that is something that would be good to figure out.

I know you've had experience with the Drupal User Guide, and I think this will end up being more akin to that than the wiki like documentation currently on Drupal.org. Happy to chat in Slack, feel free to ping me.

And, to the original issue. I totally agree that once there is content written that the Drupal CMS leads are happy with we should link to it from the Drupal CMS UI. It is sorely missing at the moment.

Thank you. I'll get this merged and create a new release ASAP.

Hi @jackwrfuller thanks for reporting this, and for working on fixing it. I think that maybe we should include a backwards compatibility layer as per the guidance in the change record https://www.drupal.org/node/3375748 → . Either that, or we should update the module's info file to indicate that it requires Drupal core 10.2.0+. What do you think? Is this something you can work on? If not, I can jump in and help out.

I tested this out in a couple browsers (Safari, Chrome, FF) and it was fine. So I think I must have been seeing a caching issue. False alarm. Thanks @poker10 for double checking.

This MR changes the background color to white, like the example image in the OP. If there are more specific designs to be implemented here let me know and I can try and update it.

eojthebrave → created an issue.

eojthebrave → created an issue.

I've addressed all the feedback in the review so this is now ready for another pass.

Looks fine to me. We'll have more polished documentation related to trying Drupal CMS versus contributing to Drupal CMS in the future and at that point we can update this README to link to that. But this totally works for now. Thank you!

I added some changes with my initial thoughts on what a more complete README should contain.

My biggest question is regarding the content about using `composer launch` and whether we want to include that at all? Personally, I think we should recommend DDEV in the README and then maybe provide a link to other options. I think limiting the number of choices, and therefore decisions, someone has to make to get started will help make it easier for most people.

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

Related (not sure if this needs a different issue or not) there's a link on the default dashboard for "Learn to build with Drupal" which is now broken because Help module is no longer installed.

Good catch. Thanks @shderuiter.

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

Updated. Thank you.

Thanks for the update. I've applied it. And it'll show up in the guide in the future.

I can confirm that `http_client` is a service that is defined directly after an alias, and it also does not show up on the list on api.drupal.org for Drupal 11.x.

eojthebrave → created an issue.

eojthebrave → created an issue.

I addressed @thejimbirch's comments in the MR, thanks for the feedback. And added the additional test running examples that @phenaproxima brought up to the proposed text for the Wiki.

Regarding the information about x11 I admittedly have not set this up personally. I think ideally we link to other existing documentation. I'll have a look at the issue you linked and see what I can figure out.

Personally, I set up my local Drupal CMS instance with x11vnc and noVNC on the web container so that I could watch/run the cypress UI via a browser (more like a browser in a browser ... it's a bit of inception, but it works). Do to this I changed the .ddev/config.yml file:

name: drupal-cms-dev
type: drupal
docroot: web
php_version: "8.3"
webserver_type: nginx-fpm
xdebug_enabled: false
additional_hostnames:
  # @see nginx_full/trial.conf
  - drupal-cms-trial
additional_fqdns: []
database:
    type: mariadb
    version: "10.11"
use_dns_when_possible: true
composer_version: "2"
corepack_enable: false
hooks:
  post-start:
    # Generate `composer.json` by merging the project template with our internal
    # dev requirements.
    - exec: 'jq -s ".[0] * .[1]" project_template/composer.json dev.composer.json > composer.json'
    # Add the components as path repositories.
    - exec: "setup-repositories"
    # Install all dependencies.
    - composer: 'install'
    # Copy PHPUnit configuration into the web root.
    - exec: 'cp -f phpunit.xml $DDEV_DOCROOT'
    # Install JavaScript dependencies if needed. The `--foreground-scripts`
    # option is needed to ensure the Cypress binary is actually downloaded;
    # see the warning about Node.js Snap for Linux at
    # https://docs.cypress.io/guides/getting-started/installing-cypress.
    - exec: 'test -d node_modules || npm clean-install --foreground-scripts'
    # Makes sure noVNC is available at https://drupal-cms-dev.ddev.site:6081/.
    - exec: 'cp /usr/share/novnc/vnc.html /usr/share/novnc/index.html'
web_environment:
  # For faster performance, don't audit dependencies automatically.
  - COMPOSER_NO_AUDIT=1
  # To display its UI, Cypress needs to be able to talk to an X11 server
  # running on the host machine.
  # - DISPLAY=host.docker.internal:0
  # Download Cypress to a directory that won't be blown away every time the
  # project is restarted.
  - CYPRESS_CACHE_FOLDER=/var/www/html/.cache/cypress
  # Use the DDEV-provided database to run PHPUnit tests.
  - SIMPLETEST_DB=$DDEV_DATABASE_FAMILY://db:db@db/db
  - SIMPLETEST_BASE_URL=$DDEV_PRIMARY_URL
webimage_extra_packages:
  # Add Cypress' system dependencies.
  # See https://docs.cypress.io/guides/getting-started/installing-cypress#UbuntuDebian
  - libgtk2.0-0
  - libgtk-3-0
  - libgbm-dev
  - libnotify-dev
  - libnss3
  - libxss1
  - libasound2
  - libxtst6
  - xauth
  - xvfb
  # Additional browsers for Cypress to test against.
  - chromium
  - firefox-esr
  # Packages for setting of noVNC to watch Cypress tests.
  - novnc
  - x11vnc
web_extra_exposed_ports:
 - name: novnc
   container_port: 6080
   http_port: 6080
   https_port: 6081
web_extra_daemons:
  - name: Xvfb
    command: Xvfb :0 -screen 0 1920x1280x16
    directory: /var/www/html
  - name: x11vnc
    command: x11vnc -display :0 -forever -nopw
    directory: /var/www/html
  # Make noVNC available at https://drupal-cms-dev.ddev.site:6081/vnc.html
  - name: novnc
    command: /usr/share/novnc/utils/novnc_proxy --web /usr/share/novnc --vnc localhost:5900
    directory: /usr/share/novnc

And now I can run ddev launch :6081/vnc.html and it launches to watch the results of ddev exec npx cypress open. Which might be a bit more portable. Though I can't say if one approach is better than the other for any reason.

I've added some draft text for the Wiki to the issue summary. And created an MR with updated docs for the code in the e2e.js file. I think this is a good start. Happy to add anything else that people might find helpful.

eojthebrave → created an issue.

Is there a reason this was moved back to "Active"? I updated the text in this commit https://git.drupalcode.org/project/user_guide/-/commit/5ac64e16f494d96d5.... But if there's still something wrong please let me know. For now though I'm going to move this back to "Fixed".

I've just updated the screenshot (including in all the translated versions) with a new one that shows the correct modules (Search, History, and Ban which matches what is in the current text after recent updates) being uninstalled. Thanks for pointing this out.

Fixed this one too. Thanks again for pointing out the mismatched text. This will be live on Drupal.org the next time the guide content is deployed.

Good catch, and thanks. Looks like I forgot the update the text when I updated the screenshot. Oops. I've updated the text in the source files and the next time the guide is deployed to Drupal.org it'll be updated there too.

Thank you for pointing this out. I've updated the text in the source files and the next time the guide is deployed to Drupal.org it'll be updated there too.

Thanks for making the new page. I think it looks fine, though I suggest moving it higher in the Installing Drupal guide to make it more prominent as I believe the goal is to guide people to DDEV as quick as possible.

Fix minor typo.

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

This update is going to have breaking changes so I think we should create a new 6.x branch, and start with a 6.x-beta or something like that that indicates I think this is working (at least in my tests) but you should also do your due diligence if upgrading. We could also have this new branch drop support for Drupal 9.

breidert → credited eojthebrave → .

The MR updates the module to work with the latest release of the Recurly PHP SDK. This required making a lot of updates to the code since the way the Recurly PHP classes are used is different in the current version than the older v2 SDK the module has been using. Hence the need to touch so many different files. I've tried to stick to only updating the API integration and not changing any of the modules functionality. I've verified this work so far through a combination of manual testing, the tests included in the module, and via Drupalize.Me's e2e testing suite.

Update summary to remove text about module being part of core (it's not anymore) and add a note to the main content of the page about the history of the module as part of core but not in contrib.

That's my preference too so +1 from me. Thanks!

I believe the phpstan tests are failing here because 📌 Update templates so 11.0 is the default/current branch RTBC is changing the GitLab CI default major version to Drupal 11. And Tour module was removed from Drupal 11.

eojthebrave → created an issue.

eojthebrave → created an issue.

Formatting updates, and adding some information about when to use annotations vs. attributes.

@poker10, that's a great question.

There's no final decision about format that I'm aware of at this point. Right now Lenny is the track lead for the documentation track. Amber and I helped created the POC work linked above as part of having something to show in the demos at DrupalCon. But I don't know of any plans beyond that initial POC.

If you've got suggestions for format I would certainly love to hear them. And I suspect others would as well. The formatting for the current POC work was totally me basing things off what we had previously done with the Drupal User Guide and I'm not personally tied to it.

Un-publishing and directing to  https://www.drupal.org/docs/8/api/migrate-api/migrate-process-plugins/li... → instead.

Updating menu item text, and adding a redirect to this page from  https://www.drupal.org/docs/8/api/migrate-api/migrate-process-plugins/li... → because the content from that page was merged with this one and that one is no longer necessary.

Okay. I'm going to redirect this URL to the new page, and then un-publish this one.

Should we remove this page and redirect to the other one?

Woohoo! Thanks for sorting out that CI weirdness. 🎉

Adding credit for Amber who helped with copy editing and reviewing the content.

Yeah ... I have no idea how to debug that one. But as a trial I'm going to just remove all the changes to the .gitlab-ci.yml file that this MR introduces and see what happens. That should at least tell us if it's something related to those changes or not.

Sorry about the mess of commits. But I was able to simplify the GitLab CI config based on your suggestions and it's still working. Thanks.

Sure! It's mostly copied from here https://git.drupalcode.org/project/gitlab_templates/-/blob/main/.gitlab-.... I found that while trying to figure out how cspell was being run for contrib projects. And while that's not the implementation in the gitlab templates for Drupal projects it seemed to work. :)

Then I paired that job down to just the cspell related bits. It's probably possible to remove the `exit $EXIT_CODE` related stuff since it's only running a single check in this case instead of multiple. Let me try that and see what happens.

Thanks for the feedback.

I've cleaned up the .DS_Store file, added Amber and I to the CODEOWNERS file for the /docs directory. And added a job to run cpsell on the docs directory. This is my first time setting up cspell + GitLab so while it's working, and passes, that part could use a review.

At some point in the future I think we should look at tooling that not only checks spelling but also enforces a style guide (always use Drupal, never drupal, always write "contributed module" never "contrib module", etc.) But for now I think cspell does enough.

Ready for another review!

eojthebrave → created an issue.

The MR contains my proposed resolution. Here are screenshots showing what it looks like with the CSS updates.

Claro:

Gin:

eojthebrave → created an issue.

Whatever we do here I would like to see us reduce the burden on the DA for maintaining one-off infrastructure and workflows that the current system creates.

Personally I would love for this to remain in Git, and not become standard nodes. For all the same reasons outlined when we originally decided to go this path. I think it lends to better editorial control, consistency, and supports things like translations in a way that would be really hard without VCS. And selfishly, as the person who currently does the majority of the content and screenshot maintenance for the guide doing so via editing individual nodes would be a nightmare.

If we keep doing the importing to Drupal.org as nodes I think moving the build process to GitLab and creating the HTML artifacts there would be fairly straight forward, and a great idea.

The feeds import process and surrounding customization would need to be rebuild for Drupal 11. This is not ideal for ongoing maintenance.

We also import the user guide content on Drupalize.Me, and use a custom migrate source plugin and a couple of migration YAML files that's far less code, and easier to maintain, than the asciidoc_feeds code used by Drupal.org. I'm happy to share that work if it's ever useful.

The user guide is not part of www.drupal.org and does not appear in Drupal.org site search.

This for me is a big reason for not using GitLab pages (or Mkdocs) or anything else that is self contained. I'm worried that it potentially makes it less discoverable. I'm not opposed, something like learn.drupal.org could be cool. But I think burying it in GitHub pages could have a negative effect on people's already pretty negative view of Drupal's documentation. There are some benefits to going this route too, if for example we built a static site out of the user guide it could potentially be more shiny and have a different kind of impact on people's perception of the documentation. I think ideally if we do go this route that the site is themed to be consistent with the Drupal.org brand so that it continues to be as official as possible.

Converting to Markdown is an interesting idea (aside, there are static site generators that support asciidoc natively). Doing so would require figuring out a few technical things, here's a few I can think of off hand:

• Ebooks. Asciidoc has far superior support for ebook generation. Though I'm sure it's possible with Markdown. Probably requires something like converting to a single .md file, and then using pandoc to create the books.
• Markdown doesn't support reference style links. In asciidoc for example we can do [[extend-module]] and it'll be converted to a link to the document with that ID and the text of the link will be the title of the document. We use this a lot in the content of the guide. I'm sure we could come up with a custom solution in Markdown, but that's a thing we would need to figure out.
• Indexing. Asciidoc supports the creation of an index by using ((Term,term)) style metadata in documents. This is another thing we use a lot. And again, could probably be figured out with some kind of frontmatter in Markdown but isn't something Markdown supports natively.

I've tried using tools like pandoc in the past to automate conversion to Markdown as an experiment. But because we use features of asciidoc that have no Markdown equivalent it fails pretty miserably. So the conversion would either be manual. Or someone would need a script a custom conversion tool.

I think it would be a significant amount of work to convert things. And I'm not convinced that doing so would suddenly get more people contributing. Personally, it doesn't make much difference to me if I'm editing the files in asciidoc or markdown so I'm happy to do either.

And ... I think that if it is converted to markdown there are a lot more options for using something like Mkdocs and just general support in that many more people use Markdown on a regular basis.

Fix typo in issue title.

Drupal 11 requires PHP 8.3+

eojthebrave → created an issue.

This was completed in the 11.x branch.

Thanks for the review and copy edits.

Also, I just used the GitLab WebIDE to search for links to the deleted file ...

Yes, I did a search through all the English language source files and the string `install-manual` is no longer present in any of them.

Okay I've made significant updates to the MR and it's ready for another review. This update:

• Updates the pages about applying module and theme updates to remove the use of the Update Manager UI and only recommend using Composer. The Update Manager UI isn't really compatible with Composer, and long term we should stop recommending it and wait for Automatic Updates. This also required updating some screenshots.
• Remove the content about installing core from a .tar.gz file completely.
• Update the content about manually installing a module or theme that was previously about using a .tar.gz file to be about installing custom modules or themes that are no available via Composer.

> I created an issue about adding DDEV.

+1. I totally support this. And I appreciate you opening another issue for it since I think it's something we can tackle after we get an initial Drupal 11 version of the guide published. It's been on my to-do list, but lower priority than getting the required updates addressed first.

eojthebrave → created an issue.

Another option would be to remove the content about using .tar.gz files completely. And focus on Composer only. Which seems like it might be a good idea given the issue linked by @quietone. 🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active . Which is recommending that for core at least the option to install Drupal via .tar.gz be removed.

And while the option to use .tar.gz files for contrib might still exist it is not the recommended way so we shouldn't be promoting it.

I'm going to work on an update to this MR that removes the manual install instructions completely. Anyone have objections?