garvinhicking wrote:Maybe you'd like to integrate this into the serendipity_event_unstrip_tags event plugin; this already works on at least showing escaped HTML in the comment, so you might be able to use that as a base to offer people restrictive HTML parsing.
Well, I based it on unstrip_tags, that's how I figured out how to get at the original text of the submitted comment. For now I'm just testing it, when I'm happy I'll see whether it would make sense to put it in serendipity_event_unstrip_tags as a different kind of "unstrip" functionality.
The basic problem of this is that it's kind of an API change, and instead people being able to install a single plugin and letting it work on that, is that you'd create another dependency. I agree that the code is a bit redundant, but on the other hand it's onle small 4-5 lines of this foreach/if routine.
That's true, it would be an API change that either adds a dependency or breaks backward compatibility of existing plugins. On the other hand, I think it's a bit more than 4-5 lines:
Code: Select all
$this->markup_elements = array(
array(
'name' => 'ENTRY_BODY',
'element' => 'body',
),
array(
'name' => 'EXTENDED_BODY',
'element' => 'extended',
),
array(
'name' => 'COMMENT',
'element' => 'comment',
),
array(
'name' => 'HTML_NUGGET',
'element' => 'html_nugget',
)
);
$conf_array = array();
// Add markup elements config
foreach($this->markup_elements as $element) {
$conf_array[] = $element['name'];
}
$propbag->add('configuration', $conf_array);
...which is required for serendipity_event_entryproperties to know a particular plugin is a markup plugin that can be disabled on a per-post basis (as well as to provide the standard "where to apply this markup" configuration options), plus the following
Code: Select all
case 'frontend_display':
foreach ($this->markup_elements as $temp) {
if (serendipity_db_bool($this->get_config($temp['name'], true)) && isset($eventData[$temp['element']]) &&
!$eventData['properties']['ep_disable_markup_' . $this->instance] &&
...to actually implement it.
It might also create trouble for people that already use one plugin, and I'm not sure if the s9y core already supports installing dependencies, when the dependency did not initially exist in the installation phase of the plugin.
Well that part could be handled by upping the required version of s9y, and making it part of the API instead of another plugin... but I had not considered API stability, and I can see how that's kind of an issue. Maybe I'll bring it up again if you start thinking about a flag day (like s9y 2.0).
Yeah, most of these links are used due to url rewriting, and that for Apache using the ErrorDocument rewriting method, you cannot pass GET/POST parameters to a rewritten URL, so the pages would not see the parameter. So it does not only depend whether you use url rewriting or not, but also if you use ErrorDocument or mod_rewrite.
Ah, okay. I had not particularly investigated the ErrorDocument form of rewriting.
For the sake of not forking the code and making it work in all three cases, on situations where variable appending is required, s9y always uses the non-rewrite URL.
Hmmmm. I'm going to keep looking at it, I really want clean URLs throughout.
