Output Filters

[scullion]

Hi there,

Is there any clean way to implement an output filter (or, better, a chain of those) without hacking into the WB core? As an admin module, perhaps?

Possible uses of such a module:
- tag removal/substitution;
- obscene language filtering;
- usage of system/custom constants in plain text blocks;
- etc.

Thanks in advance for any suggestions.

[doc]

Hello,

have a look on the no spam script I posted somewhere in the forum (can also be found from the addons site; unofficial modules). The script searches for mail address links and replace some of it to make it not so easy for spam robots to extract mails (frontend.functions. php).

Christian

[scullion]

Thanks, Christian.

If I see it correctly, your first module (nospam) does not actually process any output, merely offering the mlink() function instead, but the second one (spam_protection) -- that is really close to what I'm looking for! (And I hope I'm not the only one.)

Speaking of which, here is a suggestion: why not make this feature a bit more universal and use it not only for e-mail obfuscation but for virtually any kind of output filtering? One could define regex-powered substitution rules in, say, "Settings" section, which are then parsed by class.frontend or frontend.functions or whatever part of the core responsible for filtering and, finally, applied to the output one by one. (And no system file is touched, not even config.php!)

Of course it should be carefully considered how/whether to enable/disable such filtering on a per-page basis; how to specify/store rules; which rules to include by default etc., but I hope the idea is clear.

I think this is a useful and powerful feature that could become quite an addition to the next releases of WB.

[doc]

Hi,

yes I was talking about the second tool in the thread (spam_protection). Well yes, it is very powerfull, but one needs to use this with care (as can be seen from the discussion). When using regular expression to filter out stuff, one needs a lot of thinking (classes, ids, styles ....).

This features may make up its way into the next WB version, however, I doubt that we will give the user the freedom to define regular expression by its own. Hope you can manage to modify the stuff to your needs.

Regards Christian

[scullion]

Hi Christian,

I'm afraid I don't quite understand what you mean saying that you "doubt that we will give the user the freedom to define regular expression by its own". To me, it sounds like you are going to voluntarily shoulder the load of defining regexps for thousands of users out there -- and then spending your time replying to their feature requests, updating the core and releasing new WB versions? Or, if not, then strictly limiting the possibilities?

Your spam_protection module is really great, but you are implementing a special case of a huge application domain. Of course using full power of this feature will require from admins quite a bit of thinking, but so does module or template development, doesn't it?

No doubt I can manage to make stuff work for me, this way or another, but I'd prefer doing it in a non-destructive way. And if at the same time it contributes to project's development -- even better! 

[doc]

Hello,

well personally I do not like the idea of output filtering at all. I implemented this as a measure against harvasting mail addresses. Think if we implement such a feature to any future WB 2.x version, we will limit the possibilities (only allow to switch on/off, only allow to specify replacements for parts of the mail address).

I think WB is a great CMS due to its simplicity. Adding tons of features to the backend will not help to keep this status. With WB 3.0 in mind, we should avoid putting more and more functions into WB 2.x tree. And the usage of regular expressions will be at least one level too high for most of the WB users. In addition this method does only work for output generated by WYSIWYG pages. Content outputs of modules are managed via the view.php of the individual modules.

Regards Christian

[scullion]

Hi Christian,

Okay, I agree that the core should stay as small and simple as possible, but how about giving more flexibility to module developers, then? For example, what about hooks that could allow modules interact with the core at different stages of page rendering? Of course it's a step away from simplicity, but the line between simplicity and inflexibility is very thin, after all.

[doc]

Hello,

the only change in WB 2.x is to make us of the module type Code Snippets introduced with WB 2.6. They allow to define own functions which can replace the core files. What you are asking for would require to rewrite the entire WB 2.x core - what I believe will not happen.

However, you can express your wish to the board: WB 3.0 wishlist (search for WB 3.0 and Ryan). The work on WB 3.0 is not started yet, so it is still some time to get your ideas in.

Regards Christian

P.S.: Sounds you have some experience with coding. Are you willing to contribute e.g. modules or stuff like that?

[scullion]

Thanks, Christian.

I doubt you'd have to rewrite the entire core to introduce hooks, but you should know better, after all, since you seem to have spent some time in the project. I didn't take time to take a deeper look at the core yet.

On the other hand, I probably should do it. And, well, make the stuff work for me, as you say. To be honest, this scares me a bit: every n-th reply in this forum suggests "go there or there and adjust file abc.php, this should work". Of course it will, but how to apply updates when another WB version arrives? One can't just go messing up with system files!

I was looking for a nice and simple yet flexible CMS, and WB caught my eye. (Hats off to the dev team!) And I believe that with some tweaking and "flexing" it can truly become the one I was looking for. But if it remains at the point of page and user management and does not solve such essential CMS tasks like content reuse, module chaining, output filtering etc. in an elegant way, I'm afraid I'll have to go on with my search.

As for contributing -- yes, I have some coding experience (10+ years of software engineering, in fact), and I'd like to contribute indeed. But I cannot start with modules until I understand what your road map looks like. So I guess I'll just stay in the forum and/or tracker for the time being, putting in my two cents every now and then, and see what happens.

[doc]

Hello scullion,

thanks for your reply.

Well about 90% of the suggestions "go to file xx and change lines YY" come along with a clear statement that you need to keep in mind that every new version of WB will overwrite modifications applied manually. So it is up to the user. WB offers code snippets to put and/or overwrite core functions without touching the core files. Another solution is to write a module which fits this purpose.

However, all those "requests" are very special and not asked very often (as your request for output filtering). It was never my attention to offer a solution for filtering output, my intentions was to provide the functionallity to protect mail addresses with ease. Most likely this option will be integrated into a WB 2.7 release.

As the last X replies are not related to the spam module (which the whole thread is dealing with), I suggest we stop discussion in this thread. As already mentioned, please feel free to put your comments in the WB 3.0 thread started by Ryan. This is the right place to ask for a schedule, offer your help, or to address your feature requests like hooks to WB core functions.

Regards Christian

[scullion]

Thanks, will do that.