Problem/Motivation

It's not always clear what a particular filter was intended to do, especially for more complex filters and those created by other developers. Something as simple as a space at the end of a filter, or replacement, could easily go unnoticed. And for many of us, it doesn't take long to forget exactly why we included a particular filter.

Proposed resolution

Add a text field to each filter for notes, so developers and site builders can optionally document the intent of their filters.

Remaining tasks

  1. Decide on label for new text field (Notes, Description, Intent, ???).
  2. Update module to include new text field.
  3. Add test coverage for new text field.

User interface changes

A third field, labeled "Notes" (or something along those lines), will appear with each filter in the paste filter configuration.

 "Search expression," "Replacement," and "Notes".

API changes

None.

Data model changes

Each filter in the plugin configuration would have an additional 'Notes' field to be stored.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

jstoller created an issue. See original summary.

star-szr’s picture

Thanks for the feature request @jstoller! I like the idea and don’t have any immediate concerns, although it will make the form vertically larger. I’m not sure when I can work on this feature in the near future but I’m happy to review patches/MRs and help it along with reviews and such.

star-szr’s picture

Issue summary: View changes

joel_osc made their first commit to this issue’s fork.

joel_osc’s picture

Status: Active » Needs review

Not sure what is going with the tests, but I have tested the plain diff and it works as long as you drush updb to update sites with any existing filters configured.

star-szr’s picture

Thanks @joel_osc, I will take a look.

star-szr’s picture

Pushed a commit that should resolve the test failures, it was due to the config in the test module not being updated with the new description field.

I think at least one other thing that deserves some thought is the behaviour for deleting rows, should we check that all three text fields are empty? Currently we just check that the search and replace are empty and delete the filter row if they are both empty. I think we should probably include the description field and update the messaging/tests/etc. accordingly, but open to other suggestions and thoughts here.

joel_osc’s picture

Thanks for the fix to the tests!!! I am not sure we need to check if description is empty - I think the main fields are the search and replace. If someone has emptied both of those then I would say that we are sure they want the row gone. Cheers and thank-you!

star-szr’s picture

@joel_osc I am leaning that way as well, thanks for weighing in. Could you please take a look at the phpcs errors in the .install?

star-szr’s picture

Status: Needs review » Needs work
star-szr’s picture

I re-ran the Nightwatch tests (it tends to randomly fail, I am working on replacing it), looks like there is one phpcs error left. Thanks!

star-szr’s picture

Version: 1.0.x-dev » 1.1.x-dev
Issue tags: +Needs tests

I've hit retry three times on the test, but it's still randomly failing. Not your fault @joel_osc, thanks for your work on this! See #3509004: Replace Nightwatch testing with Playwright.

I think this feature also needs additional test coverage to:

  1. Ensure that the Description field saves and displays properly
  2. Explicitly test for the "empty row" behaviour (row should be deleted if Description is non-empty but Search and Replace are empty)

Sadly those tests would need to be ported to Playwright later if we write them in Nightwatch now, but I won't merge this without test coverage. If nobody comes back to this I will add those tests at a later date, but I will be working on #3509004: Replace Nightwatch testing with Playwright first.

joel_osc’s picture

Cool, thanks @star-szr!

liam morland’s picture

Current state of merge request.

jstoller’s picture

While I still think a text field is the right way to do this, in the meantime, if anyone needs a hack while they wait, I've started adding (?:Comment goes here)? to the ends of my search expressions. It's an optional, uncaptured string, which will never actually appear in any of my pasted text, so it has no real impact on the filter but allows me to include some documentation. For instance...

(<[\w]+)(?: [^>]*(?= href))?( href="[^"]*")?(?: [^> ]*)*(>)(?:Remove all element properties, except "href")?
<([\w]+\b)[^>]*>( )*<\/\1>(?:Remove all empty elements)?
star-szr’s picture

Just coming back to this, all tests have been converted from Nightwatch to Playwright so if anyone is feeling like it, please add tests for this and I can re-review. Otherwise I will try to come back to this and add some tests myself. Thanks!

liam morland’s picture

Current state of merge request.

star-szr’s picture

Coming back to this, an improvement in my mind would be to change from an input[type=text] to a short (in height) textarea similar to the search and replace fields, to allow for multi-line entry.

My thinking is to allow something similar to a git commit message format which can have a "subject", then a "body" with more details, URLs, issue numbers, etc. as needed.

I'm planning to make this textfield -> textarea change and add some test coverage, and 🤞 potentially merge this.

star-szr’s picture

Ran out of time for today and also ran into core 11.3+ dropping the body field as a default when creating a new content type, which complicates us wanting to test both D10 and D11.

I pushed a little commit to change textfield to textarea for now.

star-szr’s picture

Created #3575837: Rework tests to not rely on node body field to handle the body field change separately.

liam morland’s picture

I just rebased and tests are back to passing.