I use German as forum language (I did a translation for the locale files which I will provide shortly).

I have just realized that special characters like ä, ö, ü, etc. are converted to their respective html entities before being stored in the codo_post table, e.g.

ä ö ü

While that is fine for display, it apparently breaks the search when you are searching for a word containing any of those letters.

The same is probably true for all special characters.

These days with utf-8 encoding the conversion into html entities probably isn't necessary.

But if you do it you need to convert the search term as well or you break the search.

I am doing a lot of monkey patching to get this software to work the way I want it to and I have the distinct feeling that all my patches will be overwritten once the next update comes around...

Update: I provided the German translation at https://github.com/evnix/codoforum-translations and issued a pull request. I noticed there is a Spanish translation waiting for its merge since January 15th.

Hi,

We will fix this search bug.

As for your patches, can you tell us what you have done ?
May be we can incorporate them or provide a solution that does not need over writing,

As for your patches, can you tell us what you have done ?
May be we can incorporate them or provide a solution that does not need over writing,

Ok, here are most of them:

1. Redirect after login: The current behavior is to redirect to the user's profile page. I changed that in codoforum/sites/default/themes/default/templates/user/login.tpl to redirect to the forum's start page. Ideally, that would be a user preference where the default can be set by an admin.

2. In my use case the forum requires a login before displaying anything other than a static startpage. That startpage I incorporated using Dashboard > UI Elements > Blocks > block_body_start (these hooks are a very nice feature, btw!). Using Role permissions I could make sure that non-authenticated users don't actually see any content, but they are still presented with the HTML provided by {body block}. So I edited codoforum/sites/default/themes/default/templates/forum/topics.tpl to incorporate a clause {if $I->loggedIn()} to get rid of that. Again it would be nice if this could be configured rather than programmed via a setting, like e.g. "non public forum".

3. Since my forum instance is configured to use https, it is not a great idea to embed styles, iframes, scripts etc. from external sources, since that then mixes secure and insecure connections and thus defeats the whole point. So I got rid of those (most of them located in codoforum/sites/default/themes/default/templates/layout.tpl) and replaced them with local copies.

4. The bug in line 109 of codoforum/sys/Controller/Ajax/user/login.phppreventing valid XHR-responses (undefined $time→ time()) I mentioned already in another topic.

5. The Time and Date format is hardcoded in codoforum/sys/CODOF/Time.php. Changing this ideally could be done via configuration (again with a default set by an admin).

6. I noticed that not all mail templates can be edited via Dashboard > Mail Settings > Templates. Specifically the fields topic_notify_messageand topic_notify_subject in the table codo_config have no representation in the dashboard.

7. At least one locale string didn't make it into the lang.php, namely 'You need to login to view the forum'.

8. And then, most importantly for me, there is still the issue with sending mails using SSL. Haven't figured that one out yet.

Hope this helps, and thanks for a potentially great forum software!

Hi,

We have bookmarked your post.

Thanks for providing your suggestions.

I recently tried an update to the current version of codoforum, and this didn't go too well:

• Admin interface broken due to undefined constant ADMIN
• Smileys for existing posts broken
• Time format still hard coded and back to default value
• Many language strings not present in the language resource files - why not use gettext with automatic pot-file creation?

So either I stay with the old version or do the monkey patching all over again.

It seems to me that quality assurance of this software could be improved.

Little surprise, do read it
https://codoforum.com/blog/Valentines-Day-Surprise

So I guess I will wait for that and hope for a smoother upgrade experience.

We will also include your points in that