Closed (outdated)
Project:
Wordfilter
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
15 Aug 2010 at 21:11 UTC
Updated:
28 Mar 2022 at 07:38 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
jaydub commentedI see that this is problematic and includes the case where the word to filter is at the end of the content as well.
Can you try out the attached patch to see if that helps? This is against the development snapshot which should be updated with another commit by tomorrow at the latest.
Comment #2
jaydub commentedComment #3
Michsk commentedNo it does not seem to work, don't know how to explain the error. It just doesn't show the content.
Comment #4
jaydub commentedwell the patch worked for me so I'm gonna need more info from you as to how it did not work for you.
Comment #5
Michsk commentedmm, well i would love to give you more info but it just doesn't work. The content (text) that uses words that need to be replaced don't show. Also when using the test i just get:
Your test phrase 'test needs to be replaced' did not match any filtersWhen unchecking the standalone for the word 'test' i do get the restult
Comment #6
Michsk commentedThis is the setup i'm trieing to use. Basically it's word changed to a link, checking the upper and lowercase. Demo:
And it returnes.
Comment #7
stevetweeddale commentedI had the same issue, got an error of 'empty regular expression' when using the above patch. After some poking around I've got it working locally for the first and last words in a field, so thought I'd post my version of the patch.
Comment #8
q0rban commentedThe attached patch fixed it for me.
Comment #9
q0rban commentedComment #10
q0rban commentedGrr. ;)
Comment #11
capellicThe patch in #8 is a good start, but it over-corrects and only gets words at the beginning and at the end, not ones truly surrounded by white space. I'm not a regular expression guy as I'm sure it could have been dealt with one one patter, but here's what I ended up with:
Comment #12
q0rban commentedHmm, I'm not sure I understand. I'm using #8 with success. Can you provide some example strings that would not be a match using that method?
Comment #13
capellicq0rban: It wasn't working with the following string (including the period) where "hello" was the word to be converted.
Hello hello hello.
Comment #14
q0rban commentedAh, yeah, so if you write the same word over and over, it only finds every other word. I bet if you put 'Hello hi hello hi hello.' it would match them all. Will work on this a bit more.
Comment #15
q0rban commentedYou know what, though, now that I think about it, that's a bug with the current regex as well. I'm going to create a separate issue for that in hopes that this will get in ASAP.
Comment #16
q0rban commentedHere it is: #1176872: Standalone doesn't account for word repetition
Comment #17
q0rban commentedOk, let's try this on for size. Should resolve both issues.
Comment #18
dunx commentedSame with 6-1.1. Should I raise a new issue?
Comment #19
Michsk commentedNo you don't have to create a new issue.
Comment #20
yngens commentedsame issue here with 6.x-1.x-dev. subscribe.
Comment #21
q0rban commentedI'm closing #1176872: Standalone doesn't account for word repetition and retitling this issue. The patch in #17 resolves both issues.
Comment #22
Michsk commentedSo this has been committed?
Comment #23
csavio commentedYou shouldn't need to back-reference the word-boundary (\b). It is not a character. I think you missed changing the replacements as well as there is nothing to back-reference due to \b being a word boundary appending the variables $1 and $2 in the preg_replace makes no sense.
Comment #24
csavio commentedPatch should be done against the development version(s) and updated to remove the now unnecessary back-references.
Comment #25
q0rban commentedCsavio, thanks for the review. Can you please explain this a bit more? I'm feeling a bit dense. :)
Also, the patch was done against the development version. Are you meaning to say it needs to be re-rolled?
Comment #26
csavio commentedYeah, you'll just want to re-roll your patch with the additional changes if it was against the development version. Sorry, that was a misunderstanding on my part.
The metacharacter \b is an anchor like the caret and the dollar sign. It matches at a position that is called a "word boundary". This match is zero-length. (Reference: http://www.regular-expressions.info/wordboundaries.html)
So, since \b is not a character it is the boundary of the word the parenthesis around the regular expression character (\b) make a reference to nothing then concatenate that nothing needlessly later.
Previous replacements:
Previously the pattern was matching (\W). \W means anything that is not white space, so it was concatenating those characters back on to the replacement ("\${1}". $replacement ."\${2}"), which is probably why it was broken every other match.
What we should be doing after your update:
Your change functionally works perfectly, it would just be confusing from a maintainability standpoint and a bit of extra process that doesn't need to happen.
Comment #27
q0rban commentedAh, got it! Thanks so much for the clarification, it's nice to have someone looking at this that actually understands these things. When it comes to regex, I just keep trying things until it works. ;)
Comment #28
csavio commentedNo problem. Thanks for taking the time to make the patch. I'd just happened to be bug fixing the repetitive word issue and found your other thread.
Comment #29
mxh commented