Please use this topic to suggest agenda items for our weekly meetings.
Weekly office hours
Bring your questions to our weekly virtual office hours, every Wednesday. Everyone is welcome.
Recent topics
Posted 1 day 4 hours ago by (ian) in How-To and Troubleshooting
Posted 2 days 6 min ago by (onyx) in How-To and Troubleshooting
Posted 2 days 21 hours ago by (clarkac) in How-To and Troubleshooting
Posted 3 days 20 hours ago by (Egmund) in How-To and Troubleshooting
Posted 1 week 1 day ago by Graham Leach (Graham Leach) in Other
Recent comments
My opinion is influenced from the fact I started learning Drupal since its 4.7.x release, but I agree. For a new site, I would use Backdrop, even in the case of small sites where the...
Opinion: Backdrop vs Drupal/Acquia vs WordPress
Hi ian, I belief, the easiest way to achieve that is via styles. There's a "styles" dropdown button for the toolbar. And as soon as that button is part of the active toolbar, you get...
CKEditor v5 colour (color) button?
Pasting here, since the stackexchange answer includes the use of drush, which may or may not work in Backdrop. The function that takes care of deleting the field in Backdrop is field_delete_field($...
Remove fields programmatically
https://drupal.stackexchange.com/questions/63421/how-to-manually-or-prog...
Remove fields programmatically
Last time I tried CiviCRM, it was incompatible with PHP 8+. You are certainly running into that. https://forum.backdropcms.org/forum/trouble-accessing-civicrm-after-inst...
Comments
Suggested topic for the dev meeting: CKEditor update, Issue #6481
Unfortunately it turned out, our image plugin implementation seems incompatible with CKE5 v42. There's an error with ... presumably figcaption downcast. Or something else.
This console error isn't particularly helpful:
Uncaught CKEditorError: t.hasStyle is not a functionIt only happens, if an image has a caption, other images work fine and when disabling the caption, the image dialog opens again without problems.
However, some of our code needs to get updated. And there's actually only one person, who understands that code. And that's not me. ;-)
Coding standards, line length and
t()Because the coding standards check allows
t()functions to be longer than 80 characters, I and others often do this. But porting a module recently, the descriptions are spread over several lines and the code is much more readable while still working. In the README we split at 80 characters for readability in editing even though it makes no difference to the render of the md. I also came across this in the Localization API (which we should import to our docs site btw): https://www.drupal.org/docs/7/api/localization-api/dynamic-strings-with-placeholders#s-lets-do-better-than-drupal-core which encourages line breaks int()strings.Should this be part of our coding standards?
See https://backdrop.zulipchat.com/#narrow/stream/218635-Backdrop/topic/t.28.29.20and.20line.20breaks
One caveat, is that this should only be changed for new (or modified to the extent that a new translation is needed anyway?)
t()strings, as changing existing strings like this would break the link to the translation.Within that thread, there is also a suggestion about increasing the line length to 120.
Telemetry for Contrib
A process (ideally very simple) is needed for how contrib project can have telemetry enabled on b.org and have metrics added, modified or removed.
Based on core, there appear to be four main categories
As examples, I have two projects which I would like to add telemetry for:
Bee
Bee is a special case as it doesn't get usage data like other contrib. The subset of Backdrop users who are also Bee users is likely to make some of the metrics different from Backdrop core, hence the reason to collect information that it is also collected by core.
Font Awesome
The module currently supports versions that are quite old and it would be informative to know if these options are still needed.
FTR, CiviCRM has already implemented telemetry, and here are the results: https://backdropcms.org/project/civicrm/telemetry
There's a manual aspect of telemetry, which is that a trusted person with the proper access/permission levels in the backdropcms.org website needs to add and configure the metric(s) gathered for the respective project node. I find this to be a good thing, since we need to have some governance/process where at least another person other than the contrib maintainer gets to review/"approve" this.
But yeah, lets discuss further during the dev meeting this week.
In Zulip it was recently stated: "Using the d2b upgrade module isn't a supported Backdrop upgrade path, so that might be the problem."
I accept that this may be true, but I would like to better understand what makes the d2b upgrade different and/or unsupported? What would it take to make this a supported path?
What can we include in documentation to help folks know what to watch out for while doing a D2B upgrade?