Removed references to D8. Keeping description less than 1000 character.
Removed dead / hijacked link to guide. Using headers for questions.
@gribnif: Thx for the report. It would have help if Drupal also reported the DB server, SQLite in this case. Feel free to file an issue in the Drupal issue queue → . (Further discussion here isn't useful.)
Title is just module name - not description. Moved link to project page to running text.
We list modules with just the name - not short descriptions. Added link to project page.
Thx. The placement of "Book: Drupal 7 – the Essentials" was perfect.
"we can update this page, and keep it up to date." - this attitude doesn't scale IMO. (I know you can handle it, ressa, but when you move on ...)
NB! You are abusing the package manager when you explicitly install all packages. The PM should handle the dependencies. That simplifies upgrades and so on. Your list should match only the extensions explicitly listed on the PHP req → . page.
PS! The local dev page I linked to wasn't about DDEV. It was the Ubuntu specific guide; that I also want to remove - LOL.
Regarding matching extensions with packages: (I have read what you wrote - you know that.) If you had used "composer check-platform-reqs" you would have been told that the filter, hash, pcre, session, spl and zlib extensions were already installed (because they are part of PHP core package). I think the rest is straight forward. (People running their own VPS should know the package manager - having a VPS is a big responsibility.)
And if the requirements for Drupal changes, we have to update this page. And if the distros changes their naming, we need to update this page. (The problem with the Laravel discussion I linked to was the version numbers - at least three answers were correct at some time. We avoid that here by using package names without versions numbers.)
Yes, I know having a VPS for deploying a site isn't the same as local development, but setting up PHP, databases and so on is identical. I think we are duplicating information.
Regarding your install command: 1) What if you are using Nginx? Then you better not install "libapache2-mod-php" as it will pull in Apache, I guess. 2) No need to include "php", "php-common". They are always pulled by they other packages. And 3) the composer package requires php-cli which requires php-opcache and php-readline. No need to include those either.
Anyway, sorry about another long reply. Someone will probably approve this page, but I'm reluctant.
I'm happy to see that the page has been (re)moved from the requirements guide. Probably the PHP requirements page need a review. I'll see if I get time.
Anyway, I think this page is a little bit counter productive as we are promoting DDEV as the development environment. Most hosting services (for PHP applications) have most PHP extensions enabled by default. If you are paying for a dedicated server and you set it up from scratch, the best starting point might be Linux development environment → .
Since Drupal depends on Composer to get started, we should recommend
composer check-platform-reqsto check what extensions are required and missing. Before I learned about that command, I just started the installation process and followed the guidance given by the installer - about missing extensions and so on.
IMO: Listing the actual commands for a specific package manager at specific time is not the way to go. (An example for Laravel.) We should write something like: "Install the missing PHP extensions using the package manager (PM) for your operating system". There are multiple PMs for Linux and several for Mac and even some for Windows. And people will Google it if necessary. And the Linux distros change packaging from time to making it even hardere to maintain.
Thank you for the report. I'll fix this. Configuration inspector seems like a nice module
I totally get that URLs like
www.drupal.org/docs/extending-drupal/contributed-modules/contributed-module-documentation/some-module
is too long. That is a side-effect of the decision to always use "automatic URL alias". That is another discussion.
However, I object to "randomly" creating very nice URLs for just one module / project. This doesn't scale. Anyway, the created redirects doesn't hurt anyone ...
Finally, I don't think the documentation for " Distributions and Recipes initiative → " belongs under " Contributed module documentation → ". I think it fits much better under " Drupal Recipes → ".
Hi! This info doesn't belong under "System requirements" IMO.
And do we really want this information in the Drupal docs? To me it's a clear no.
If you use a Debian (or Ubuntu) server, you should learn about apt elsewhere. And listing the package versions / names isn't very helpful when the information is outdated and the packacge complains that the package doesn't exist. At least use the dependency packages - "php-gd" instead of "php8.2-gd" or "php8.3-gd".
Please use our support → - and don't spam us.
Added link to project page and fixed a spelling "error". (Sorry, if "focussed" was intentional.)
Still using BigPipe? Please test without.
Minor adjustments trying to make the pages easier to maintain. Drush info corrected.
Trying to improve the header situation a little bit, but a rewrite is probably need.
Thx for report and sorry about the late reply. I'll see if I can reproduce this. Some questions:
- Did it work with BigPipe enabled for Drupal 9.5?
- Does it work without BigPipe enabled for Drupal 10.2.2?
- Which mail sending modules are you using?
Thx, TR, for actually responding to my comment - I appreciate it.
Yes, listing external dependencies on the project page automatically based on the composer.json file would be nice.
@veverka42: I have confirmed you now so you should be able to edit the page.
Just a minor comment: Shouldn't tecnickcom/tc-lib-barcode be listed on the project page to give proper credit?
Adding "module" to title to be consistent with other core module documentation.
Approving / adding to menu, but I think this (and some other existing pages) should be in an separate "Tips and tricks" guide. Can wait until there are more pages, maybe.
quietone → credited hansfn → .
@balu Yes, I see that we might be too eager to clean up. Maybe better if you add your voice to the issue → .
Some suggested changes to the "How to migrate documentation" list:
- First, visit the appropriate new home for the documentation, and create a new documentation guide for your project (if it doesn't exist).
- Secondly, find the old documentation for your module, theme or distribution. There may be a link to the documentation on the project page in the lower right. If not, search the Site Building Guide book for your module, theme or distribution.
- Follow the instructions in the yellow section at the top of the documentation to migrate the pages.
- Finally, after the pages are migrated, edit the project page. Scroll to the bottom, select Resources and add the link and text for the migrated documentation.
Open questions:
- How do we track which documentation in the Site Building Guide that we have created issues for? Google Docs spreadsheet?
- Should we in the issues we create, link to the documentation to be migrated? That removes the "find" step in the list above.
- Since most of this documentation is for D7, should the links after " For modules the new home is" be to the D7 docs? For example https://www.drupal.org/docs/7/modules →
- Deadline?
I think I will answer yes to the first three. I guess Drumm should set the deadline, but if not - 1st of October?
Not sure about the placement at the root - see bottom of the docs root page → . Maybe under Understanding drupal → is better, but more hidden? We can keep the short URL.
Thx for taking a stab at this. I have added it to the menu. (You fix "This is a Drupal 7 version of the glossary"?)
I agree that we can remove terms that aren't Drupal specific, but it would help if we could link to a really good resource for programming / computer terms in general. Not a stopper for starting cleaning up.
Title should be module name (as all other modules). Used phrase from title in first sentence.
Added link to project page instead of as related content. And fixing URL alias.
Approving / adding to menu since I suspect the AI maintainer won't be notified.
This page is already planned (batch) deleted as part of #3442307: Decide what to do with 'Tutorials and site recipes' → .
I could starting deleting single pages, but ...
PS! And on top of this we have #2762837: Migrate documentation into the new system → .
Yeah, I missed canonical. It seems to explain the decent search results for Symfony.
The bad search results are more serious when moving between versions is hard.
No, we should list older versions and redirecting isn't very user-friendly if you need to read the old docs.
We need to fix the issue with bad search results in another way. We probably need to use "current" or something.
By the way, this is the docs list from our friends at Symfony:
Could we ask them what they have done? It doesn't seem to be robots-related - neither robots.txt or robots header explains this:
Google search: intitle:"The HttpKernel+Component" site:symfony.com
But anyway, would you say it's almost certainly a mime mail problem?
No, not necessarily, it could also be that Views Sends is trying to set another sender. But Mime Mail is old ...
We just sent Drupal password reset mail from this system/domain and that got a 10/10
Switch the system mails to ‘Mime Mail’ via the ‘mailsystem’ and see if you still get 10/10.
Sorry for putting all the testing on you, but currently I don't use the module in production myself. I only test it using DDEV (and mailhog).
Thanks for the report. I'm familiar with SPF and DKIM. Which mailing sending module do you use?
This module doesn't really handle the mail sending part - it's left for the mail sending module that your site is using. Have you checked that normal Drupal messages works (with the same mailing sending module)? If so, I'm happy to investigate if the misconfiguration is in Views Send.
apaderno → credited hansfn → .
Reading your experience with migrating the Organic Groups documentation, I remember that I had the same experience long time ago (when we started migrating stuff). It is too much work for us to handle. I suggest:
- For guides that cover modules with D7 release, we create a critical issue (in the corresponding project issue queue) saying something like:
- To preserve existing module documentation in the the old site building guide, you (the maintainer) have to migrate the content within [a date or a duration]. If the documentation isn't migrated withing the deadline, it will be deleted to enable migrating drupal.org off D7.
- Then in the issue description, tips for migration could be inserted - like creating the D7 docs guide first, so you have some where to migrate the content. It makes sense that the maintainer creates the new doc guide, so the ownership is correct.
- Finally, we could ask for an update of the documentation URL on the project page. (To get a name instead of an URL displayed, you need to select a doc guide from the new system.)
- For guides that cover modules without a D7 release, we mass delete - please, drumm
Automated message: (to be deleted) guide deleted. Moving its content one level up in the documentation hierarchy.
Hi, jacobdgm! The only thing that is needed is some kind soul to verify your account which I just did. Please feel free to fix the issues you discovered.
Yes, making the command shorter is nice. Since the checkout command also reports which branch it switches to, no information is lost.
Automated message: temporarily deleted guide deleted. Moving its content one level up in the documentation hierarchy.
Automated message: temporarily deleted guide deleted. Moving its content one level up in the documentation hierarchy.
Thanks for the commit. It does solve the reported problem since there are more than 100 modules with documentation. However, this will look ugly for themes for a long time. I think I would have preferred a smaller number :D
Anyway, I can create a new general issue for large generated TOCs. The very long scroll for contributed themes isn't very user-friendly or nice on the desktop either.
LGTM :-)
Yes, .node-type-guide .top-right-content #contributed-module-documentation should do, but it breaks if the parent guide changes name from "Contributed module documentation" to say "Contributed modules" (following the IA for
themes →
).
Trying to improve headers (so automatic TOC displays nicely).
Thank you for the interest (and first MR). I don't think this is sufficient since you break the placements of TOCs.
Random example:
https://fjgarlin-drupal.dev.devdrupal.org/community/contributor-guide
https://www.drupal.org/community/contributor-guide →
If we want to move it, we probably have to do it only for the module documentation.
I think a better and more robust solution is to make the TOC for module documentation a (searchable) dropdown. Even if you get it at the bottom (as you did) it is useless for navigation ...
Another simpler solution is just to hide / remove the TOC when you are on the start page for the top level doc guide for a module. If you want to see all modules you can use the bread crumbs to move one level up where all doc guides are listed anyway.
Just adding duplicate issue as related.
This has annoyed me for a long time. Duplicate of 📌 Display of module documentation on mobile Fixed .
PS! Your "movie" is of course better than my text only issue.
Then the obvious question is: Why isn't it listed on the Drush page? Do you automatically get all this info if migrating / upgrade with Drush? If not, ...
Regarding "human readable language for severity". 1) The error from Drush is rather clear. You are able to modify the command. Using just a number like 4 requires that you explain what 4 means. 2) That Drush doesn't handle English (source code language) in addition to to the language of the site, is IMO a bug. We shouldn't discuss this further here, but maybe you have time to file a bug report?
The main harm is duplicating information. Couldn't you just link to the relevant section of the Drush page? (I'm just assuming it's already listed on the Drush page?) In addition, I think we should try to keep the pages focused ;-)
Regarding, the command: Isn't it better to use --severity-min=Warning and so on instead of numbers? And "To include warnings, use --severity-min=4" sounds wrong - aren't you excluding Notice and lower?
To me it feels strange to include Drush commands here. There is a separate page for doing this with Drush, and if you have chosen to use the browser upgrade approach info about Drush is just distracting - IMO.
Yes, I'm observing the same. Basic comments:
- As long as the announcement link to the release notes and not back, we are basically already saying that the release notes are most important.
- If we want an X.Y announcement to be listed before X.Y.0 to X.Y.N release notes, we need the release notes to link to the X.Y announcement.
Not sure we can do that much SEO - headings seems to be a propriate at least. And the pages are just different - short versus a wall of text.
A side note: Should we create an URL alias https://www.drupal.org/blog/drupal-latest → that always links to the announcement for the latest release? Just like we have https://www.drupal.org/latest-release → / https://www.drupal.org/download-latest/zip →
I think "Drupal 7: The Essentials" goes deeper than the user guide in some topics - part B and C which covers Views and Rules (and more). I just loved the work that Johan Falk did which makes it hard for me to just "throw" this out. However, you are right, it will never be maintained. Then again there is probably plenty of low quality D7 docs that are already migrated. I end up wanting to migrate this even if it just an archive.
A big resounding yes from me. Testing the project browser on D10 and getting a lot of old D7 stuff from the project pages is a problem. Maybe a mini initiative to update using the template would help? In particular when the project pages only can be edited by the project owner - they are not a wiki.
PS! We also have the "new" feature that enables copying the readme ... It's not easy getting all of this right.
Removed useless tags and some formatting and link improvements.
Some link tweaking in issue summary.
Some random comments to jwilson3 above:
- "Update the Node title and URL alias to something even shorter. E.g. /docs/develop/ddev-local".
Yes, short and nice URL aliases would be perfect, but I have been told that we should leave automatic URL aliases on - multiple times. Then the URLs tend to become very long ... Anyway, I think the use of URL aliases might need a separate issue - I think we should avoid repeating information that is maintained upstream. If we can focus on what is truly Drupal specific, that helps. (The DDEV people documents installing DDEV quite nicely.)
- Removal and clean-up is nice, but we have to remember that this is a Wiki. People can create pages about the tools they use. This is how we ended up where we are. I don't mind being strict, but putting everything under "Other" doesn't help. We have to dare to remove stuff
- And finally, a rant: Installing DDEV isn't easy on Windows. That is why we get guides like this → - great work, but repeats too much infomation for my liking.
So, how do we proceed? Consensus by discussing like this takes long time. Maybe just edit the IS and discuss when we disagree ...
it looks like the redirect for /node/27882 got flushed out as well
Not under my control. You can readd the redirect under the settings for the page you created.
Yes, you lack permission. I don't, but got
You tried to migrate over 30 child nodes. Usually a guide consists of a smaller number of pages. To prevent possible mistakes, please select a smaller sub-set of book pages for migration at a time.
In addition OG was missing a D7 guide to migrate to, but I have created that now → and added you as maintainer. You should be able to migrate (in multiple steps). Or maybe delete the D6 stuff first gets you under the 30 child node limit.
Editing link display in IS.
- I deleted 27882.
- I can migrate directly into any module documentation guide, but not the general docs. It would help if drumm relaxed the conditions now to get the pages faster migrated.
Readding two missing anchors used by core. All other previous anchors match automatic anchors and they shouldn't change since the header is the module name.
Sorry, I was afraid I broke some important anchors. The simple way to avoid breakage in the future is to never insert anchors manually, but just use headers (and don't change the text of the headers).
Remove "module" from menu and use automatic URL alias as all other modules.
I have reviewed / skimmed Videos and slides → and it's filled with dead links. In addition, if a video is a good resource for say a module, it's much better if it is listed directly in that documentation. Strong delete from me..
I have reviewed and cleaned up Tutorials → . Even if some of the content is still relevant - and even for (early) D8 - I think it's just too random. We should focus on creating new tutorials for D10 in stead. Strong delete from me..
Using h3 instead of list items to get TOC and automatic anchors.
Adding to menu (and using automatic URLs as all other modules)
Adding to menu (and using automatic URLs as all other modules)