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 function
It 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. ;-)
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 in t() strings.
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.
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
Server software (type and/or version)
Library version
Site setup (e.g. multisite, installation profile)
Setting (Drupal compatibility layer)
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.
Bee version
PHP (CLI) version
Multisite
Font Awesome
The module currently supports versions that are quite old and it would be informative to know if these options are still needed.
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.
Thanks. openid_connect is actually a different beast than OpenID. I think the "connect" version implements an OpenID client to work on an Oauth server. Or something like that.
I think this alternative works too. Instead of installing the stub modules, you may be able to just insert the relevant records in the systems table (while also ensuring entity_plus and...
This relates to a problem with creating a View of Projects on a site using MySQL >= 8.0.3
https://github.com/backdrop/backdrop-issues/issues/5795
I can't be at the meeting this...
Posted12 hours 41 min ago by Martin Price | System Horizons Ltd (yorkshirepudding) on:
Additionally, "outside" means a file that is located outside a module folder. The second parameter of module_load_include() is the name of a module, so, this function assumes that you are loading a...
Posted17 hours 25 min ago by Alejandro Cremaschi (argiepiano) on:
Yes, it does mean outside your functions. You can use module_load_include() within functions but not outside.
The YouTube module gives an example:
<?php
/**
* @file
* Youtube field module adds...
Posted22 hours 4 min ago by Martin Price | System Horizons Ltd (yorkshirepudding) on:
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 function
It 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 in
t()
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?