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