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.

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.
edited Jul 28 '15 at 11:03 am
 
0
reply

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,

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,
 
0
reply

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 $timetime()) 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!

>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. 1. 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". 1. 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. 1. The bug in line 109 of `codoforum/sys/Controller/Ajax/user/login.php`preventing valid XHR-responses (undefined `$time`→ `time()`) I mentioned already in another topic. 1. 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). 1. I noticed that not all mail templates can be edited via `Dashboard > Mail Settings > Templates`. Specifically the fields `topic_notify_message`and `topic_notify_subject` in the table `codo_config` have no representation in the dashboard. 1. At least one locale string didn't make it into the `lang.php`, namely `'You need to login to view the forum'`. 1. 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!
edited Jul 28 '15 at 4:36 pm
 
0
reply

Hi,

We have bookmarked your post.

Thanks for providing your suggestions.

Hi, We have bookmarked your post. Thanks for providing your suggestions.
 
0
reply

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.

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.
edited Feb 17 at 12:54 pm
 
0
reply
123
views
6
replies
3
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft