Well, after opening plugin_calendar.tpl and saving it (without changing a single byte), everything went back to normal.

A server-side caching problem maybe? I'm not sure. I don't even know why it stopped working in the first place. But fortunately, the calendar is now working as expected :) (tested ...

After performing an upgrade to s9y 1.4.1, the calendar in Bulletproof broke again :?

After the upgrade I applied the workaround that I mentioned before, but this time it isn't working (the calendar is showing "S?" where it should display "Sá").

I can tell for sure that this isn't a problem with ...

If I change the truncate call in plugin_calendar.tpl so that it keeps 3 characters instead of 2, then Wednesday is shown as "Mi?" (it's spelled "Miércoles" in spanish).

But knowing where the problem is, I looked for issues related to Smarty, truncate and UTF-8 strings, and found a workaround here ...

Hi Garvin,

I've checked the hosting account and it does provide the UTF-8 spanish locale.

If I publish a post on a Saturday, the date on the post shows OK as "Sábado". Even on the calendar, the tooltip for "S?" displays "Sábado".

I made a very simple php file in order to test this:

setlocale ...

I'm setting up a new blog using s9y 1.3.1 with the Bulletproof style. The site is in spanish, and every special character is being displayed as it should, with just one small but annoying exception: the calendar plugin.

At the top of the calendar, you can see the names of the days shortened to two ...

Hi Garvin! I was wondering if there were any news about this issue.

Do you know if it's fixed in the latest s9y release? I'd gladly perform an upgrade if this problem got solved (I'm still running version 1.3.1).

Thanks,
Alex

Thanks a lot, Garvin!

Maybe if Tobias Schlitt or the current package maintainer can be reached for comments, this bug can get fixed in an upcoming release.


--
Alex

Garvin, I think that you've made a very interesting point in your last post, for which I thank you. I hadn't thought about the fact that a shared PEAR setup could be somehow interfering with the Wiki plugin behaviour.

Until now, all of my tests were performed on a shared hosting environment ...

Well, I think I should share a small workaround that I've just found. Maybe others find it useful for their own blogs.

If you wish to use the Wiki plugin and still be able to put some HTML tags in your posts, here's what you can do:

Just enclose the HTML tags between `` and ``. For example:

This ...

Garvin, thank you once again for your reply.

Since I'd really like to help to debug and solve this issue, I took the time to make a fresh install of Serendipity to see what happenned.

I choosed the Simple setup, and these were the plugins installed by default:

- Serendipity
- Emoticate
- NL2BR ...

Today I tried setting HTML to on and Entities to off , but still the same problem. I've also noticed that even single paragraphs with no markup at all get enclosed between <p> and </p> tags that show up in the blog.

After that, I tried disabling every markup plugin except for Wiki_text. Still the ...

I'm working on a new blog, and I've installed the Karma plugin in order to track the views per post and show the total number of views below each article. I'm not interested in Karma as a voting plugin, and in fact I've disabled most of its features.

Yesterday I decided to post my first article ...

Hi Garvin! Thanks for your quick reply.

So far, the problem seems to happen not only with images inserted through the media library, but also with URLs that I've enclosed between <a href ... > and </a> tags (is this the right way to do it?), and even with Textile markup, which I guess is ...

I'm trying to set up a new Serendipity-based blog, and so far everything is working smoothly, except for one thing.

The problem is that if I install the Wiki markup plugin, then all entries start showing HTML code instead of the corresponding rendered result. (All of the entries have been typed in ...

Thank you very much for the tip! That did the trick