🇦🇺Australia @geoffreyr

I've put up a first pass based on what we have going. I think it's pretty rudimentary compared to what we want to accomplish. I'd rather avoid modifying the template too much, as I'm assuming a lot of site builders make their own edits to the template.

That said, if we're changing the template, I wonder whether we should consider using <details> tags for the facet containers... this would allow us to set the open attribute on them and make the facet containers collapsible.

geoffreyr → created an issue.

Adding a bit more to the description. I want to take a look at config changes before we look at RTBCing -- might be difficult to merge given how much else is coming through.

Got a draft MR in, which is what we've been using in production for a little while now, but I don't feel that it's ready to be merged back into this project yet. I think we'll need to add the config.factory service to funnelback.querystring and clean up the services before we're good to go. There's also still the question of passing the tracking URL to the node view mode, which I haven't thought about yet.

geoffreyr → changed the visibility of the branch 3460721-add-support-for to hidden.

Marking #3435248 🐛 Inconsistency between general_settings.results and general_settings.pagesize Needs work as related because we depend on the config schema being present.

I reckon we should continue working on PHP Codesniffer fixes in the issue that has the merge request attached 📌 Fix issues reported by PHPCS Active .

One change I added in the latest version of the MR is to give the attribute merging its own dedicated method PasswordConfirm::combineAttributes to merge the attribute arrays. This allows us to reuse the same merging code across both pass1 and pass2, but also to normalise the autocomplete attribute for both.

The reason why I think we have to normalise autocomplete is because the Nightwatch tests appeared to pick up a case via Axe where pass1 on the user edit form was invalid. After some investigation, I found that pass1 was rendering with the attribute autocomplete="off new-password", which appears to be invalid. To this end, I've tried to pick up the "off" value within either the array or string values of this attribute, and if it's found, reduce it to just autocomplete="off".

A good example of where this might be set is in \Drupal\user\AccountForm::form. This obviously makes handling attributes more complicated, and I'm wondering if this too is the right approach.

With Drupal 7 reaching End Of Life in January 2025 → , this issue is now outdated. Drupal 8+ supports image style tokens via the Token module using a token format along the lines of, say, [node:field_image:thumbnail:url].

Issue summary updated as of #60.

Issue summary updated as of #79.

Might have a crack at rolling the most recent patch into 11.x.

Started a new MR based on @mortim07's patch in #39. I added support for default_revision and keep_untranslatable_fields arguments in the createRevision call; this means that we can do things like keep a revision published while updating the entity with a new draft revision.

I reckon it'd be pretty good to be able to add a revision log message and UID, but I'm not sure of the best way to do it yet. I'll have a think and see what could be done.

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

The latest version of the MR now has a dedicated form and test case for Password Confirm widgets, and the hook to modify the User Registration form has been removed.

@smustgrave Thanks for your checks. I've updated the issue description to try and conform to the current template. I don't know much about upgrade path tests but I'll try and figure this out while I'm working on this issue.

I might also see about adjusting the MR and tests further to add functionality. I'd like to ensure we've got an "on demand" setting that lets the field remain empty as long as we need it to.

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

I think I've fixed the TimestampTest by ensuring that $this->fieldName gets set. I still see a lot of tests failing but none of them relate to the timestamp widget.

BTW hi @man-1982 long time no see (:

We're now using this in a production deployment and are happy with the way it's been working.

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

We've been working with patch #17 in this issue for some time. I've rerolled #30 against the 9.0.x branch and created a merge request.

geoffreyr → changed the visibility of the branch 3008580-impossible-to-index to hidden.

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

We're interested in getting AGLS 2.0.x going so we can upgrade our Metatag installations. I might try it out as is at our end, but is there anything you might want a hand with?

geoffreyr → created an issue.

geoffreyr → created an issue.

Might want to look at odata_client.odata_server schema errors 🐛 odata_client.odata_server schema errors Active first before we add anything new to the schema.

geoffreyr → created an issue.

geoffreyr → created an issue.

This one doesn't merge with 1.1.2 or the current DEV; might try and re-roll.

@dalin Thanks for the feedback! I appreciate that adding a whole plugin system does run the risk of overcomplicating things. Perhaps this sort of functionality might be more useful attached to Crop module itself -- that way, it could work with other methods of cropping, such as cloud solutions that provide smart crop bounding boxes instead of focal points. This might also help get around the issues with Image Widget Crop pre-emptively removing the Focal Point crop.

In our hook implementation we check $crop->isNew() before updating the coordinates, so perhaps I should update the patch with either the same behaviour or explicitly check whether the crop coordinates have changed, as you suggested.

Lot to think about here. I'll see what I can do to make this more useful.

mingsong → credited geoffreyr → .

We needed to do this for our use case, so we patched Focal Point to allow us to hook into the focal point values before they get saved. This might allow for some variety of solutions, whether they be backend, remote, or frontend.

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

geoffreyr → created an issue.

Very curious that these phpcs issues weren't picked up by the GitLab CI pipeline, which should cover that. I'll take a look.

Looking to address this one in #3435248 🐛 Inconsistency between general_settings.results and general_settings.pagesize Needs work , since we'll need it for keeping track of the new general_settings.results setting.

Targetting to 2.0.0-beta4.

Targetting to 2.0.0-beta4.

Targetting to 2.0.0-beta4.

Updated MR with a post-update hook, as well as a module schema file.

Updated MR with a post-update hook, as well as a module schema file.

geoffreyr → created an issue.

This was released in 2.0.0-beta3.

That took a little while, but I finally got a merge request going with a PHPUnit test for the FB16 data. This code is already running in our PROD environment but if anyone wants to review by all means go for it. I might line up a new beta release featuring this update -- the good news is that it should be backwards-compatible.

Here it is: https://www.drupal.org/project/funnelback/releases/2.0.0-beta3 →
I mucked up my own contrib on 3441681, so I'll make sure to do future merges through d.o so I don't lose anyone else's.

Merged and closing.

I might have a second look at this later -- we probably don't want that event change and I could reuse $hashElem.

geoffreyr → created an issue.

Thanks Lee! Given you prefer frequent releases, I might look at doing a 2.0.0-beta3 for the issues that are already committed to 2.x, and do additional ones for individual features as you suggested. The CI/CD one would be a good one to get in so we can start testing all changes yet to come.

geoffreyr → created an issue.

Added a Composer requirement for drupal/core matching the info.yml file.

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

MR ready. If you want to set 3.0.1 as being for 10.3 and above you won't want to merge this, but anyone else who finds this issue can use the plain diff source to download it and use it in their sites.

geoffreyr → created an issue.

geoffreyr → created an issue.

I've been trying this out with an implementation that uses IEF Table View Mode and so far it's working well. Much more concise and reliable than patching IEF to remove the sort elements. I'm not going to RTBC it until we test and deploy it, but this looks really promising.

I've tried rerolling #18 against the latest 2.x. It seems to work but I reckon it needs a bit of a look. If anyone else wants to check the branch out and make changes that's all good.

MR available for review.

I've got a case where I have a CSV with a lot of line breaks in the cells that I'd like to convert to HTML <br /> markup (nl2br style). This feature might allow for what I want to achieve, so I'll see if it's possible to render out the cells with a text filter set.

You're quite right. Sorry!

I've uploaded a patch to let Linkchecker ignore non-numeric content entity IDs when deleting. This is a hack at best so I'm not putting it through as a proper merge request, it's more to let people who use Entityqueue or modules that do similar things with entities use Linkchecker alongside it.

I recommend that we identify and implement a proper solution.

geoffreyr → created an issue.

@vaish Thanks, will do.

We've been using this one in PRODUCTION for the past two months, so moving to RTBC.

We've been using #11 in PRODUCTION for some time so I'm also +1 for RTBC.

geoffreyr → created an issue.

MR is in. I should review the existing tests to see if the behaviour is already covered or not.

geoffreyr → created an issue.

We've been observing this same issue. The original MRs no longer apply, and they appear to have no extant use since we're seeing position: fixed applied via JS, presumably from a completely different part of the theme. We'll have to dig into this in a bit more depth to see how the dropbutton styles are applied at runtime.

We've finally got this implementation into PRODUCTION, so I might look at finishing off the tests so it's ready for review.

This might be a little more complicated than I'd hoped because there's currently no way to enable or disable specific entity types from being managed by this module. It's all or nothing, which is probably why the admin form is crashing hard all the time.

I might take a look at https://www.drupal.org/project/form_mode_control/issues/3431354 🐛 Config schema is incorrect Active which aims to fix some of the config mapping issues.

geoffreyr → created an issue.

@Mingsong Good catch on the data typing, thanks for making the change!

Amended issue title accordingly. MR to come shortly.

@Mingsong No worries, happy to shed some light on the intricacies of this issue. It's not really about the number of matches returned to the autocomplete; it's about the autocomplete text input field itself being hard limited to 1024 chars long. Here's a discussion covering some one-off fixes for the issue. Since EntityReferenceTreeWidget is a child class of EntityReferenceAutocompleteWidget, we'd be overriding the limitation present in EntityReferenceAutocompleteWidget::formElement.

Instead of doing a one-off fix, we figured making the widget more flexible would be a better solution. A patch to the widget would be a good start, and I'm currently working on this.

geoffreyr → created an issue.

We're using 3.1.0 in PROD now and everything looks great. Thanks again for version 3.1.0! Closing as fixed.

Thank you very much! Very kind of you, it should do the job perfectly. We'll get this version into production as soon as we can.

geoffreyr → created an issue.

Ok, looks like I've fixed the exception throwing.

Doesn't handle boolean results properly. Need to fix.

Adding #3441681 as related; I'd like to get this implemented so we can test our changes.

I think I've worked through most of the code quality issues. I can take a look at some of the other patches that I've been using to work out what to change. There aren't any changes to templates, so most people who've been theming Funnelback pages, blocks and results shouldn't be affected.

Looks like I've got a lot of code quality fixes to sort out before we can proceed. This will probably affect a lot of other pending patches and MRs unfortunately; might be a big job.

geoffreyr → created an issue.

I'm going to mark this as needing review, as we need this functionality too, and I'd like to see how it goes in our production environment.

Updated the MR to cover RequestPluginBase as well.

geoffreyr → created an issue.