Please use this topic to suggest agenda items for our weekly meetings.
Most helpful answers
Comments
Project name vs. repo name - a topic for our DEV meeting.
The usual case is that the project name and the repo name are the same. So mymodule.info and mymodule.module are in a directory mymodule.
However, in very rare cases a D7 module doesn't follow that common practice, and its repo name is different. Such a module can be ported, can be released (gets packaged) - but it can't get enabled.
What we might need is some policy and documentation, or - if we want to support that, it should work in the installer.
Either way, there needs to be clarity. Especially for people porting D7 modules. For example instructions how to rename such a project (if we enforce exact match).
And if we enforce exact match, the packager should refuse to build a release (happens in the project module, I guess).
Not sure if that needs a PMC decision.
See also:
The core issue opened recently by a new contributor, who ran into that problem: https://github.com/backdrop/backdrop-issues/issues/6901
A short discussion in our Zulip chat, where preferences rather seem to be "strict match":
I'd like to discuss this issue:
https://github.com/backdrop/backdrop-issues/issues/3857#issuecomment-2880006337
and a zulip chat #Backdrop > File may not be referenced in WYSIWYG
Which on the surface is about the image library but has another discussion about the behavior that changed in file_usage_delete in Backdrop where files with no usage will be marked as temporary in the file_managed table and then cleaned up on cron run.
There are basically two schools of thought on this in the queue:
- It's desirable because otherwise you'll have a bunch of unused files lying around
-
It's dangerous because it could lead to irreversible deletion of files that are in use even though they're not in the
file_usagetable. This can happen in one of two ways: contrib modules that don't know they need to use the file_usage table (I believe I've made this mistake) and D7 -> Backdrop migrations where there happen to be a bunch of files infile_managedthat don't have entries infile_usage
There was a suggestion in to make this behavior a) optional and b) turned off by default especially for migrations since it deviates from Drupal 7's behavior, which doesn't clean up files automatically.
There are basically two schools of thought on this in the queue:
I belief, there were some more "schools of thought" ;-). Having the ability to turn image/file garbage collection off may be beneficial for some sites, but it actually just hides the problem instead of solving it.
A solution for D7 upgrades, which are the main cause for this anomaly, could be an upgrade hook to set the files as "self-using", so we avoid the problem of having files that are permanent, but have zero usage count. Note: this only affects inline images/files.
I think some discussion of https://github.com/backdrop/backdrop-issues/issues/6900 would be useful
I'd like to discuss this issue:
https://github.com/backdrop/backdrop-issues/issues/3857#issuecomment-2880006337
and a zulip chat #Backdrop > File may not be referenced in WYSIWYG
Which on the surface is about the image library but has another discussion about the behavior that changed in
file_usage_deletein Backdrop where files with no usage will be marked as temporary in thefile_managedtable and then cleaned up on cron run.There are basically two schools of thought on this in the queue:
file_usagetable. This can happen in one of two ways: contrib modules that don't know they need to use the file_usage table (I believe I've made this mistake) and D7 -> Backdrop migrations where there happen to be a bunch of files infile_managedthat don't have entries infile_usageThere was a suggestion in to make this behavior a) optional and b) turned off by default especially for migrations since it deviates from Drupal 7's behavior, which doesn't clean up files automatically.