Yes, it works. 700+ people are using it. The only possible thing that can disable it is the configuration option (see screenshot)
Apart from field autocomplete it should also autocomplete other stuff. You can check if #theme, #type autocomplete works (check Autocomplete for #theme, if not then I'm not sure what's going on
The fix will be available in a few days.
https://github.com/nvelychenko/drupal-extend/commit/14f1d3b6f6609441969d...
Hi, to clarify. There is a directory icon where you can choose it.
dinazaur → created an issue. See original summary → .
Hi @sime. Thank you for the report. That's a known issue. The only broken thing is IDE no longer knows what is \Drupal::service('blabla'). I'll take a look at it next weekend.
Changing the priority according to Application review Timelines
The priority of applications that have been waiting for a review for more than eight weeks is changed to Critical.
Changing the priority according to Application Review Timelines
The priority of applications that have been waiting for a review for more than three weeks is changed to Major.
bohart → credited dinazaur → .
Re-roll patch created for 10.2.3
dinazaur → created an issue.
Looks good to me.
Just for reference here is logic from #16 https://git.drupalcode.org/project/photoswipe/-/merge_requests/119/diffs...
Eh, our developer almost finished this implementation, don't want to throw its work away. But I also don't like this thing. I guess we can at least remove all stuff related to this issue, like this->isAttached etc. I will tell him to remove it.
We cannot attach it "once" because there might be cases when the element to which it was attached was not rendered. e.g. #access = false and all subsequent elements to which it should be attached will not contain a library at all.
So the solution is only one in that case. We can cache result of photoswipe_js_options hook since it does not contain the actual element so users cannot detect which element is used now, so they always return the same result theoretically. It means that we can cache it without worries. By cache, I mean static variable once per request. I don't see reasons why we need to use actual cache
Also if there are override options we should not cache it and trigger our hooks.
That's the only thing that we can do here.
dinazaur → created an issue. See original summary → .
Hello @ChristianAdamski is there any reason why you didn't give credits to people who worked on this issue?
Contributions to credit The following are examples of types of contributions that should be recognized: →
- Creating a well-written issue that describes a problem
- Proposing a solution (either in the form of a patch, or a text comment)
- ...
dinazaur → created an issue.
Hi @trickfun I guess you are using an old version of module, because path (libraries/photoswipe/dist/photoswipe.min.js) you provided is not the same as in our librarier /libraries/photoswipe/dist/umd/photoswipe.umd.min.js file.
Other problem could be that you have not cleared cache.
Looks good to me
Hi @Anybody just to clarify. What we need is to implement 4 formatters - 2 for image (Responsive and Not) 2 for entity_reference (Responsive and Not) Is that correct?
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
Looks great! Thank you.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
dinazaur → created an issue.
Here is a link → to related Drupal.org project ownership issue where I explained why I'm doing such a change. I just didn't want to make another module on Drupal.org and took the obsolete module and reworked it from scratch.
So here is a screenshot that shows commits in 2.x branch only.
And here are explanations of what is inside 2.x branch. My initial commit contains 1941 additions and 406 deletions. I've removed all code from 1.x branch. So the 2.x contains all my code.
Hello, literally 2.x branch contains all my code. I deleted whole 1.x version when took the module. And reworked it from scratch. So this one commit is literally whole module
<?php
namespace Drupal\example\EventSubscriber;
use Drupal\ckeditor_mentions\Events\CKEditorEvents;
use Drupal\ckeditor_mentions\Events\CKEditorMentionsEvent;
use Drupal\message\Entity\Message;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
class Example implements EventSubscriberInterface {
public static function getSubscribedEvents() {
return [CKEditorEvents::MENTION_FIRST => ['onMention']];
}
public function onMention(CKEditorMentionsEvent $event) {
if ($event->getPlugin()->getPluginId() !== 'user') {
return;
}
$notification = Message::create([
'template' => 'some_template_id',
'uid' => $event->getMentionedEntity()->id(),
]);
$notification->save();
\Drupal::service('message_notify.sender')->send($notification);
}
}
@lazzyvn
Check on ckeditor5, it work great
Can you support some module notification please
This is a straightforward implementation in custom code. You just need to react to the Mentions event. I don't see any reason why we need to implement such thing in this module.
Hello there. It was a long way. Let's merge it into 3.x branch and create a beta release. I'll create a follow-up ticket for tests adjustment.
dinazaur → made their first commit to this issue’s fork.
Thanks all, great work. I've included once fix in the PR.
dinazaur → made their first commit to this issue’s fork.
dinazaur → created an issue.
Fixed issue in the examples module.
Hello,
Unfortunately, I no longer need assistance. I have already made a release for D10. And in the future, I will continue to support the module. I just got a bit off track.
I'm not sure that understand the question, this module is all about form state manipulation, if you want to clear all steps states, you can simply remove all information from form_state. I just don't know what you're doing there.
Unfortunately, 1.x is not supported anymore.
Unfortunately, 1.x is not supported anymore.
Unfortunately, 1.x version of module is not supported anymore.
Hello, I had an issue with the styles applied to the modal, especially the backdrop. The patch resolves the issue.
Fixed a bug that was caused by dialogSettings.options property. It led to unexpected behavior on modals. Sometimes they missed actions, not opened at all.
It seems that you just closed the issue without even reading the context. Who even said something about Bootstrap 4?
Okay, I just made a few changes. What's left to do is to implement an upgrade path, and remove unneeded properties from configuration. Apart from that it's ready for review.
dinazaur → created an issue.
Hi, I will have a look at this MR over the weekend.