🇦🇺Australia @geoffreyr

@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.

We're using the MR with cache context in production right now. Works really well and haven't seen any issues with cached search queries.

@larowlan Thanks, I'll give it a go.

We've been using this patch, but it's had the interesting side-effect of showing other users' unrelated search queries in cached search blocks. Need to dig into this a bit; maybe a custom cache context would help.

@larowlan Sounds fair enough. My MR is above but I expect it'll need more documentation, a changelog update, etc. Probably depends on when we want to cut a new release.

geoffreyr → created an issue.

A rough first pass indicates that Funnelback module really doesn't depend on Drupal core search at all. No hooks, no config, no permissions, nothing. I'm putting together a patch for myself which I'll soon contribute back here, but we may want to add an update hook to warn module end users that it no longer needs core Search and they should disable it for themselves if they like.

We're actively looking at using the patch from #52 in production so we've created a MR for it. It also incorporates some minor fixes for D10 compatibility; there may be more adjustments to come. Will look at 2472941 when I have the chance.

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

@abhishek_gupta1 Thanks for your patch. I've submitted a MR which does the same thing but is a little bit more terse.

geoffreyr → created an issue.

I've worked out that we can go to the Advanced tab and set, under Custom Options, something like timeout: 10. This works as intended, albeit that if that timeout is ever exceeded, it throws a fatal error that Webform module can't recover from. It looks like Guzzle is throwing a ConnectException on timeout, which isn't classed as a RequestException. This is also a problem with Webform's own RemotePostWebformHandler, but I don't see a reason why we shouldn't fix this here.

geoffreyr → created an issue.

@sarwan_verma Thanks for submitting your patch. I've done up an MR with this change and also fixed a few uses of this method throughout the module.

geoffreyr → created an issue.

geoffreyr → created an issue.

We've been using #18 to adjust the CSP to allow for some rich legacy experiences that take over the page. We're taking configuration from Composer files in separate repositories to adjust the CSP rules for particular page requests -- highly custom but very effective. This patch has been of great benefit to us; and given that the patch provides new tests for this case, and that they're all passing, I'm willing to RTBC this.

I think this should pass muster, casting to an int appears to round floats appropriately. In this case it doesn't really matter which direction it rounds, but (int) (37 / 2) rounds down to 18. Suggest we do it as a merge request so it can go through all the pipelines.

geoffreyr → created an issue.

The patch for this issue doesn't apply on 10.2.5, apparently because #2825860 🐛 Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput() Needs work got merged and directly conflicts with MR 5391. It looks like it should do the same thing albeit expressed differently. Can anyone else confirm?

geoffreyr → created an issue.

geoffreyr → created an issue.

Added a change to the WebformMatcher so it implements EntityMatcher::buildPath. This allows us to use the webform's configured alias if it's available.

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

Just pushed an update to the merge request adding an update hook to add the `id` column if it's not already there. This will help users with existing installations.

Sorry about the implementation, it's hacky, but I couldn't find a better way. The issue https://www.drupal.org/project/drupal/issues/3264915 💬 Can't update database: Syntax error or access violation: 1075 Incorrect table definition Closed: duplicate describes a similar problem.
We might need to check other database types (SQLite, Postgres) to see if this method is valid or not.

We should probably add a hook_update implementation to add the primary key for cases where it does not already exist.

geoffreyr → created an issue.

geoffreyr → created an issue.

I had a bit of a go at porting this to D9/10. Not sure that we should call the parameter max_nodes_per_cron anymore, maybe it should be renamed to reference entities in general. publish and unpublish methods take the limit as the command, but default to 0 so the original invocation should continue to work (albeit with no limit).
Will iterate on this when I have the opportunity.