Done!
This field is now gone, backup of its data is attached.
Thanks all, this has been deployed.
drumm → made their first commit to this issue’s fork.
This is now allowed for POST requests.
For organization ranking, we can weight this based on project usage, like we do for issues.
Before getting into crediting organizations, we want to make sure people are credited. That means making a release should be highlighted on your user profile page, like https://www.drupal.org/u/catch → . A couple ideas to start:
- A separate listing of “Releases made”, like “Projects maintained,” would be the most straightforward. For medium to large screens, could position to the right of “Projects maintained.” Would need to either count for each project, or see if we need a “more” link if listing them all.
- Merging in with “Projects maintained,” adding a count, would save some screen real-estate. Would need to think about what, if anything, to do when someone who made releases is no longer a maintainer of a project.
Once people are credited, this should guide how credit appears on organization pages like https://www.drupal.org/tag1-consulting → .
For storing the organization metadata, it would be most straightforward to have a field like “Supporting organizations” on projects. That could be a straightforward entity reference field; I don’t think “How they helped” would be necessary for releases. Using the issue-style organization/customer setup would be overly-complicated, but if we do need that, we can follow what we did for security advisories.
Once we have the data for organizations, we should pick where/how to show it on release pages.
I went ahead and deleted the @drupal8changes block from https://www.drupal.org/list-changes/drupal → , since it is just a block, and wasn’t in code anywhere.
Next steps for the field on project pages:
- Remove the display, other references to it, and field configuration
- Make a backup
- Remove the field
Done
I do think we should keep some old versions. If you end up with an old site, or old memory, it is useful to see old documentation, to help track down what has changed.
(Saving to resolve issue indexing issue, please disregard.)
The 3343584-fix-the-issues branch doesn’t actually exist at https://git.drupalcode.org/issue/advanced_title_block-3343584/-/branches.... This was likely the branch that was supposed to be created on forking, but GitLab must not have received and completed that API request.
Since work is happening in other branches, I’ve deleted Drupal.org’s record of it.
Modules & themes were included.
Distributions currently don’t have a great way to check compatibility. Since we aren’t serving them via packages.drupal.org, we do not have this sort of metadata in our DB.
Since going off drush make packaging, distribution support is somewhat undefined. Currently, any distribution still listed as a distribution is either not maintained, or has a special installation process. Distributions on Drupal.org can’t be installed via Composer via any well-defined process.
Many distributions have moved to general projects. A general project with a release and a valid composer.json is installable via Packagist.org. We also don’t keep compatibility metadata on-hand, since Packagist.org handles that. Compatibility checking is possible, but not practical. Some are templates and would be set up with composer create-project, some are dependencies that would be set up with composer require. Then would have to see if the composer command succeeded and/or see what happened in composer.lock. Even if we automated all of that, I fully expect enough edge cases to cause problems.
Last 28 days, Google Analytics data of what people search for directly on https://www.drupal.org/project/project_module →
The top 200 searches from Google Analytics data are:
565 ckeditor
536 commerce
515 webform
373 views
297 menu
286 admin toolbar
280 slider
252 token
248 taxonomy
235 "lazy load"
234 calendar
227 entity
214 pathauto
212 devel
192 ckeditor5
188 view
179 layout builder
174 paragraphs
173 bootstrap
170 migrate
161 rules
160 captcha
154 smtp
150 comment
142 gallery
127 pdf
127 paragraph
126 field
125 image
124 form
123 profile
122 layout
120 carousel
115 address
112 ctools
111 webp
111 seo
111 chat
110 backup
109 admin
108 search
105 entity reference
103 php
102 slick
102 feeds
102 breadcrumb
101 workflow
99 date
98 media
98 google
97 slideshow
96 css
94 video
94 color
93 redirect
92 metatag
90 user
89 taxonomy manager
89 ai
88 popup
83 taxonomy menu
82 mail
81 inline_entity_form
81 group
81 book
81 blog
80 chatbot
78 google analytics
78 editor
76 language
74 wysiwyg
74 filter
74 cookie
73 import
73 imce
73 drush
71 toolbar
71 recaptcha
70 reference
69 twig
68 button
68 api
67 entity_reference_revisions
66 h5p
65 map
65 forum
64 search api
64 openai
63 sitemap
63 poll
63 lms
63 file
63 colorbox
62 ldap
62 field group
62 event
61 table
61 scheduler
61 path
61 password
60 timeline
60 panels
59 drupal commerce
58 node
58 link
58 backup and migrate
58 back to top
57 youtube
57 jquery
56 theme
56 json
56 icon
55 jquery_ui
55 cache
54 select
54 rest
53 shop
53 gutenberg
53 export
52 quiz
52 clone
52 cart
51 ckeditor 5
50 newsletter
50 modal
50 context
49 composer
49 audio
48 optimize images
48 dashboard
48 content access
48 ajax
47 qr code
47 libraries
47 facebook
47 dns-prefetch
47 booking
46 upload
46 tree
45 taxonomy unique
45 facets
44 wordpress
44 views ui
44 linkit
44 fields
43 superfish
43 share
42 ubercart
41 views slideshow
41 opigno
41 events
40 user permissions
40 stripe
40 social
40 gin
39 title
39 smart date
39 glossary
39 database
39 accordion
38 print
38 login
38 block
38 admin_menu
37 slide
37 field_group
37 charts
37 background
36 signup
36 oauth
36 hero
36 crm
36 config
36 accessibility
35 wiki
35 whatsapp
35 email
35 builder
34 simplenews
34 registration
34 memcache
34 ecommerce
34 chaos tools
34 asset injector
33 vote
33 style
33 mercury
33 chart
32 page manager
32 news
32 leaflet
32 flag
32 banner
31 views data export
31 contextual filters
30 twitter
30 survey
30 qr
30 ecwid
30 custom blockThere is definitely a long tail, there were 8,719 unique queries.
I'm not seeing anything in the meta tags of https://www.drupal.org/blog/drupal-10-2-0 → that can be improved. We certainly can change the metatag configuration if there is something specific that can be improved.
We have limited ability to influence what Google decides to show.
What I think might help is more links to the announcement. Linking from the release notes to the blog announcement would increase its visibility and may convince Google to highlight it more. The core release notes template could be updated to mention the announcement.
Since 3.0.x is more-specific, it takes precedence over 3.x. So 3.0.x will remain the dev release for the 3.0.* series.
I recommend using 3.0.x until you are ready to start making divergent changes for the 3.1.* series. At that point, make sure everything from 3.0.x is merged into 3.x and continue using 3.x. Then 3.0.x will be for any back-ports that are made.
The fix for this has been deployed.
This has been deployed!
Thanks, I’m concerned with the label taking up too much space, so I made it smaller.
This message is technically correct, packaging is queued. A new zip file for Composer is not regenerated, so it is effectively a no-op. However, packaging also includes updating packages.drupal.org, updates.drupal.org, and some other processes. For some edge cases, this does something for the release.
We could potentially skip showing the message, or show a different message, when you are viewing a tagged release with files already attached.
drumm → changed the visibility of the branch 3448894-make-showhide-branch to active.
drumm → changed the visibility of the branch 3448894-make-showhide-branch to hidden.
🐛 Classes missing from Drupal 10 Fixed has more context about the recent upgrade, comments were removed mid-March.
The ability to log in and make new comments is not planned to come back. While we could restore the comments for the Drupal 7 documentation, that would be temporary. As soon as a Drupal core API changes enough that API module’s comment integration needs updating for compatibility, we plan to drop that instead. This is not functionality that has not had an active maintainer, and removing commenting greatly simplifies the site.
A rating system would be a large lift, see #50605: Add user ratings for projects → for some background. In short, there are a lot of details to figure out like:
- Are the ratings on the most recent version more important or the only ones to consider?
- Or use all the ratings across all versions? Some sort of weighting?
- Need to establish additional moderation for new user generated content - handling spam and low-quality ratings
We can get Composer download counts working, but there’s not a good way to distinguish a real download for a site vs. a CI system or something else.
I would definitely create and shared a curated list if this was available
I think this would be good for project browser in general. A curated place to start if you don't know what to search for, and more ability to highlight things that work together. However, this would also be a new type of user-generated content to establish community guidelines for - who gets to make lists (probably many people), who gets to decide which lists to highlight, with what criteria?
Opening many duplicate issues with many quick title changes makes this incredibly hard to make sense of.
What is the output of this command?
curl -v https://updates.drupal.org/psa.json
If it is no longer used, can we hide the field for editing as well? That way we keep the data, and give people a chance to miss it and let us know if they did use it. Before migrating off of Drupal 7, we’ll have to decide if we migrate or permanently remove this field.
It would be ideal to clean up existing comments after turning them off, so there is one less thing to migrate and otherwise maintain long-term.
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → has been helpful for me in seeing an initial split between “Site starter recipes” & “Functionality-specific recipes”, which tells me that might be something to track in metadata fields.
Would the module categories https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → make any sense to use? Is there different categorization.
How can we help someone looking through what will be hundreds of recipes find something that matches their needs?
Looks good, and this is all filtered on output anyway, so no security implications I can think of.
https://www.drupal.org/about/core → & https://www.drupal.org/community/event-organizers → are examples of sections, which are implemented with organic groups. This allows us to set up permissions for section maintainers within their section, without granting excessive access throughout the rest of the site.
drumm → made their first commit to this issue’s fork.
With most people’s profiles updated, I ran the migration for people currently at Sopra Steria who assigned issue credit to one of the three previous organizations. I used the effective merger date 2024-03-02 from the earliest press release, meaning all assigned credit after 3 Dec 2023 was updated. That updated 25 comments on issues.
Yes, most accounts are dormant, probably bot/spam. You can see from https://www.drupal.org/metrics#users → that the volume of accounts created has slowed down, but still most are not confirmed and likely not achieving anything productive. The number of user accounts on Drupal.org should never be used as some measure of Drupal’s heath.
I somehow missed how many items were in the theme guide. Reduced the limit to 25, which will go out with the next Drupal.org deployment, likely later this week.
Thanks all!
This is deployed now. Since :has() selectors have good browser support now, I used that to hide the menu on smaller screens, whenever there is a 100th item.
Deployed!
Blocked users should never have been in the API, this is now resolved with https://www.drupal.org/sa-contrib-2024-019 →
Projects are not deleted from Drupal.org. Since there is a release, we would not put someone in a situation where something they are using is removed; and we certainly wouldn’t want the possibility of existing releases replaced with a different codebase.
If you would like to direct people to a replacement project, you can mark the releases and projects as unsupported and update the project to note what it is replaced by.
Not for today, https://developer.mozilla.org/en-US/docs/Web/CSS/max might be a better approach for this in the future. Looks well-supported now, even if not, this is minor. Could be a bit more resilient.
Projects are not deleted from Drupal.org. Even with low usage, we would not put someone in a situation where something they are using is removed; and we certainly wouldn’t want the possibility of existing releases replaced with a different codebase. You can mark the releases and projects as unsupported. If you want to go as far as removing yourself as a maintainer, the GitLab pages like https://git.drupalcode.org/project/content_login have a Leave project option under the three-dot menu to the right of the project title.
This is now done and poll module is uninstalled.
This is now fixed. Occasionally the field collection containing the release files does not fully attach to the release node, and this is now corrected.
Site moderators is the new name for Drupal.org webmaster.
The two taxonomy-related permissions are only edit & delete, so “edit” ought to imply add.
The two roles/projects that have access are https://www.drupal.org/project/site_moderators → & https://www.drupal.org/project/content → , so whichever matches this task closest
Yes, this will be a one-off migration with some downtime as the migration runs.
Before staging is built out, we’ll want to make sure the codebase is fully updated for Drupal core, modules, etc.
We recently launched the Drupal 10 version of API.Drupal.org. We’ll want to make sure everything we learned from that is incorporated into the site build.
We'll want to start a checklist for running and launching the migration, so it can be repeated a few times in staging to find issues, and get an idea of how long it will take. What commands are needed to run the migration? What else is needed?
I think https://git.drupalcode.org/project/drupal/-/commit/d7235bfe2f5fb0432aa93... should be reverted for 11.x, and kept in for 11.0.x.
I can test this on staging if needed. That will be somewhat easier next week when staging has reset to a fresh copy of production
This is now fixed: https://bitbucket.org/drupalorg-infrastructure/subtree-splitter/commits/...
So 11.0.0-alpha2 should complete as-expected with the 11.0.x branch.
The subtree split issue is not a symptom of #3445259: Update core subtree splitter to handle major.x & main branches → . That concerns tagging, but this is happening for branch commits.
The subtree split issue may be a symptom of #3445259: Update core subtree splitter to handle major.x & main branches →
Done!
This looks like it is currently affecting packaging doing subtree splitting for 11.x as well:
13:40:29 > /usr/bin/php7.3 /usr/local/bin/composer --working-dir=/var/lib/subtree-splits/drupal/11.x/0894355a79949464fdfa181c0c89597f24498368/subtree-workdirs/recommended-project -n --update-no-dev require drupal/core-composer-scaffold:11.x-dev drupal/core-project-message:11.x-dev drupal/core-recommended:11.x-dev
13:40:29 ./composer.json has been updated
13:40:29 Running composer update drupal/core-composer-scaffold drupal/core-project-message drupal/core-recommended
13:40:29 Loading composer repositories with package information
13:40:36 Updating dependencies
13:40:36 Your requirements could not be resolved to an installable set of packages.
13:40:36
13:40:36 Problem 1
13:40:36 - Root composer.json requires drupal/core-recommended 11.x-dev -> satisfiable by drupal/core-recommended[11.x-dev].
13:40:36 - drupal/core-recommended 11.x-dev requires drupal/core 11.0.x-dev -> satisfiable by drupal/core[11.0.x-dev] from composer repo (https://repo.packagist.org) but drupal/core[11.x-dev] from path repo (/var/lib/subtree-splits/drupal/11.x/0894355a79949464fdfa181c0c89597f24498368/subtree-workdirs/core) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
13:40:36
13:40:36 Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
13:40:36
13:40:36 Installation failed, reverting ./composer.json to its original content.I’ve updated the other releases with lost files.
Moving for adding an integrity check to proactively catch this in the future.
This is fixed for your release.
Occasionally a race condition leads to the field collection for release files to not be fully associated with the release. This is no fault of your own.
I'm leaving this issue open to fix the handful of other releases with the same issue.
Bypass node access is an overly-broad permission that has proven to be problematic. There’s no indication of what lines shouldn’t be crossed, so people with that access can unknowingly cause problems.
We do have a “Post: View any unpublished content” permission that is not currently granted to any role. That could be a quick fix.
However, “allow section maintainers access to unpublished nodes in their section” solves this for all section maintainers, and does not require figuring out which roles are right just for someone helping with a section.
I think this might need to be revised to a drupalorg module task: allow section maintainers access to unpublished nodes in their section
Releases should never be unpublished. The other ways of marking support are preferred, and we should not try to make releases disappear in any way.
Tagging 11.0.0-alpha1 was a good way of spotting 2 technical blockers:
I don’t think there is anything else to do here. I believe I left it open for final acceptance testing.
I think the key part missing is seeing who has credit already and who is about to get credit, if I am returning to an issue that a maintainer has already commented on.
This was done with the ✓ to the left of the checkboxes.
The fix for https://www.drupal.org/project/user → is now deployed. Thanks for reporting!
I've updated the redirects to 8.9.x.
✨ [30 April 2024] Improve removal of jobs and prevent adding new ones Needs review is done, next step is deciding when to send reminders to maintainers still using DrupalCI ahead of July 1st.
benjifisher → credited drumm → .
The timing lines up, so I believe this to be due to the database size. Please re-open if you are still seeing issues.
The 5xx responses were due to an under-provisioned database, and should be resolved now. See #3444876: api.drupal.org returning 500 errors for all classes →
This is not something that we can really prioritize thinking about until issues are migrated.
#3005229: Provide optional support for using composer.json for dependency metadata →
would help make the .info.yml rewriting in packaging less-necessary. If we can drop that rewrite, packaging contrib projects becomes significantly more straightforward.
But when I open drupal.org/project/add, I get an error 403 forbidden.
This was caused by an anti-spam measure which disallows creating projects when your account is not yet confirmed. You are now confirmed, and this part should be resolved. Sorry for the inconvenience.
So I went on my dashboard and followed the "Your projects" link, which let me to drupal.org/project/user where I get the following error.
5xx Server Error
This is a bug on that page which we are triaging.
Same root cause as 🐛 Interfaces are not showing implementations Active
Comments were removed on the existing site to gauge the need to keep them. Migrating without the ability to log in and comment removes quite a few blockers. There should be a duplicate issue somewhere with more information, but that’s a good summary. I’m not aware of anyone missing the comments and we have the upgraded site ready to launch soon.
Testing schedules can no longer be added. We can now remove any code gated by pift_testing_enabled, so we don’t have to look at it again as we discontinue the rest of testing with
#3412417: Disable DrupalCI testing →
I couldn't find detailed enough steps in that article
This embed code can be obtained from Slack by accessing the app settings and selecting the ‘Install App’ button. Once the app is installed, navigate to the ‘More’ menu and choose the ‘Add to a website’ option.
Which app? Do they have a privacy policy? Cost?
Even with an embed, I would think using the regular Slack app would be a better experience. No need to keep a Drupal.org browser window open for Slack, and no trying to get chat fit into the already-packed Drupal.org UX.
⚠️ In other words, using this patch also means that the site may need to adjust the module weight for this module, so it runs at the end of the set.
Rather than module weighting, hook_module_implements_alter() is a bit nicer to control hook ordering, in case some hooks need to fire early and others late.
This is by design to prevent a new module from overriding a component of another project. In some cases, it is possible to get the package names reset. In the meantime, drupal/graphql_compose_fragments-graphql_compose_fragments is correct, Compose package names do not always match project names.
This is done now, I opted for a Drupal hook_menu() redirect for now.
This is now corrected. Your browser may have the redirect cached, so you may need to clear caches or restart it.
Thanks for reporting, a recent GitLab upgrade must have changed the path here.
Drupal.org is on D7 and much of its functionality is being pared down as a result of the GitLab migration. As the DA must plan the future of the D7 install, the docs system must be accounted for and migrated "somewhere."
I do not see a way around migrating a large portion of the documentation as-is on Drupal.org. There are 7,679 documentation pages in 1,972 guides. Unless 100% of the pages are put somewhere else, replaced with redirects, and deleted, we are still maintaining the current documentation system on Drupal.org. Migrating 1,000 nodes is the same as 10,000 nodes, so this has no potential to save cost or reduce technical debt for Drupal.org’s migration past Drupal 7.
Where we do need to draw the line for technical debt is that Drupal.org actually has 2 other documentation systems leftover from previous efforts to “solve” documentation. #2762837: Migrate documentation into the new system → is needed to remove book nodes from Drupal.org, as these do not make sense to migrate on top of the current guides and pages.
And as mentioned already, there is an existing official docs in Git, https://www.drupal.org/docs/official_docs → , which is not very active, https://git.drupalcode.org/project/user_guide/activity. I do not think this is a tooling problem. Git doesn’t make it easier to find motivated people with time and a shared vision of what needs to be documented for a well-defined audience. Git may make the workflow easier for some people, but the important part is good, organized writing and time to do it.
Btw the User guide is already a static files with broken 💔 regeneration, it' still looks the low hanging fruit to fix first as it multilingual and only predictable regeneration is a blocker for it (except leader)
🐛 Problem with encoding on Drupal.org user Guide for all chars except latin. Active was already fixed.
So I think the layer that is very noticeably missing/hard to find in the current docs landscape is 'high level developer docs about low level APIs' and this is what are front and centre when you look at frameworks like Symfony.
Getting more specific like this should help get to something achievable. I’m very skeptical of any proposal that claims it will solve Drupal documentation. Starting with one thing makes it possible to do that well. Something like high level developer documentation identifies an audience and a gap that can be filled.
While the wiki model works well for many knowledge bases, very few users contribute to the docs in this manner and there is no staging or change-proposal system in place.
The design of documentation guides on Drupal.org was for guide maintainers, and other people interested, to get notifications of edits. This allows people to be bold and make edits, and for others to see changes and review after the fact. If a maintainer is still active, they can catch any further improvements needed. If the maintainers are no longer active, the changes aren’t stuck in a change-proposal system.
Any documentation plan needs to think long-term about who will maintain the documentation long-term. People don’t do the same thing forever, and that is a big part of what led to the current disjointedness.
On GitLab pages
With increasing use of GitLab pages, we’ll also have to think about the Drupal.org site search. If a lot of documentation is missing from www.drupal.org, and issues are no longer there either, we need to consider removing the site search or getting GitLab pages indexed. (Removing site search would not significantly reduce technical debt - we still need a solid, tuned, full-text search for project browsing.)
And agreed on this not being an ideal way to spend time, but this is what we need to do whenever there is a migration to something new. There is twice as much technical debt as long as there are 2 ways to do documentation. Unless we bulk delete everything or auto-migrate outdated/etc book pages to the current system, there's unfortunately no way around the sheer volume of docs that were a good idea at the time.
These are now deleted:
- PHP block snippets https://www.drupal.org/node/21867 →
- PHP block visibility settings https://www.drupal.org/node/60317 →
- PHP page snippets https://www.drupal.org/node/23220 →
Code used was:
$page = node_load(23220);
$queue = book_menu_subtree_data($page->book);
$nids = [];
while ($item = array_shift($queue)) { print $item['link']['nid'] . ' ' . $item['link']['title'] . PHP_EOL;
$queue += $item['below'];
$nids[] = $item['link']['nid'];
}
node_delete_multiple($nids);So deleting more trees of pages is technically straightforward.
🐛 JS behaviors double-attach causing checkboxes to become unchecked Closed: outdated is the root cause
Not offhand, I would apply the same to any package management, like npm, pypi, etc. Production deployments should be as atomic as possible, deploying artifacts instead of building them. If something has changed, or some part of the internet is flaky, production is not the place to find out. Composer 1 was particularly error-prone, since the codebase changes started before other steps were complete. I believe Composer 2 is as good as it can be, with more distinct phases and copying everything at once, after build is done; so you won't have a codebase in an indeterminate state unless there is a badly-timed hardware failure. A maintainer could still introduce randomness, GitHub-hosted tagged releases can change to different code or be deleted.
Running Composer in production is not recommended anyway, although is a lot safer with Composer 2. Composer 2 internally has much fewer places that could leave your codebase in an indeterminate state if something goes wrong.
With this clarification, this does look like a duplicate of #463424: Drupal.org reachable by IPv6? →
A potential solution is putting the badges right next to the organization logo on the left, matching the badge size to the logo size. That makes it more clear where the badges come from. If an organization has more than one badge, then it would have to go to the next line, which would probably be okay in most cases. I do like that it frees up some page real-estate to focus more on the person, but does split up the supporting badges.
If we stick with the right side, let’s make the text a bit more descriptive, like:
- Cambrico, Ymbra are Bronze Drupal Certified Partners
- Tag1 is a Platinum Drupal Certified Partner
That helps if you get lost deciding if the text goes with the badge above or below, and is a bit more direct than “Associated with”