The Future of Serendipity

[garvinhicking]

Hi!

@mekk: Version control is a good goal, even though I personally do not have the need for that. I simply created the "proof of concept" plugin, and I'd be happy if other developers can flesh it out with adding notes, support for staticpages and version comparison.

I like your second idea, but I'm afraid it is an awful lot of core code with very little reward for the end user, because usually people simply tune their layout incrementally until the find their best variant. I have rarely had the request for people that often want to switch into different "presets" of their former layouts. I do think this would be a nice feature, but the general use of it might be very, very little. Your third idea about config staging would go hand in hand with it, and this I see more use to people because their testing would not affect the 'live' blog.

- let me "activate plugin only for category X" (plugin is active when I view article belonging to given category, or index of this category, otherwise it is not run)

The "sidebarhider" plugin allows you to hide specific sidebar plugins based on author login or category mode...

About your idea #5, I've already stated my personal thought on this, that I do not want to mess with the "credibility" of trackbacks by allowing seperate text to it.

Thanks for your input, much appreciated!

@abdussamad: The comptetition for the last time was VERY little rewarding. The layouts we got were nearly only from core members. I do not think the bar of contributing users to serendipity is high enough that a new contest would proove effective. Instead, maybe asking those "usual suspects" like Dan, you or others should proove much more rewarding.

About the FF issue, I'm a bit stumped. Did you try with FF2, just to see if it works there? I find that FF3 has changed in many respects that break compatibility...

Regards,
Garvin

[Mekk]

The "sidebarhider" plugin allows you to hide specific sidebar plugins based on author login or category mode...

Thanks for the pointer, I did not know about it. I will take a look. Nevertheless...

a) It would be really nice if one could see the plugin activation/deactivation/hiding rules on the plugin management screen. So I could take a look there, and see what is available when.
This is important part of the suggestion 4)

b) Doesn't there exist difference between hiding and not running?

About your idea #5, I've already stated my personal thought on this, that I do not want to mess with the "credibility" of trackbacks by allowing seperate text to it.

I feel I could be unclear. I do not want a separate text, I want to fine-tune which part of the existing text is to be used. Technically: let me specify index of the first letter and the length (and even check url presence inside). Visually: maybe let me mark this on the preview, or sth like that

[d_cee]

Hi

from reading this thread through, "I did not know about it" in respect of plug-in functionality seems unfortunately common, an improvement in plug-in descriptions would therefore probably be really useful - as would an improved user interface in the admin section. If plug-ins could be subdivided in a way that makes them easier to find/use instead of the ever lengthening scrolling list.

The same goes for themes/templates. The list is getting very long and would IMHO benefit from subdividing. The distro templates could also be updated.

I, like Carl, mostly use Serendipity as a CMS. As a framework for client websites it's unbeatable in my opinion. However, as Abdussamad mentioned previously, the WYSIWYG editor is problematic and needs replacing. The BSD license should not be a problem as the Yahoo Rich text editor is BSD licensed and even supports Safari which others don't so this should be worth consideration for the next upgrade.

HTH
Dave

[carl_galloway]

It's a shame static pages can't be integrated into the core, that is one of the strengths of WP in my opinion, and one of the weaknesses of s9y since the static pages plugin is overly complex and being a plugin doesn't play as nicely as posts do with certain plugins such as the metadesc plugin, and the lack of comments on static pages has been an issue for me in the past which forced me to look at other CMS alternatives. I personally believe a switch (drop down option) in the post editor that converts a regular post into a static page, would be a much more elegant solution for s9y than a separate plugin, and then the post ID could simply be omitted from the blog archive pages. The static pages sidebar plugin could then look for posts with that switch instead of looking in a separate table for the static pages. This would mean an immediate end to compatibility problems with static pages.

I've had a look at the Yahoo wysiwyg editor that Dave recommends and it definitely looks nice, and seems to have most of the functions that users would require.

[garvinhicking]

Hi Carl!

If you see static pages just like blog entries, why not use them as such? With the custom permalink plugin you can give such entries custom URLs, and with the entryproperties plugin you can withdraw such entries from the usual blog entry flow?

I really see a clear distinction between static pages and blog entries. If you want to comment on static pages, it's imho a blog entry and not a staticpage. Static pages are really layoutwise distinct pages and I really see the need to distinct this. Having the functionality for it as a plugin also allows more flexibility and a smaller core code footprint for people that do not want this. My blog for example lives completely without staticpages, and I wouldn't want this functionality.

As a developer, I really want to keep the plugin concept, it allows for so much more flexibility, which has been the strength of serendipity since day one. By putting it into the core, it gets more static, less easy to replace or adapt, and has a much longer release cycle, and people can harder contribute to its code.

I think the staticpages can be much improved by developers, even as a plugin.

I've had a look at the Yahoo wysiwyg editor that Dave recommends and it definitely looks nice, and seems to have most of the functions that users would require.

I agree, I haven'T seen that until know. I'll need to check how stable and flexible it is, and if we can include the s9y specific things like media insertion.

Regards,
Garvin

[Tscherno]

First of all: Thank you Garvin for the great piece of software. It is fitting my needs perfect. If i think about missing features the only one i could think of is an online update system. I know that this could be a security problem. What do you think?

[judebert]

The other difference between a static page and a blog entry, I think, is order. You can get the "next" and "prev" link for static pages, but for blog entries it's much harder, especially if the entry is part of multiple categories or has multiple tags.

I've encountered this with my EV pages. Sometimes I think they'd be better as static pages, just for the next/prev links. I've actually considered a plugin that would add links for each category and tag on a blog entry, but I've never gotten around to it.

[abdussamad]

About the FF issue, I'm a bit stumped. Did you try with FF2, just to see if it works there? I find that FF3 has changed in many respects that break compatibility...

Yes I have tried ff2 and the problem is the same with it. The author of the bug report thread I linked too (here it is again) also says he was using FF2.

Frankly I don't think that the problem is related to session restore.

[gimmel]

Serendipity is by far the best weblog software I know. And I tried a lot of them. Thanks for development, perfect support and just being a nice guy, Garvin.
I have some points that would make Serendipity a little bit more perfect.

• Better XHTML and better semantic programming.
  • The default template still contains tables for design purposes. That should be changed to tableless design.
  • Sidebar plugins should not use headlines(h3) but definition lists (dl). Take a look. Plugins are not that important to be seen as headlines for search machines and screen readers.
  • Images with nested div as a container for comments often make problems. You should use definition lists for that, too. Here and here.
  • Too many <br />: There is no reason to generate space with <br />. You can do it much better with block elements and margins. The comments plugin has three empty lines (<br /><br /><br />) to seperate entries. It's hard work to clean this mess up just with css.
    If the plugin would generate a list (how it should be), you simply could set the distance with the margin-bottom of the list elements. <br /> is only for entry text, not for designing the site.
  • There should be a plugin programmers guideline to assure semantic standards for those things.
• Better multilanguage support
  • It would be much easier to generate multi language entries, if all used languages would be visible in columns side by side.
  • Handling of multi language static pages and blog entries is totally different. That should be adjusted. Generating 40 entries in 4 languages is easy, but try 40 static pages in 4 languages: You have to generate 160 static pages and make every setting for all of them. I want to edit just one static page for all languages. URL could be automated (de/pages/xxx.html for german and en/pages/xxx.html for english and so on.)
• Backend
  • Moving and deleting plugins is often a game of changing, saving, changing, saving. An Ajax-like programming would be a great way to make this easier and would set Serendipity to a complete new level for a blog software. What about SproutCore?
• Database
  • While programming templates, I have a Serendipity installation locally on my MAMP and the „real“ one on my web server. To have the same content on my programming environment, I tried to use the web servers MySQL database instead of the one in MAMP. The problem is: the internal paths are saved in the database, too. So I can use the database only from one serendipity installation. Wouldn't it be better to save those server dependent data like absolute path in serendipity_config_local.inc.php? So the database would only keep the blog content, not the server settings. Development would be much easier.
• Email subscriptions
  • Subscription emails should be template based. Those standard mails are a bit ugly. Very important: the mails have to contain the comment text! It's not very handy to have to click and open the web browser for every short comment to read.
• Plugins
  • Every plugin should have a modifiable template. That's another thing for the plugin programmers guideline.

[yellowled]

[*]The default template still contains tables for design purposes. That should be changed to tableless design.

It will be once s9y 1.4 comes out using Bulletproof as the default template.

[*]Sidebar plugins should not use headlines(h3) but definition lists (dl).

You're right about not using headlines, but I'm not sure dls are the way to go. uls would be an alternative.

[*]Images with nested div as a container for comments often make problems. You should use definition lists for that, too.

I agree that images need work. We especially need to find an easy way to clear floated images. Not sure whether dls are right for this, though. Don't get me wrong, I *love* dls, but it's debatable whether a list with one item is still a list

[*]Too many <br />: There is no reason to generate space with <br />. You can do it much better with block elements and margins.

Correct. This has been addressed for the core plugins already, but we just need more time (and possibly manpower) to work on the additonal plugins available over spartacus. Help is always appreciated for this

[*]Every plugin should have a modifiable template.

They should at least have the option to use a smarty template - smatifying every single plugin might create performance issues. Again, this is a matter of time and manpower.

YL

[gimmel]

Help is always appreciated for this

I am here! I never used SVN and don't know how to join the club. I have some plugins to publish, too.

[yellowled]

Help is always appreciated for this

I am here! I never used SVN and don't know how to join the club. I have some plugins to publish, too.

Subscribe to the developer mailing list, register at berlios and sourceforge, lay down and wait.

Garvin, I got one!

Someone give this young man SVN access already. It's not like we could have too many developers.

YL

[gimmel]

Registered at BerliOS: done…
Registered at Sourceforge: done…
Registered Name: Michael Kaiser…
Developer Mailing List: not found…
Layed down: done…

[tpost]

"I did not know about it" in respect of plug-in functionality seems unfortunately common, an improvement in plug-in descriptions would therefore probably be really useful

This is one of my pet peeves with S9Y.

S9Y is already quite powerful, but I never know which plugin is the one I want.

And as abdussamad mentioned -- documentation -- which is another thing that could be polished up.

I almost always end up making a post and bugging Garvin!

-----

Here's my contribution to the thread:

*Internal podcast support (this could be done through a plugin)
Perhaps making a distinction between a post and a podcast entry, so one can add iTunes description and tags. (this is probably hard to implement conceptually)

Or even at the category level - ask if the category is going to be used for podcasts? That way, when creating a new entry in this podcast category, iTunes fields will need to be filled in in addition to the regular description and title. (might be easier)

-----

If I think of anything else, I'll be sure to post it.

[garvinhicking]

Hi gimmel!

Registered Name: Michael Kaiser…

I could not find a user named like this. I believe, nicknames for both SF and Berlios are not allowed to have spaces, which username/nickname did you use?

You might need to get yoursel familliar with SVN and CVS if you want to contribute like this.

The usual way to get joined as a developer is, if people submit patches first. Either in unified diff format, or if you do not know about unified diffs, simply submit the full replacement files and I can check out the differences. You can do that here on the forum (preferrably on a new thread).

@tpost: You're not bugging me, I really enjoy helping here on the forum. But it is MUCH easier to reply to factual questions, than to write up anything to cover POSSIBLE questions. This is much harder for me, especially as a blind developer to whom everything looks simple and easy already.

Regards,
Garvin