Now the question is: How to build a Drupal app with git nowadays?!
a recipe could supply (or dynamically create) an ECA model to reapply itself any time a particular condition, or set of conditions, is fulfilled
🤯 🙌🏻
I can't find a way to patch this module if it cannot be installed. The issue is marked for 8.x-1.3 but isn't the MR on 8.x-1.x?
Can we have a new release please?
Having the same error at /admin/config/services/openapi
I noticed this module could be relevant: ai_integration_eca
Yes, this would be great! The real automation and assistant capability come from being able to chain actions, and we already have a framework in Drupal, not only to define and run them, but also to visualize & customize their flow without code with ECA module.
I would say a natural language way of describing actions is with a [subject], [verb], [object], where normally the subject is the current user, the verb extracted from what the user asked the chat bot and used to find the closest synonymous from whitelisted action_id(s) and ECA models, and the object the closest [entity_type_id] or the [entity] provided by a token.
We could even define config entities that reference existing actions to provide metadata, ie. text suggestions on how to use the action, description of what it does, the synonyms above (for ECA models we could directly use their documentation field), and the entity types it can work on (for ECA models, ie. more abstract or complex actions, these could be custom inputs and outputs), to produce a rich list of actions that the LLM can pick from, trimmed down to only the ones that work on similar prompted [object]s.
@megachriz I think you are seeing Tamper only as part of Feeds, while it is a standalone module. I, for example, was trying to use it as a dependency to eca_tamper, to manipulate strings with actions inside my ECA models, and the hash plugin wasn't working.
If I change this:
public function tamper($data, TamperableItemInterface $item = NULL) {
if (empty($data) || $this->getSetting(self::SETTING_OVERRIDE)) {
$values = $item->getSource();
return md5(serialize($values));
}
return $data;
}to this, it will work fine as an ECA action:
public function tamper($data, TamperableItemInterface $item = NULL) {
return md5(serialize($data));
}
Now take a common (I think) implementation (like my case), where you need to hash an authenticated API request: it would be nice to use the much more popular & useful hash_hmac PHP function (but that requires a key input) instead of deprecated md5, something like this (even nicer would be to integrate with the key module to use secret keys defined there):
<?php
namespace Drupal\tamper\Plugin\Tamper;
use Drupal\Core\Form\FormStateInterface;
use Drupal\tamper\Exception\TamperException;
use Drupal\tamper\TamperableItemInterface;
use Drupal\tamper\TamperBase;
/**
* Plugin implementation of the hash plugin.
*
* @Tamper(
* id = "hash",
* label = @Translation("Hash"),
* description = @Translation("Makes the value a hash of the values of item being tampered."),
* category = "Other"
* )
*/
class Hash extends TamperBase {
const HMAC_ALGO = 'sha256';
const KEY = '';
/**
* {@inheritdoc}
*/
public function defaultConfiguration() {
$config = parent::defaultConfiguration();
$config[self::HMAC_ALGO] = 'sha256';
$config[self::KEY] = '';
return $config;
}
/**
* {@inheritdoc}
*/
public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
$form[self::HMAC_ALGO] = [
'#type' => 'select',
'#options' => hash_hmac_algos(),
'#title' => $this->t('Hashing algorithm'),
'#description' => $this->t('Select the hashing algorithm to use (defaults to sha256).'),
'#default_value' => $this->getSetting(self::HMAC_ALGO),
];
$form[self::KEY] = [
'#type' => 'string',
'#title' => $this->t('Hashing secret key'),
'#description' => $this->t('The secret key used to hash the value.'),
'#default_value' => $this->getSetting(self::KEY),
];
return $form;
}
/**
* {@inheritdoc}
*/
public function submitConfigurationForm(array &$form, FormStateInterface $form_state) {
parent::submitConfigurationForm($form, $form_state);
$this->setConfiguration([
self::HMAC_ALGO => $form_state->getValue(self::HMAC_ALGO),
self::KEY => $form_state->getValue(self::KEY),
]);
}
/**
* {@inheritdoc}
*/
public function tamper($data, TamperableItemInterface $item = NULL) {
return hash_hmac(self::HMAC_ALGO, serialize($data), self::KEY);
}
}
Describe how to override the template files provided by the module with custom ones provided by my theme or custom module. Simply calling the custom template files like those supplied by the module won't work (ie. override them) because they don't follow the standard Drupal template naming convention.
Can you share that code please? 🙏🏻
I think the most important would be link fields:
- having the option to show the link under the code would be great, so thatusers with the scanning device can scan it, but others (say mobile phone users, when showing a QR code) may directly click the link to reach the same destination;
- having the option to use custom protocols (for deep links) would be great too, ie. not only https:/ but myapp:/ or any other (whitelisted from settings maybe) open source protocol
I even tried disabling verification on each link decorator setting, without success, but I guess the field formatter setting should override the setting at each decorator, right?
kopeboy → created an issue.
I would expect the problem to go away after disabling the verification from the field formatter, but on every link field save the page takes ages to load and will again show the errors. Why is that? I even tried removing the verification checkbox on the modules settings for each social network, but the problem stayed. Should I open another issue?
I guess being able to reset passkeys is necessary for a release?
I tried with a different variation of ECA model as well, ie. I replaced the action to set the order token manually with one that loads the entity by Type & ID (selection Order entity type), but nothing changed.
Maybe we can take inspiration from this module: direct_checkout_by_url
This is the ECA model with which I'm trying. I just set up a Commerce store and a single product with 1 variation with sku "VAR1".
Nothing happens when I run the custom ECA event from the command line..
Can you provide a working example ECA model? Cause I couldn't get this to work and I'm not receiving any error messages
Last commit seems wrong: both
"drupal/draggableviews": "^3.0", and
"drupal/form_mode_control": "^3.0", don't seem to exist.
Shouldn't they both stay at ^2.1?
Is using a Service worker with Drupal something a curious Site builder can do though?
Does this mean that recipes can now be applied successfully on the command line, even if the configuration they include isn't actually applied to the site? How would a site builder identify pre-existing configuration issues and distinguish them from problems with the recipe itself?
FYI I noticed that the latest version of this module (v4, now stable) doesn't have this issue.
kopeboy → created an issue.
I just installed this module (version 8.x-7.1) on Drupal 10.3.6 and I can't reproduce this. I can create new content with the faq field empty and no error nor any field artifact will show up in the saved content.
Are you sure your field doesn't have the "Required field" option enabled in its field settings, nor the "Required Field Question" and "Required Field Answer" checkboxes in the field formatter options (at Manage Form Display)?
@sebastian-hagens: I know, you can see it even in my screenshot..
I had the subscriptions and I had run cron, but no DANSE events nor notifications were being created & sent.
I don't think you need this with CKEditor 5, as it supports inline code out-of-the-box (without adding any plugin/button/configuration): install a fresh Drupal 10 site and type `text` (the backtick) in any CKEditor textarea to see the text wrapped in <code>.
Looks nicer, but the old (horizontal) admin_toolbar is faster. I would like an horizontal option.
Since we are here (😅😇).. I noticed that the relevant CSS is not applied to the front-end theme, ie. when there is no CKEditor active on the page..
so shouldn't we remove the .ck-content class prefix from this CSS below, to make it look good out-of-the-box everywhere?
.ck-content .todo-list .todo-list__label .todo-list__label__description {
vertical-align: middle;
}.ck-content .todo-list {
list-style: none;
}
The margins top & bottom instead are irrelevant as a frontend theme will always have them already on lists (so I wouldn't touch all other CSS), but the margin-left is needed and missing from the frontend (see below), so I would add margin-left: 1ch; to the first declaration above (without the .ck-content class prefix).
AS IS while editing (with Claro default theme):
AS IS while viewing (with Olivero default theme):
TO BE while viewing (with Olivero default theme and the edits I described):
Yep, that worked, thanks!
Sorry, I didn't even now what "inject services in the class constructor" meant 😅😇, so I asked ChatGPT and tried to provide a new MR accordingly.
That worked! I didn't know about the configure key in the module.info.yml file, thanks!
I'm getting a warning by phpcs: Undefined method 'getEntity' (with and without the patch).
I don't have a use case in mind but it works fine 😇
A standard composer require won't work even with those linked projects.. Seeing from their README there are many steps to do 😅 And if they are correct, maybe they should be added to this module's README?
#2: I know, I was asking why they are unnecessary..
#3: thank you.. even if I'm not sure this module would actually improve in those 3 dimensions (see below), could this info be added to the module page or README?
- SEO: got some resources to share?
- Performance: you are altering/unsetting something that was already processed
- Privacy: could you provide some examples?
Thank you 🙏🏻
Thank you!
Yep, patch in #60 worked, and didn't seem to break anything! Thank you all!
Yep, that worked, thank you!
To @sebastix: no, the issue is unrelated to pwa or advanced_pwa: I was just noting that the latter includes web push notifications and has a submodule specifically to correctly remove that feature.
To @ nk_: Unfortunately I had already Deleted the service worker and removed the test site, so I can't Unregister the service worker now because I don't see it anymore (as well as the error logs). At least this also means the original issue got fixed by itself, maybe Chrome just needed some time?
The big red "Unlock" button is supposed to clears service workers & subscriptions? It doesn't seem so, cause I've just reinstalled a new site with DANSE, push_framework, this module, registered a new key & service worker and subscribed myself with DANSE, but after clicking it, I can still see my subscription at /admin/reports/push-subscriptions, as well as the service workers in the Chrome console.
Regarding DANSE.. how to check the subscriptions? I don't see anything in the provided /admin/reports/danse, that's why I thought DANSE events are not even fired.
I had already given the instructions to reproduce! But here it's an even simpler one:
- Install a standard Drupal 10.3.6 site (I used DDEV & drush with
ddev drush si - Require & enable this module
ddev drush composer require drupal/tour - Check that there is a tour that should show up on Tour edit pages (
/admin/config/user-interface/tour/manage/tour_edit) - Go to edit itself or any other tour, eg:
/admin/config/user-interface/tour/manage/tours] - Click on the "No tour" button in the toolbar to start the tour
You can see the same problem on all 3 of the default tours provided, as well as new tour you might create, as I said in #1.
The problem is with the toolbar module and not with the navigation module. Just enable it and repeat the last 2 steps to see the problem "fixed".
Yep, that fixed it, thanks!
What do you mean with a ticket? From who?
Clear, thank you!
We should also support Drupal 11 since we're at it, please.
..or even a dependency on jquery_ui_slider module?
I confirm the issue and that that patch solves it. Please include in a release.
The difference is that with this you have the option to only edit the field if it didn't have a value (which is a condition that you could copy in a VBO action only with custom code, or by using eca_vbo module), and the benefit of not having to filter and select the entities to update: you automatically update all the entities that have that field, directly from the field settings form, so I would say it's pretty convenient for this specific use case, ie. when modifying the structure of your site (more specific than with VBO).
I think the feature is already available here: https://www.drupal.org/project/eca_condition → ☺️
I'm not the maintainer but I just installed the module on Drupal 10.3.6, with admin_toolbar disabled, and I didn't get any warnings or errors.. the module seems to be working fine (not with the new core's nagivation module though).
Could you provide the steps or some details on how to reproduce the errors?
kopeboy → created an issue. See original summary → .
Yeah, here it is. I'm still a noob at this.. is there a way to open an issue fork and propose a MR before opening the issue on Drupal.org?
My bad, this was intended for the tour_core project.
Actually, I think this is breaking danse module.
Even after uninstalling this module and the whole push_framework, and deleting the service worker from my Chrome developer tools (under the Application tab), I still get the same warning but only when a new DANSE notification is triggered. I suspect this is the reason the notification doesn't get created at all.
kopeboy → created an issue.
I should point out that instead it works as expected if the (core experimental) navigation module is enabled, both with and without the toolbar module enalbed (which should be superflous once navigation is used).
No error in the logs nor in the browser console whatsoever, using Chrome on macOS.
kopeboy → created an issue.
I confirm the issue is still present, and even changing the annotation of web/modules/contrib/contact_formatter/src/Plugin/Field/FieldFormatter/ContactFieldFormatter.php to "entity_reference:contact_message" doesn't work (all options other than just entity_reference are just removing the formatter.
This might be the solution: https://drupal.stackexchange.com/questions/233862/limit-entity-reference...
Yep, and the problem is not only that the fieldset or details element are not collapsible, the fields inside are completely missing!
v9.3 to v11, which are the versions that really matter for modules to be built with the new APIs, already count ~370k sites, ie. the majority, more than the rest (v6 to v9.2).
To update costs time and/or money, especially if you need a different module and content wasn't already easily exportable with JSON or CSV in their older versions. Drupal Association should lead by example and finally migrate Drupal.org and produce documentation while doing it. Just filming the process and making a timelapse with a transcript would be great imo.
What is holding Drupal back regarding extensibility & integrations lately imo is the difficulty in working with Javascript & using the features on the client's browser. There are plenty of useful FLOSS libraries on Github but I don't know how to plug them.
He wanted simplicity with Wordpress and you talk him into Symfony? 😅
I think that once you get a grip of all the good modules supporting Drupal 10 & 11 out there (it takes a long time to find all the good ones), as a site builder you will get infinite powers on Drupal, all absolutely for free. Even the upgrading/deployment part nowadays is much easier thanks to automatic updates, DDEV and its integrations with hosting providers. It just takes longer to learn, but that is also changing thanks to recipes now, and Drupal CMS. Have you had a look into those?
When I try to save an Address format from the manage display page, I get redirected to a weird blank page.
When I edit it from /admin/config/address-formatter is fine though..
So it could be that this is caused by CKEditor, but I'm not sure.
For sure adding a plain text option wouldn't hurt.
I don't know why but applying the patch with composer failed:
Cannot apply patch https://drupal.org/i/3474987 ( https://www.drupal.org/files/issues/2024-09-18/address_formatter_depreca... → )!
Applying it manually removed the error instead, so... RTBC
Btw, I noticed many warnings in my IDE.. for example at line 81 (right after what we are changing with this patch) I see:
...so probably we could do a better job in a future version.
I second catch, regardeless of the version, knowing which other modules are related is useful, both dependants and required (on which the module depends).
Any core action will be picked up by ECA.
I don't have a Slack server to try but the patch seems good?
Maybe a doubt about token substitutions: I'm not sure if ECA will automatically apply substitutions or you need to do it in your action code, but it the latter case, I would allow even the channel and user to be tokenized.