Serendipity Forums

garvinhicking wrote:That sounds good! Indeed returning the ID inside the functionw ould be helpful, so I've patched that as well for the next version.

Would you maybe be able to adapt the importer in a way, that the user could specify through a boolean option whether to use default XML output or the jbackup one? Then we could have it all inside a single importer module...

• an HTML Purifier markup plugin, so that I can allow safe HTML in comments rather than requiring some other markup language like BBcode or what-have-you.
• related to that, I've noticed that a lot of markup functionality is repeated across all the markup plugins ($this->markup_elements, the extended properties' disabling of individual markup plugins per post, that kind of thing), I'm thinking about writing a serendipity_event_markup_plugin class from which markup plugins can inherit.
• I've also noticed that there are still places where pretty URLs aren't used, and I'm trying to weed them out. Some of this involves the URLs generated by my theme (bulletproof), most of it relates to comments (show threaded/show linear links, the URL to which comments are posted, etc.)... this is the area where I know the least, I'm just trying to make changes and then test them with/without mod_rewrite enabled.

[*] an HTML Purifier markup plugin, so that I can allow safe HTML in comments rather than requiring some other markup language like BBcode or what-have-you.

[*] related to that, I've noticed that a lot of markup functionality is repeated across all the markup plugins ($this->markup_elements, the extended properties' disabling of individual markup plugins per post, that kind of thing), I'm thinking about writing a serendipity_event_markup_plugin class from which markup plugins can inherit.

[*] I've also noticed that there are still places where pretty URLs aren't used, and I'm trying to weed them out. Some of this involves the URLs generated by my theme (bulletproof), most of it relates to comments (show threaded/show linear links, the URL to which comments are posted, etc.)... this is the area where I know the least, I'm just trying to make changes and then test them with/without mod_rewrite enabled.[/list]

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.

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.

        $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);

                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] &&

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.

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.

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.