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.
Tried and successfully applied DrAlbany's method with the form https://www.drupal.org/sandbox/grobot/2105379stickman hook. I also encountered the same situation. Thanks DrAlbany
Since before migration you need to prepare the Drupal site - disabling and removing all modules, disabling themes, as part of the preparation you can clear the cache and logs, delete the search...
QuickTabs is now available!!!
But does not work as expected, already reported (https://github.com/backdrop-contrib/quicktabs/issues/14).
Maybe an alternative solution using Views...
SKU = Stock Control Unit... meaning an easy way to identify stock...
Depending on the type of stock item you have, would dictate the SKU.
So, for example, in the IT industry,...
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?