So just to rewrite the code to make it "<br>" instead of "<br />" would be a total waste of developer's time. Just to state the obvious, I guess you all meant similarly. If it's just that, then yes. What I meant is that when we switch to HTML5 we should also sooner or later aban...

Seems I kicked something off here.

Yeah, doing that in our local config file would be a workaround though an option for that in the settings would be better. For the comments thing: I think that could indeed be a starting point, but just for developing this feature. Approving comments by email verification is not very comfortable for...

Okay. The problem remaining is how we can maintain two parallel versions.
Having all the plugins inside the Git repository would be handy. But as you mentioned, Garvin might take care of this.

this is a long term goal, since breaking compatibility is not a very own speciallity of Serendipity Yep, that's both a blessing and curse. :-) Why not? Garvin said he will think about migrating additional plugins to github too, if people wish him to do. Maybe we could use this switch to have smarty...

I'm talking about templates in general and plugins in particular. ;-) I'd like to remove all inline HTML out of any plugins or s9y core functions so that there's no hardcoded HTML anywhere. Additionally I'd like to improve the flexibility of the templates by using Smarty blocks which are available i...

Well, HTML5 is backwards compatible even with XHTML syntax, but it is not forward compatible. That is, we can't satisfy all people. Once the switch to HTML5 is done, we will break some compatibility. Old plugins with XHTML 1.0 output will still be compatible (though ugly), but people with XHTML temp...

There are many plugins. One example would be the twitter plugin which throws some links and one-pixel graphics into the code. I often have to make changes to the plugin because it's output is not really compatible with my template. Of course, those changes are all gone after the next update. Very an...

Is there any chance to make Smarty3 block syntax a code design guideline? Currently all the plugins drop in some hardcoded XHTML stuff, which often is garbage and interferes with the overall HTML of the template, especially when you're not using XHTML syntax or need some more serious customization o...

[OT] When you make the change, will you also get rid of this useless and bloated XHTML syntax? I know, many plugins (unfortunately) output some hardcoded XHTML, but I think the general blog should use normal HTML syntax. That makes things much easier and cleans up the code. XHTML syntax isn't of any...

Hi there, not sure were to post feature requests. If you like it better in the bugs forum, please move this thread. There should be an option to anonymize IP adresses for comments as well as for any logs (such as the spam log). This option should let you choose a) to save the full IP without any ano...

I'd suggest Aloha Editor as a new default WYSIWYG editor http://aloha-editor.org/
It's an HTML5 based WYSIWYG editor which solves many common problems other editors have such as copy and paste, proper frontend editing etc.

Well, here's the s9y patch: --- serendipity/include/tpl/config_local.inc.php 2009-10-27 10:08:48.000000000 +0100 +++ serendipity/include/tpl/config_local.inc.php.new 2011-09-27 23:26:43.000000000 +0200 @@ -110,7 +110,7 @@ 'permission' => 'siteConfiguration', 'default' => 'uploads/'), - array('var' =...

Provide those config options: "Autodetect Host", "Default Host" Change baseURL to no longer be a user-specified option, but set it to "Default Host" when autodetection is off, and to current host, when autodetection is on. No. Not that way. $serendipityBaseURL stays al...

For plugins which use the new variable it wouldn't be more than $baseUrl = isset($serendipityBaseURL) ? $serendipityBaseURL : $serendipityDefaultBaseURL; and for all the other plugins everything would remain the same. Alternatively an API function getBaseUrl($defaultUrl = false) or similar could be ...