In it's current form, I don't think this pages adds much. But maybe if extended a little, it could fit under Comparison of contributed modules → .
And this is really, 'delete', not unpublish?
We can of course unpublish, but then in practice it is deleted since no one will see it and it will never be maintained.
Anyway, sorry, it was not my intention to tell what catch meant by "archive".
Good point, quietone. I just read "archive" as "delete" - because I also don't know about an archive for "modern" documentation. (We have an archive for pre D7 stuff.)
It was the proposed resolution, "Archive the entire page, and redirect it to ...", that made me comment on the issue. I'm completely fine with the effort.
> Any page will get outdated if no-one updates it
Sure, but guides that cover "everything" tends to become outdated more quickly. Anyway, that is a different discussion.
I mean at least most of it.
OK, but some people will be very unhappy if Installing Drupal with DDEV in WSL2 on Windows → disappears. Most of the other stuff is dated, indeed. Just like "Installing Drupal with DDEV in WSL2 on Windows" will become ...
Did you mean the complete Local server setup → or the Mac OS subsection → ? I think archiving the complete LS setup is too much.
PS! I find it interesting that we have Set up a local development Drupal site on the latest Ubuntu LTS version and more → (for Linux) and the newly created Installing Drupal with DDEV in WSL2 on Windows → (which is basically Linux on Windows). I think killing the non-DDEV Linux only guide is OK, but in spirit these two are similar and IMO too broad.
I'm so sorry this excellent work never got merge. I don't understand what has happened (and I have gotten the comments notifications - Gmail search tells me).
I'll test, merge and make a release shortly.
Will merge MR after all, but there will be no new release.
Merging didn't seem to change status to fixed. Doing that now. Again - thanks heddn.
Hm, you are right. Maybe a feature - a different redirect list for 404 / deleted pages. I have added redirect for both URLs (again) now.
Thanks a lot for the testing and patch, heddn. I obviously haven't had time to test the module on D11. I was planning to, but paid work ...
It seems you have made very reasonable changes, but I would have preferred one PR for the Mime stuff and another for the Token stuff. Or does the token stuff also break the site? Looking at the issue, you are only pointing to the defines as breakers. Do you mind the extra work?
So, some questions because I'm not following Drupal development closely:
- How long has "type: mapping" in the schema been wrong ...
- How long has "type: mapping" in the schema been wrong ...
- Why do you create a ViewsSendMimeInterface? Is it a requirement? I don't expect there to be anymore implementations of that interface than the one you created?
Again, I really appreciate that you help keeping this module a live. It really should be completely rewritten, but I guess it works well enough for some people as is. Well, not for people on D11. And maybe it was broken for 10.3 also. It seems I last tested with 10.1.5
Removed "theme" from the title as (almost) no other theme doc guides includes it.
Removed "theme" from the title as (almost) no other theme doc guides includes it.
I have added a redirect (for this page) to https://www.drupal.org/docs/extending-drupal/installing-modules →
Will delete the page shortly / in a few miniutes.
penyaskito → credited hansfn → .
Yes, your understanding is correct. WSL is just a virtual machine and needs an operating system (where Ubuntu is supported out of the box).
> In general, the whole section Installing Drupal with DDEV in WSL2 on Windows is confusing to me. It has a lot of information that is not about installing.
Yes, I have written about in other issues. Nothing wrong with the guide itself, but it covers too much - IMO.
Some of the old events looked like they would be a bit large to flatten into a single page, which would be required for moving into community events.
I was thinking just keeping the title - really. Looking at https://www.drupal.org/node/46559 → (as an example) the sub pages doesn't have much value.
Yes, if History of Google Summer of Code → was turned it a doc guide, you could just move the GSOC stuff there.
Is there some way we could migrate the events to d.o - community/events/past-events → The content itself is probably not that useful, but the fact the events took place is nice to preserve.
And maybe all the Google Summer of Code events could be removed - we have https://groups.drupal.org/google-summer-code
I agree - "drupal" as too many meanings in the same command / instructions. "mysite" for the folder is nice.
We could just go ahead and update the drupal-quick-start-command page → , but we need help to update the download page.
Yes, just delete it. IMO it's better to restart a Snippets "initiative" if we think it is useful, but most of this belongs on Drupal Answers now.
@claudiu.cristea: Is your wish that we create a new "Obsolete" doc guide (under "Organic Groups") and then place "Mix public and private files with Organic Groups and File (Field) Paths" in that guide? (That was my interpretation.) Holding back on deletion until this is clear.
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.