Add a page to test the filters

Rather than testing the regular expressions, the page should allow to test the custom filters created without to

• Create an input format that uses only the custom filter you want to test.
• Create a new node, just to be able to see the preview of the node content as it would appear.
• See the source of the page, and check if the output of the filter is really the one you were expecting.

Testing a filter should be easier.

This feature has been implemented.
I will add the possibility to use the raw content of a node as test text in the next days.

I guess I forgot to change the status.

Altough it is a good thing to have such a feature I don't like the way you did it :).

To output it in the info bar (#message-status) isn't a good idea. Because on my site for instance this pops up as a little notification. So it's a highly inappropriate place for a whole node preview. Put the preview underneath. (And it isn't processed the right way on my site. I.e. < get's prelaces with <, so the tags are shown instead processed from the browser.)

2nd the input field where you put in the node doens't work for me right. I don't know why but it only accepts nids. And you have to consider path aliases which are set by the path module that look like http://www.mysite.com/about and doesn't have a .*/node/.* in it.

And I would like the possibility to select only one filter rule from a custom filter to test it. It would be also cool just to see what the regex of a rule would select. So give a option to just highlight these matchings without process the code/replacement of the rule.

Or you should integrate this whole functionality into the rules definition page. So you can tune you rule faster. With this setting you have to go the rule settings, modify, save, go to the test page, click preview... and so on. This is a little bit bugging. So really nice would it be to have this feature integrated in the rules settings page and it would be ajaxified that you don't have to reload the whole site every time (and it doesn't kick you out of the rule settings page if you hit save to test if it works)

I hope my critique helps to make it even better :)

Rock on

To output it in the info bar (#message-status) isn't a good idea.

The output method clearly needs to be changed; the code I implemented is simply prototype code that helped me to verify the functionality. Considering that the user can receive a notification for each message shown through drupal_set_message(), it's better to use another method.

And it isn't processed the right way on my site. I.e. < get's prelaces with <, so the tags are shown instead processed from the browser.

The result is passed through check_plain() to make possible to completely see the filter output.
Suppose that the filter wrongly add a '<strong></strong>'; when seeing the test preview, you could not notice the extra tags if not looking at the page source (but then you should ask to the browser to show you the source page, and search the part that interest you through all the HTML tags).
The preview needs to be added, but it must not be the only output you see.

I think that the full test page needs to be rewritten, as there are some problems that need to be resolved.

• The code should not allow to use nodes when their input format includes the PHP filter. It's not possible to create a preview of those nodes without to first render the node content, and then apply the filter to test; this could create unpredictable results, and alter the test result.
• Using a node content to test a filter doesn't allow you to see the node content before applying the filter; this means it's not easy to understand if the filter is working (but then, what would be the purpose of the test page?).
• The output of the filter testing could contain not closed HTML tags, which cause problems to the full page when previewing the test result.
  Before to preview the test result, it must be corrected to close all the tags that have not been closed.

2nd the input field where you put in the node doens't work for me right. I don't know why but it only accepts nids. And you have to consider path aliases which are set by the path module that look like http://www.mysite.com/about and doesn't have a .*/node/.* in it.

In the input field you just need to insert the node ID; this has done because the autocomplete function cannot complete a string like "content/page".
I can remove the autocomplete functionality, and change the code so it can accept any relative URL entered (which would include both the canonical URL "node/<nid>", and a URL alias).

And I would like the possibility to select only one filter rule from a custom filter to test it.

That is already possible; it's enough to disable all the replacement rules you don't need to test, and then you test the filter. As you are testing the filter, I assume you have not selected it in any input format; if then the filter is already used in an input format, then it's more probable you are interested in testing the full filter.

Or you should integrate this whole functionality into the rules definition page.

The test page is only for filters, not for replacement rules. To test only the single replacement rules would not be of any help, as there could be some problems when applying all the replacement rules.

The result is passed through check_plain() to make possible to completely see the filter output.

Okay, makes sense.

The output of the filter testing could contain not closed HTML tags, which cause problems to the full page when previewing the test result.
Before to preview the test result, it must be corrected to close all the tags that have not been closed.

Perhaps such a case could be highlighted in the preview, so you can modify your filter.

In the input field you just need to insert the node ID; this has done because the autocomplete function cannot complete a string like "content/page".

You could replace it with a node title. There is auto-completion support for that and it's much more convinient than the nid (honestly, I don't think you now your nids per heart ;)).

That is already possible; it's enough to disable all the replacement rules you don't need to test, and then you test the filter. As you are testing the filter, I assume you have not selected it in any input format; if then the filter is already used in an input format, then it's more probable you are interested in testing the full filter.

What I meant was in addition to the filter testpage. Just something like http://www.regex-tester.de/regex.html to see how your regex pattern works, what it matches and what this special rule do with the matches.

For a workflow you should avoid reloads wherever as possible. Because drupal isn't that fast in the backend where nothing is cached.

Perhaps such a case could be highlighted in the preview, so you can modify your filter.

The result could have not closed tags because the trial text the user inserted has not closed tags (which means the filter didn't do anything wrong).
I agree that the module should output a message in the case it finds some tags left open; it actually could give a different message basing on where the not closed tags have been found (in the trial text, or in the filter result).

You could replace it with a node title. There is auto-completion support for that.

That it was I have done, at the beginning; there isn't a function that allow to autocomplete a node title, but to create such function is not a problem. I thought that to request the title of the node to use was fine, but then I thought to the nodes with the same title (which are allowed on Drupal, as the nodes are identified by their node ID).
It's true that it's hard a user remembers the node ID (especially when the node has a path alias), and that to give to the module the parameter it requests, one should go to the node page to check the node ID; for that reason, I think I will use again my original code.

What I meant was in addition to the filter testpage. Just something like http://www.regex-tester.de/regex.html to see how your regex pattern works, what it matches and what this special rule do with the matches.

I understand your point; still, I think that it's more important to verify if the filter works as expected.
After I change the code, in the page that lists all the filters there will be a "test" link for each filter, which will allow you to go directly to the test page. You can then create a filter, create the first replacement rule, return to the filters page, click on the "test" link, and verify if the rule you have written works as it should.
There is no need to have a page to test the filter, and one to test the regular expressions you want to use. I understand that it requires a little more steps, but after you became more familiar with the regular expressions, you will nee a page to test the filter more than a page to test the single patterns used.
Bear in mind that each replacement rule can have sub-replacement rules; at that point, to test the regular expression is just the tip of the iceberg.

I thank you for the suggestions, and the feedback you are giving me; I appreciate them, and I am glad somebody is interested in the code I am developing.

I am reopening the report, as the code I added was clearly a prototype; the code needs to be rewritten as per suggestions given here.

I committed the changed to the code. I hope this is much better.

I am setting this report as fixed.

Automatically closed -- issue fixed for 2 weeks with no activity.