Submit handlers are not attached to the form correctly.
sanduhrs → made their first commit to this issue’s fork.
joachim namyslo → credited sanduhrs → .
joachim namyslo → credited sanduhrs → .
joachim namyslo → credited sanduhrs → .
If you want this fixed, please support the upstream merge request: https://github.com/pear/XML_XRD/pull/2
The "token" is a twig variable and per default available in "Global: Custom text" fields, no further requirements.
at 1. Formatter approach
I don't think a pseudo field supports formatters.
You could create a text field or a link field and store the link to the node using a default value and tokens.
For these kind of fields the barcodes formatter will be available.
at 2. Global: Custom text
This also does not support field formatters afaict.
You could use the twig filter to render the barcode
{{ view_node|barcode('QRCODE', '#000000', 100, 100, 0, 0, 0, 0, 'png') }}
But currently there is a bug in Drupal core's filter system that prevents rendering if inline data images: https://www.drupal.org/project/drupal/issues/3413396 🐛 Xss:filter() malforms inline image references with data uri scheme Needs work
Before enabling the module you need to install and (auto-)load the external library tecnickcom/tc-lib-barcode:
https://git.drupalcode.org/project/barcodes/-/blob/7.x-1.x/README.md?ref...
You might want to use composer_manager module to assist you with the task or do it however you load and manage other third party libraries:
https://git.drupalcode.org/project/barcodes/-/blob/7.x-1.x/README.md?ref...
Thanks!
sanduhrs → created an issue.
Thanks!
I created MR!19 with the patch from #7 to get the tests running.
Apparently every existing test passes.
We need a new test for this case before it gets committed.
I reviewed the other parts of the referenced issue, don't think anything is left.
Thanks.
Joachim Namyslo → credited sanduhrs → .
#9 has been addressed.
Patch is simple, applies well and works as advertised.
Thanks!
Can confirm the findings in #5, added an example in the MR!5.
Thanks!
sanduhrs → made their first commit to this issue’s fork.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → created an issue.
Added pushframework, pf_mail and pf_slack and initial config export in
#3422866: Add push framework to codebase →
sanduhrs → created an issue.
/requires from to|requires cron to/
sanduhrs → created an issue.
This has been fixed in
🐛
Change markup from span to a
Fixed
.
Thanks!
Fixed along with other things in https://git.drupalcode.org/sandbox/sanduhrs-3274877/-/commit/979d272563f...
Tow alternatives to implement content subscription in D10:
- DANSE
https://www.drupal.org/project/danse → - Message and Message Subscribe
https://www.drupal.org/project/message →
https://www.drupal.org/project/message_subscribe →
Seems like you didn't fullfill the requirements:
https://git.drupalcode.org/project/wordcloud/-/blob/1.0.x/README.md?ref_...
Joachim Namyslo → credited sanduhrs → .
Thanks for the feedback.
#4.1 We should bump the release number
The recommendation to install the module on the project page is composer require 'drupal/barcodes:^2.0'.
As per semantic versioning we should bump
* major in case we make incompatible API changes.
* minor in case we add functionality in a backward compatible manner
As we do not expose the library as a public API, I see no point in bumping major, unless we break sites if we don't.
Given constraint of ^2.0 as recommended on the project's page and semantic versioning
A minor version bump:
* bumping to 2.1
* composer update will update the module, as well as the library
* drush or Drupal UI will break the site as the library will stay outdated
A major version bump:
* bumping to 3.0
* composer update will update neither the module nor the library
* it will therefore be a more conscious process to upgrade
* updating manually with drush or Drupal UI will break the site as well
As the initial install of the module needs to be done with composer require already - for getting the library and generating the autoloader - isn't it safe to assume any updates will be done that way?
#4.2 The project page will also have to be updated for the new barcode types
Added the todo to the issue summary
#4.3 Aren't the array indexes still relevant
I agree, readded the barcode identifiers to the docs, but behind the description for better readability.
#4.4 Is there a need or use case for adding barcode.html.twig?
Drupal 10 was trying to fall back to it when it didn't find the specific template for a new barcode type.
sanduhrs → created an issue.
sanduhrs → created an issue.
sanduhrs → made their first commit to this issue’s fork.
sanduhrs → created an issue.
sanduhrs → created an issue.