I didn't test it but from my understanding after updating to CKEditor5 obsolete options are removed automatically, someone needs to check it out.
LGTM. Thank you.
dinazaur → made their first commit to this issue’s fork.
The schema bug should be fixed in the latest dev. I keep this ticket open because we need to remove not existing options from config schema e.g.
use_advanced_pattern:
type: boolean
label: 'Use advanced pattern?'
pattern:
type: string
label: 'Pattern'
advanced_pattern:
type: string
label: 'Advanced pattern'
We should add form validation, because support same marker for multiple plugins is a bad idea
Thanks for the work. LGTM
dinazaur → made their first commit to this issue’s fork.
We should also fix it in Realname plugin. I don't like idea of hardcoding 50 items, we already have dropdownLimit option, we can pass it into ajax call and use it inside plugin.
Thank you for you work, we already merged this fix in 📌 Drupal 11 compatibility fixes Active so no need to merge it here.
@jaydarnell could you test if 3512131 resolves you issue?
@todo Add credit for: atoll and jaydarnell (#3453103)
> How about fetching image data from default field like user_picture ? (ex: field_image)
There's no default image field in node. It might be anything and different for each node type. From my point of view, #3512131 is the only appropriate way. If someone wants to display images for nodes, there are plenty of ways to add an image token to the response.
Thanks, great work
dinazaur → made their first commit to this issue’s fork.
> I will not tolerate entitled users who demand that I (a volunteer) work on
Who in the world demanded anything from you?
If a question "Could you please explain why the patch vs issue fork is such a big issue?" is "demand" for you, I'm impressed. Creating a patch just because of your habits is not something I wanted to do, 4 years ago this module had 0 (zero!) tests. So the only reason you demanded is your whim. So to clarify, the only demander here is you.
> fix problems that that they (paid employees) are experiencing.
I reported the issue, and provided a fix, while I could create a local patch and didn't bother creating any issues here. I didn't make a "Feature request", I implemented a fix to the issue, reported it, described it, and provided reproduce steps.
> If you care about this project and/or this issue, then contribute.
Providing a fix is not a contribution? okay.
> I feel no obligation to do your work for you.
As I said, no one told you to do any work. In fact I'm willing to close this issue.
> needs patch put into a MR
Ahahahaha
one
🐛
VotingApiWidgetBase::getVoteSummary method doesn't work correctly.
Needs work
,
two
🐛
VotingApiWidgetBase::getVoteSummary method doesn't work correctly.
Needs work
. As you said, Fuck you.
> needs a test
For one clear as fuck condition, ofc you're. Hopefully you get banned from drorg.
bohart → credited dinazaur → .
dinazaur → created an issue. See original summary → .
dinazaur → created an issue.
dinazaur → created an issue. See original summary → .
dinazaur → created an issue.
dinazaur → created an issue. See original summary → .
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.
> About the deprecation, I disagree. I still see use-cases for an actual Drupal module over a plugin:
I didn't mean to deprecate module over plugin. I meant to deprecate plugin over native drush generate phpstorm-meta that has much deeper integration with PHPStorm since they provide support for routes, roles, services, settings, states, fields, field definitions, entity_types, date formates, configuration and more. You can see all the things that they provide here. Just run drush generate phpstorm-meta and you will see every file it generates. Drush depends on Chi-teck/drupal-code-generator, that provides all templates for drush generate command.
My friend of course I added alternatives - here you can see them → .
The only issue I see is that this module should be deprecated in favor of native drush phpstorm-meta because it provides much deeper integration with phpstorm, you can check all templates that they provide here.
dinazaur → created an issue.
I'm not sure what you're trying to achieve but it is not even close to what should be done. Probably some chat gpt hallucination.
First of all I'd like to hear answer from maintainer and then implement it by myself, because that's not a big deal.
Reported as a spammer prem suthar.
dinazaur → changed the visibility of the branch 3496585-retrieve-fields-from to hidden.
So my question is do I missing something or can't we actually retrieve data from index? Why do we use addField if Retrieve result data from Solr is enabled.
dinazaur → created an issue.
For each query we add tag.
https://git.drupalcode.org/project/ckeditor_mentions/-/blob/8.x-2.x/src/...
Use hook_query_TAG_alter
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Database%...
Sorry for the delay.
The module doesn't support such a feature, you will need to implement something like this by yourself. The possible implementation would be to save form state in database using user's session id, in case of anonymous users it would require starting a session when he visits a page with a form. Such a feature is out of scope of the module.
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.
@avpaderno you're right. I thought that it was possible to omit parameters because the code sniffer allowed → to do it. There's a current discussion about " Allow omitting doxygen ... 📌 Allow omitting doxygen when type and variable name is enough Active " I suppose sooner or later they will allow omitting them as they did with constructors 🌱 Allow constructor methods to omit docblocks Fixed . But anyway it is not possible right now.
What is possible to do is to:
Omit @param and @return documentation for the standard parameters and return value (such as $form and $form_state. in Form-generating functions →
what apparently is a case, cause the only places where I omitted docs are for $form and $form_state params.
@solideogloria
The MultistepForm::prepareWizard should have its parameters documented in the function doc comment.
Drupal coding standards allow to omit documenting function parameters.
Your README.md does not follow best practices
Yeah, it does not. This module was created for developers only, site builders will never use it, hence I don't see reasons why I should change README format.
@vishal.kadam
@branch is a wrong name for a branch. Release branch names always end with the literal .x as described in Release branches.
It is wrong and was created by the previous maintainer. From what I see it is not used as Release branch. And because of that, I think it is okay to keep it, cause I don't know why it was created in first place.
Fix phpcs issues.
I already answered about README, but I'd to quote README.md template → page.
Please note that the Drupal Coding Standards have not yet been updated to allow Markdown files, conversion should only be undertaken at the request of an existing project maintainer.
FILE: multistep_form_framework/modules/multistep_form_framework_examples/src/Form/BuyBookStep/Description.php
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
54 | ERROR | No key specified for array entry; first entry specifies key
--------------------------------------------------------------------------------
I cannot reproduce it. I'm using latest (8.3.25) Drupal coder version
@zovsky Yes, this is cause they are handled in a specific way. You can check how they are rendered inside the user module and replicate this logic.
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/user/...
Re-roll for 2.1.
Since
#2997675
✨
Provide image effect to scale by width only
RTBC
was merged but no one updated effects array. I changed the status to Major because users can't see a preview of the plugin (focal_point_crop_by_width) that is provided by this module.
We should definitely rename it to "Focal Point crop by width only". I'm not sure why this was merged. This person always merges everything without even looking at the issue, I'm not sure why he is still not banned from Drupal org.
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 → .