Problem/Motivation

it would be helpful to have a "clear all recorded statistics" button.

Steps to reproduce

NA

Proposed resolution

Add a "Reset" button to the statistics admin page.

Remaining tasks

Review from committers

User interface changes

pictuer

API changes

NA

Data model changes

NA

Release notes snippet

NA

Original post

Hi,

I think it would be helpful to have a "clear all recorded statistics" button. For example, this would be useful for when a site transitions from being a private "development" site to being a public "live" site.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

LAsan’s picture

Version: x.y.z » 7.x-dev
Priority: Normal » Minor

Bump.

Andrew Schulman’s picture

Subscribing. I agree, this is a pretty basic need and common use case. Thanks, Andrew.

j.somers’s picture

Status: Active » Needs review
FileSize
1.29 KB

Attached is a small patch which adds a button to the statistics administration page similar to the "Clear cache" button on the performance administration page. The description and title information could possibly be described better.

Dave Reid’s picture

Status: Needs review » Needs work

I'd include the node_counter table as well since it is a part of the statistics.module.

j.somers’s picture

FileSize
1.32 KB

I added it in the attached patch, but note that the node_counter table is not created by the statistics module.

j.somers’s picture

Status: Needs work » Needs review
FileSize
3.89 KB

Discard the previous patch, I added a test case in the attached one.

Status: Needs review » Needs work

The last submitted patch failed testing.

j.somers’s picture

Assigned: Unassigned » j.somers

Don't really see why applying the patch would have failed but after #463064: 'content' cannot be used as a $form element and breaks any page which uses it, such as admin/settings/statistics has been resolved I shall create a new version.

j.somers’s picture

Assigned: j.somers » Unassigned
Status: Needs work » Needs review
FileSize
3.86 KB

Re-roll.

catch’s picture

Priority: Minor » Normal
Status: Needs review » Needs work
+  /**
+   * Enable required modules and create users with specific permissions.
+   */

This isn't need for setUp().

The delete from table should use db_truncate()->execute().

j.somers’s picture

Status: Needs work » Needs review
FileSize
3.78 KB

Updated the patch to make sure it works on the latest D7 version and applied remarks in comment #10.

MichaelCole’s picture

#11: jsomers_54798_5-D7.patch queued for re-testing.

ghills88’s picture

The patch from #11 works well for me.

I applied it to the CVS HEAD and the patch applied correctly. The button was indeed added to the statistics admin area and clicking reset had the desired behavior of resetting the site hit statistics.

j.somers’s picture

Status: Needs review » Reviewed & tested by the community

Marking as RTBC because of comment #13.

webchick’s picture

Version: 7.x-dev » 8.x-dev

Sorry, we're past feature freeze (and string freeze) for D7; new features go in the next release of Drupal.

TR’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs backport to D7

It's been a year and a half since the patch, so I re-rolled it against the D8 head. The only changes I made from the patch in #11 were to remove trailing whitespace, add doxygen comments, and modify some doxygen comments to bring up to standards.

I tested this patch in Drupal 8.x and it works as advertised.

This issue has been open for 5 years! I'm reluctantly changing the status to needs review to force the testbot to test the patch, but I'd like to think this is RTBC. Maybe someone else can do a quick review and we can finally get this closed.

TR’s picture

It would help if I actually attached the patch ...

Status: Needs review » Needs work
Issue tags: -Needs backport to D7

The last submitted patch, 54798-clear-statistics.patch, failed testing.

TR’s picture

Status: Needs work » Needs review

#17: 54798-clear-statistics.patch queued for re-testing.

Previous test failure seems like it was a testbot problem: "PHP Fatal error: Class 'DrupalWebTestCase' not found"

Status: Needs review » Needs work
Issue tags: +Needs backport to D7

The last submitted patch, 54798-clear-statistics.patch, failed testing.

karschsp’s picture

Status: Needs work » Needs review
FileSize
3.58 KB

Here's a re-roll for 8.x.

karschsp’s picture

Fixing whitespace issues.

naxoc’s picture

Issue tags: -Needs backport to D7

#22: 54798.reset-statistics.022.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs backport to D7

The last submitted patch, 54798.reset-statistics.022.patch, failed testing.

naxoc’s picture

Status: Needs work » Needs review
FileSize
2.66 KB

Reroll.

I did some cleanup in the test - mainly removing the t() around the text in assertions.

TR’s picture

I don't think removing the t() is appropriate until #500866: [META] remove t() from assert message is committed.

naxoc’s picture

@TR - t() should not be added to new tests anymore. See http://drupal.org/node/265828 at the top.

TR’s picture

The revision history of the documentation you cite at http://drupal.org/node/265828 says that this documentation was changed because of what is being discussed in #500866: [META] remove t() from assert message. So again, I think it was premature and inappropriate to change the documentation before the community has finished deciding the issue. #500866: [META] remove t() from assert message has been open a long time - I don't think that subverting the community process by making changes in anticipation of the expected outcome of #500866: [META] remove t() from assert message is something that we should be doing.

naxoc’s picture

Current documentation says don't use t(): http://drupal.org/simpletest-tutorial-drupal7#t

Reference found here: http://drupal.org/node/500866#comment-5654154

mgifford’s picture

Status: Needs review » Needs work

The last submitted patch, 25: 54798.reset-statistics.25.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Wim Leers’s picture

Issue summary: View changes
Status: Needs work » Postponed (maintainer needs more info)

Site builders advanced enough to have multiple environments (dev/staging/prod or just dev/prod) seem more than capable of just exporting the node_counter table as "structure only" when they sync their DB?

SKAUGHT’s picture

'Site builders' may include people who don't have enough database and module understanding, or access to a database UI/term to truncate.

TR’s picture

@Wim Leers:
Core has a UI button for deleting DB logs, clearing caches, cleaning up testing results, re-indexing the site for search purposes, etc. All these things can be done from the command-line or outside the UI by a knowledgeable developer. I think the statistics node counts are similar to these things, and they need to be cleared during site development for similar purposes. Testing content, theming content, testing a site, all generate a lot of bogus data that you don't want polluting your site when it goes live.

I think it would be a shame if Drupal stopped supporting non-developers, because if that's case much of the core UI is unneeded. (What developer enables modules via the UI these days? What developer manages config through the UI? Etc.) We should make it possible to manage the data generated by the core statistics module through the UI, just like we make it possible to manage the dblog data, simpletest data, search data, and caches.

TR’s picture

Status: Postponed (maintainer needs more info) » Needs work

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

ressa’s picture

Version: 8.8.x-dev » 9.0.x-dev
Status: Needs work » Needs review
FileSize
2.27 KB

Here is a re-roll of the patch for Drupal 9, which seems to work. I removed the accesslog bits in the test, since this part was removed in #1446956: Remove the accesslog from statistics, but the test probably needs more work to pass.

Status: Needs review » Needs work

The last submitted patch, 43: reset-statistics-54798-45-D9.patch.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

ressa’s picture

Status: Needs work » Needs review
FileSize
2.26 KB

Updates failing test method to public.

Status: Needs review » Needs work

The last submitted patch, 45: reset-statistics-54798-45-v2-D9.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

xjm’s picture

Version: 9.0.x-dev » 9.1.x-dev
Issue tags: -Needs backport to D7

Thanks for the suggestion!

Feature requests go against the 9.1.x branch at this point. Both D7 and D8 are going into LTS so we would not backport a new feature.

ressa’s picture

Thanks for the update! I am trying to get PHPUnit tests running in Lando, and if I succeed I'll try to look at the failing tests.

TR’s picture

Re-rolled for Drupal 9 and to fix the test failures in #45. I injected the database connection and modified the patch to use current coding standards. See interdiff.

Status: Needs review » Needs work

The last submitted patch, 49: reset-statistics-54798-49-D9.patch, failed testing. View results

TR’s picture

Status: Needs work » Needs review
FileSize
3.88 KB

I missed converting a drupalPost() to drupalPostForm() ...

andypost’s picture

Looks rtbc, but needs is update and release notes snippet

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

TR’s picture

Re-roll for 9.3.x.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

nod_’s picture

Status: Needs review » Needs work

D10 version needed
At this time we would need a D10.1.x patch or MR for this issue.

Also I would expect a confirmation step before removing all the statistics from a site.

pradhumanjain2311’s picture

Status: Needs work » Needs review
FileSize
4 KB

Try to make patch #55 drupal version 10.1.x compatible.

TR’s picture

You know, I first contributed to this issue only 11.5 years ago, but it has been open for more than 16 years. How many people even remember what Drupal version "x.y.z" meant? That's what this was originally opened against.

Because Drupal core is constantly changing, there will constantly be new things that this patch "needs" to change. My expectation has been that if I do the work and address the feedback that raised, then the patch will be committed in a reasonable amount of time, before core can drastically change underneath it. That hasn't been the case.

If this had been committed 10 years ago, then the code would have evolved along with the rest of core. But constantly delaying and constantly kicking this issue down the road to D7, D8, D9, and now D10 just means it will never be up to current standards.

And now we have yet another new request - that we have a confirm form for this. If I make this change do I have any assurance that my work won't go to waste?

There are a lot of people who are willing to contribute to core, but constantly disrespecting their efforts by ignoring and bikeshedding issues like this has frankly been killing the community over the years.

If there is no intention of committing this, then just say so. You could have said so 10 years ago and not wasted our time. Mark the issue as "won't fix" and move on. It's just plain disrespectful to leave it open and constantly nit pick for years without movement or feedback from the maintainers.

TR’s picture

Issue tags: +Bug Smash Initiative
nod_’s picture

I understand the feeling, a few of my long standing patches are in the same situation so I know what it feels like.

For some background the Needs review queue is at 2600+ issues today. It's nowhere near manageable, after some looking into I found that 65% of those need review issues have patches that either don't apply or don't pass commit checks. So I'm trying something to address this and make the Needs review queue a more manageable size so that patches can be worked on, reviewed and committed in a timely manner. Nobody wants to ignore a patch, it's just that there are too many open to review.

Now back to the topic at hand from #39:

Core has a UI button for deleting DB logs, clearing caches, cleaning up testing results, re-indexing the site for search purposes, etc.

Today the UI for deleting DB logs looks like a confirm form, the button is not in the main watchdog interface but in a separate tab. This was changed in #2506449: Transform "Clear log messages" submit button into a link in admin/reports/dblog (2016) and I would think that for consistency we go with the same pattern. But pradhumanjainOSL rerolled the patch, it's green, you can definitely RTBC it if you feel it's ready.

It's not up to me to say whether something makes it in core, it's possible to RTBC and have feedback from a core committer. They always have the final say.

And to answer the question about a commit guarantee. I can't tell you that, I don't have commit access to this core repository. I had some success making old patches go through this past week since I started going through the NR list, so it's possible.

smustgrave’s picture

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge require as a guide.

Fully understand the frustration mentioned here which is why we have started this new initiative to help get the "needs review" queue under control so that issues don't sit forever. This won't necessarily get anything fixed faster but users will know sooner more is needed.

I've went ahead and updated the IS so removing the tag for that.

Testing the patch #60 and can confirm it is doing as expected.

Testing on Drupal 10.1.x
Enabled statistics
Added a view column to the admin/content view
Visited a few pages, Verified count is updated.
Reset the statistic
Verified count is now 0

xjm’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs usability review

In all this issue's years, it doesn't look like it's ever gotten a usability review. :)

  1. This is a destructive operation, so perhaps it should have a confirmation form? Edit, let me phrase that more strongly: It should have a confirmation form. This was already suggested above but never addressed.
  2. Does it really make sense for it to be in a separate fieldset than the checkbox to enable statistics?
  3. Etc.

You can get usability feedback in the #ux channel in Drupal Slack. There are weekly meetings Fridays at 1400 UTC where you can join a Zoom and have your user interface change reviewed for usability and accessibility by a team of core topic maintainers and volunteers. Thanks!

xjm’s picture

Issue tags: -Bug Smash Initiative

Also, it's not a bug. :)

xjm’s picture

 

xjm’s picture

Usability review

We discussed this issue at #3329009: Drupal Usability Meeting 2023-01-06. That issue will have a link to a recording of the meeting.

For the record, the attendees at today's usability meeting were @ABElliott, @BlackBamboo, @benjifisher, @rkoller, @shaal, and @xjm.

Points we covered in the discussion:

  1. We all agreed that there should be a confirmation form for this action, since it is a destructive action.
     

  2. We discussed the organization of the form. The current structure, with the "Reset" button as an immediate action in between the rest of the form and the submit button, is confusing. We discussed two options to improve it:

    • The reset button could be moved to a separate vertical tab on a separate form.
    • The reset button could be moved to the top of the form instead of the middle of it. This would be similar to both the "Clear cache" button on the Performance administration page, and the "+ Add new" action buttons on various forms.

     

  3. We agreed that this issue is not passing the documentation gate currently. We need a couple sentences of documentation added to hook_help() and to Help Topics about resetting statistics.
     

  4. We agreed that there also needs to be some explanation of what "Reset statistics" means in the context of the form itself. The best suggestion we had was that the form should tell you the specific consequences of the action, e.g.:

    There are N statistics records from the past M days. Resetting statistics will delete these records.

    (That's just a starting point. The text could probably be improved.)

    Then, on the confirmation form.

    Are you sure you want to delete N content statistics records from the past M days? This action cannot be undone.

    And finally in the confirmation message:

    N content statistics records from the past M days were deleted.

    If there are no records in the database table, the text should be something else, maybe simply:

    There are currently no statistics records.

    (Or something along those lines.)
     

  5. Currently, the button is shown regardless of whether there are any statistics, or whether statistics are even enabled. @xjm suggested that maybe the button should only conditionally be shown if "Count content views" is enabled; however, @benjifisher pointed out that a site owner could enable statistics, then disable it, and there would still be database records that could be purged. So, it should not be hidden conditionally based on that. The previous point (displaying the number of statistics records and the timeframe, or that there are none) would be a better way of addressing this.
     

  6. @xjm also noticed in the course of manually testing the patch that caches are not properly invalidated when the reset button is used. For example, the block cache for the statistics blocks is not invalidated. This makes it appear that nothing is happening when the user first clicks the reset button. The cache for any content containing statistics data should be invalidated when the form is submitted. The cache invalidation aspect also needs test coverage.
     

Code review

Currently, the patch is directly truncating a database table:

+++ b/core/modules/statistics/src/StatisticsSettingsForm.php
@@ -78,10 +90,28 @@ public function buildForm(array $form, FormStateInterface $form_state) {
+  public function statisticsResetSubmit(array &$form, FormStateInterface $form_state) {
+    $this->connection->truncate('node_counter')->execute();
+    $this->messenger()->addStatus($this->t('Cleared statistics data.'));

This would have been the correct approach in 2006, but it no longer is. Instead of using the database connection directly, the form should use statistics.storage.node. (This is probably the key to fixing the cache invalidation bug mentioned above.)

Also, instead of hardocoding a query, we should use StatisticsStorageInterface. There is currently a deleteViews() method that delete the records for a single entity. To match that, we could add a new method, something like deleteAllViews().

xjm credited ABElliott.

xjm credited benjifisher.

xjm credited BlackBamboo.

xjm credited rkoller.

xjm credited shaal.

xjm’s picture

Adding issue credit for Usability meeting participants.

ABElliott’s picture

Took the following steps to test the site and had no issues:

Go to https://simplytest.me/configure?project=drupal&version=10.1.x-dev

On https://www.drupal.org/project/drupal/issues/54798, right-click the filename '54798-60.patch” and select “Copy link address” (or similar). This is the URL to the patch file.

On https://simplytest.me/configure?project=drupal&version=10.1.x-dev, under “Advanced options”, paste the patch file URL in the field labeled “Add patches on the chosen project”.

Click “Add patch”.

Click the “Launch Sandbox” button. It will build an instance of Drupal for you with the patch applied. This can take a long time (up to 5 minutes).

Log into the new Drupal site using username and password admin/admin.

At /admin/modules on your test site, check the box next to the Statistics module and click “Install”.

At /admin/config/system/statistics, check “Count content views”.

At /admin/people/permissions/module/statistics, grant all roles permissions to view content hits.

Create at least three pieces of test content at node/add/article.

On /admin/structure/block, click the “Place block” button next to “Hero” and select “Popular content”. Set “Number of all time views to display” to 3 and click “Save block”.

Click “Home” and observe that one of your test articles is now linked in the upper left.

View each piece of content several times.

Go to /admin/config/development/performance and click “Clear all caches”.

Click “Back to site” and observe your block listing the popular content, ordered by view.

Go back to /admin/config/system/statistics and click “Reset”.

Go to /admin/config/development/performance and click “Clear all caches”.

Click “Back to site” and observe that the popular content listing is now empty.

ABElliott’s picture

Fixing attribution

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Anybody’s picture

Still needs #68 to be implemented by someone. Would be a nice addition!

2dareis2do’s picture

Looks like statistics module is being removed from 11.x unfortunately.

https://www.drupal.org/project/ideas/issues/3266457

TR’s picture

Yeah, typical. Drupal core loses a feature because none of the core committers noticed the regression. But then when it is pointed out, there is push back to fixing it. In this case, the fix has been delayed for EIGHTEEN YEARS. Then the submodule gets removed from core, so there's no need to fix it. Thanks for wasting my time. No one remembers any more that we used to have this feature.

When I contributed patches for this issue, they were 100% compliant with the then-current Drupal standards. Those standards keep changing. If the patches had been committed 10 years ago, then this code would have organically evolved along with the rest of Drupal. But these patches keep getting judged by standards that DIDN'T EXIST when they were contributed, and when they are re-rolled they are neglected and rejected again.

If you want to encourage contribution to core, you're doing exactly the OPPOSITE of what you should.

I'm out. Clearly my contributions to this issue are not valued. A less patient person would have given up 10 years ago.

2dareis2do’s picture

@tr I believe the statistics removal has been pushed back because it does not meet the criteria of being installed on less than 5% of sites.

To be fair there are a lot of issues that have built up over the years. I have some sympathy, largely due to the limited resources that seem to make up the 'core' drupal team, which if I understand correctly stands at around 20 people. This is only really possible due in part to the enormous good will of these people who give up their own time to try and move Drupal forward.

Why the core team is limited to just 20 people is beyond me?

That said, it is sad when the core team seem to neglect issues like this. Trying to get this and other features to work as they should take far too long and put developers off using Drupal.

Most businesses cannot function on the premise that an issue might be fixed in 18 years time. Usually they want things yesterday. This goes along way to explaining why many companies are turning their backs on Drupal when it takes so long to get things done and no amount of marketing spend will convince people otherwise.

This regression probably should have been resolved one way or another 18 years ago. IMO this and other issues in a similar state should be prioritised over and above new features such as project browser on that basis.

Thats said webform already has a project browser of sorts. I would like to see webform brought into core before building project browser. Core needs to have a form builder imo.