🇦🇷Argentina @hanoii

ericgsmith → credited hanoii → .

I apologize for not finding this before, I did search but didn't spot this one with the keywords I used. I ended up coming up with a similar solution. Both are OK and really simple but mine reduces code and uses a core function so I'll think it's a safer approach. I'll mark this as duplicate.

Thanks.

Please comment on the related issue 🐛 Doesn't work if Drupal is served from a subdirectory Active so you can receive due credit there as well.

It does need a test as it was mentioned there.

Hmm, definitely a dupe, I tried searching for something similar but my keyword-fu was probably not on its peak. I will comment there, I think this patch is cleaner and rely on a core function rather than string replacements.

MR!93 added.

hanoii → created an issue.

Adding the logo, I was going to add it to the page but then wasn't sure. Would you think this a good addition to the content?

@klemendev correct

I believe a patch release is still useful, to make things more future/proof.

i.e., I am running updates and happily update gin_toolbar to 4.0 but can't do 2.0 which I have to remember next batch of updates. I know it's a little thing, but so is releasing a patch release.

Just my 2c, congrats and thanks a lot!

FWIW, I removed all previous mantainers, latest commit trom anyone was circa 2020, if they ever express the will to be added again, we can revisit

If at all possible I'd recommend releasing a new stable 2.0.0 as soon as you see best. Also, would you be open to help maintaining the D7 version of it? No need honestly, but just wondering if you are open to it.

I saw lrwebks which I assume you added.

Thanks for pushing the module forward.

Did that and added @grevil. I will look into removing other maintainers sometime over the week. If you wish to do that yourself based on their d.org activity and/or the module, please do.

Thanks for taking interest on this module. I am personally not currently using it so it got behind in my support priority, but I know it has progressed on its own. I will take a look on the shape of it and maybe give it another chance.

I'll add Grevil. Full maintainers means just giving you the administer maintainer option? no prob

@anybody has been added as co-maintainer. I might probably clean up some of the other maintainers as I don't think they have been active in the module.

Hi All, I got all emails, sorry for not getting back, keep wanting to. Today's activity of @anybody reminded me of that. Will add set him up and close this issue.

I agree that 1.x and 2.0 marked as unsupported is the correct and best approach.

I just released https://github.com/hanoii/composer-should-not - this is something that I had in mind for quite a bit.

What I think should happen is that the module maintainer should release a 4.x being just 2.x but with a higher version.

I fixed this for 3.x, 2.x will likely receive no further update unless security issues arises.

Sorry if I am adding something without an actual live error. I didn't see this on a pipeline, I saw it on ddev. I guess you wouldn't see a fail on a missing composer.json file because of what was explained to me on #4.

But ddev-drupal-contrib addon tries to emulate gitlab ci and uses the same script so that's why I thought I should at least mention this. But honestly, it maybe a non issue for gitlab ci.

I saw the account for no composer.json was added/updated on ✨ Preserve original composer.json in the modules directory Fixed .

PR added to https://github.com/ddev/ddev-drupal-contrib/pull/80 - thanks all!

@moshe weitzman thanks! I read the readme and I run `ddev poser` and failed! It was what prompted this issue

Excellent, I will fix it on ddev then.

I think what 💬 Inform jobs about the "composer" job exit status and bail out early Active made was for this to fail silently on ddev.

Also added https://github.com/ddev/ddev-drupal-contrib/issues/79

I just added 🐛 breaks if no composer.json is present on the module? Active , which it might be a follow up to this.

hanoii → created an issue.

I think we have to remove the recommended version from 3.0 and also, why would a module want to two separate feature-set maintained. Isn't it better for folks in 8.x-1.x to just upgrade to 2.x?

https://git.drupalcode.org/project/domain/-/merge_requests/95/diffs#58c9... was the same original code before PHPstan, but the replacement was OK instead of what this issue fixes, so maybe it was some accidental backspace or anything, but still worth understanding the automatic code fixing that went through the related issue.

hanoii → created an issue.

I use Gin on most of my projects and 🐛 Order select shows on a translation of a paragraphs field on 10.2+ Fixed definitely sorted it out also on Gin.

Yes, I accidentally selected support. After using this, making it a $setting is even better than a config because it allows for dynamic configurations on settings.php.

i.e.

$settings['memory_profiler_threshold'] = 120;

// Admin paths
$admin_paths = [
  '/knowledgebase/admin',
  '/knowledgebase/node/add',
  '/knowledgebase/node/%node/edit',
];
foreach ($admin_paths as $path) {
  if (strpos($current_path, $path) === 0) {
    ini_set('memory_limit', '256M');
    $settings['memory_profiler_threshold'] = 240;
  }
}

$high_memory_paths = [
  '/knowledgebase/metrics',
];
foreach ($high_memory_paths as $path) {
  if (strpos($current_path, $path) === 0) {
    ini_set('memory_limit', '512M');
    $settings['memory_profiler_threshold'] = 500;
  }
}

MR!5 is a simple addition to the code.

hanoii → created an issue.

Addressed feedback.

This is a longish issue, I tried following but different things were going on. I happened to work on a fix about url access and I wanted to share my work here.

My recommendation would be to maybe try to get the access bit first (which is easier) and then something more robust for the breadcrumbs in general?

In anyway, the two MR can co-exists and I will be using on a product of mind.

This is pretty much the same fix that the one #3319445-26: Edit link in breadcrumb region shows even when user has no permission → , and they likely should be applied together.

hanoii → made their first commit to this issue’s fork.

The rebased one was missing some twig changes, I happened to worked on fixing this before having found this issue :facepalm:

I a very similar thing and went ahead and push it, it makes it cleaner in the the twig and uses the proper drupal services.

hanoii → changed the visibility of the branch 3319445-edit-link-rebased to hidden.

hanoii → changed the visibility of the branch 3319445-edit-link-in to hidden.

hanoii → made their first commit to this issue’s fork.

Thanks! I thought about that, but I figured that that the change is very minimal that it would make it a burden to have to maintain two separate branches for some time only for this change unless there's a strong opinion that 2.x would is EOL and all will happen in a new 3.x.

While maybe not exactly the same, I believe that ✨ Support the new assets stream wrapper on Drupal 10.1.0+ Needs review should help with this on 10.1+, at least make it store it locally instead of s3fs which is what I would expect for dynamically generated assets.

hanoii → created an issue.

hanoii → changed the visibility of the branch 3454273-order-select-shows to active.

hanoii → changed the visibility of the branch 3454273-order-select-shows to hidden.

hanoii → created an issue.

Thanks! For some reason I thought that hook was not needed anymore and the sort plugin was discovered on its own. I even searched for it, but something must I obviously missed something. Apologies, 2.0.1 is out!

After coming back to this module a long time, and looked at this issue, I think is a bit too complicated for the module. Not codewise, as the code is simple enough, so thanks for that, but support-wise, as I can see this nor working as expected in many scenarios are views arg are not always so literal.

Besides, the views argument sometimes gets into the sql so there might be ways this can still be used in the sort argument. If we were to add this I would like to have tests or something with different kind of arguments to make sure we are doing things properly.

Finally, formattedText seems and odd use case for this kind of things.

Although old, the answer would be yes. There are many ways of doing this, but one could be removing the dot and casting them as integer.

Although old, I tried to reproduce it and it just worked, and this module is not doing much with the entered expression.

hanoii → created an issue.

hanoii → created an issue.

Understood. Although I'd recommend if that's the case to maybe release a new version with only support for D10.

Because the fact that 4.3.1 installs but with a very old solarium library it's potentially dangerous, I actually found another project that I didn't upgrade under this same situation. Or maybe fix -dev on composer to match the actual latest so that dev is also not picked up by composer for 4.3.1?

Fix on the previous re-roll as schema was already there.

Re-roll against 2.x

Will this still allow to install 4.3.1 on Drupal 9.5.11?

Please have a look at #2453585-16: Local Storage for Coffee →

6 years after the last comment I needed this feature, as I wanted to offload this request to a multisite on with not a huge amount of resources.

Overall I feel it's quite good, I added an install hook, a configuration option and small theme tweaks so that you can see if the data is cached as well as an option to refresh it. See MR !8

6.x-dev is actually a lot older than 6.2.3

hanoii → created an issue. See original summary → .

Following the remaining steps of the process - owner haven't replied yet - summary updated.

https://www.drupal.org/project/notify_bar →

I think a permission would just work, it is config but you set it as part of your deploy, so a role that have a perm can be assigned/removed from the user as necessary.

I can't think of an issue with the permission.

I also wanted to provide another means of setting the read only lock (globally) and I wondered if using state is also a nice alternative, as that can be changed on the fly through drush or other means.

hanoii → created an issue.

I've just contacted https://www.drupal.org/u/dhanrajlakhara → through his Contact Form:

Hello,

I've already got maintainer access on https://www.drupal.org/project/projectownership/issues/3235895#comment-1... → and I just filled in a request to become an owner of the module on https://www.drupal.org/project/notify_bar/issues/3397888 💬 Offering to take ownership of Notify Bar Active .

I've also fixed most issues and released a new version for D10 and D9.

It looks like you are not active in Drupal anymore, and I would like to take the lead on the project and becoming the onwer feels safer for the long run.

I would advise you to provide feedback on this request on https://www.drupal.org/project/notify_bar/issues/3397888 💬 Offering to take ownership of Notify Bar Active .

Thanks,
Ariel.=

hanoii → created an issue.

Fixed in 2.x

Fixed in 2.x

Fixed on 2.x

Fixed in 2.x

I am picking up on the feature @nehajyoti mentioned (she worked in the agency I am working on where we use this module) and improving upon the module which needs quite a few things, which I am willing to maintain.

Am I just added as a maintainer or can I own the module to take the lead upon it?

Thanks!

hanoii → created an issue.

hanoii → made their first commit to this issue’s fork.

I fixed it but apparently I can't resolve the thread. @jwilson3 maybe you can?

Thanks! I personally don't like casting as a way to sort issues, I rather make sure that the issues don't happen or add proper conditionals. Most of this have been fixed as part of d10 compatibility work which will soon be released.

Hmm, this is a patch for drupal core, probably not where this issue belongs and very likely outdated. For now closing, feel free to add it to the drupal core issue queue.

This has been fixed in the upcoming 3.x releases

Changing supporting organization.

Thanks a lot! This was already fixed by me before checking on this patch, this is already committed to 2.x. Soon a 3.x for d10 will be released.

@gisle, do you mean because I assigned this issue to me? I am sorry, I read the issue description and it says:

A prospective new maintainer can take this issue after the 14 day window has
elapsed and take the following steps to be added as a maintainer:

I understood by "take this issue" that I needed to assign it to mayself and then do the sub bullet points. If I understood it wrongly, I apologize.

As part of my line of work this module is being used and we'd like the option to update it both internally and for the community.

Thanks!

I am gonna close this one, it doesn't look as an issue, trying out on https://simplytest.me/configure?project=config_ignore_auto just works.

DieterHolvoet → credited hanoii → .

Just added you as a maintainer! Welcome!

Thanks for the bug report and the MR. Although it's looks like pretty safe, I am having trouble reproducing it.

drush eval "var_dump(\Drupal::config('config_ignore_auto.settings')->get('ignored_config_entities'));"
array(0) {
}

The configuration entries should really never be null or empty string as they are set by default through the initial config.

Also, whitelist_config_entities should never be null because core.extensions should never be auto-ignored.

I rather try to understand why this happened to you, it doesn't look like a bug on the module

I started researching what's going on around this issue. I will likely use 'make_unused_managed_files_temporary' for now, but I was wondering if a module that (as opposed to most of the modules out there that tries to add some smarter capability) that adds a setting to each file field so that you can manually set which file file flags a file for deletion when the entity is removed.

I applied #2671162-116: Also use text editor (CKEditor) for "summary" of a text field → on 11.x and manually edit the editor.js file as the es6 file was removed.

Also, some of the test files modified on the patch there were removed in #3270438: Remove CKEditor 4 from core → so leaving the other tests.

This is a duplicate of 🐛 Drupal 10 proper once dependency Fixed . Almost the same patch.