To Do List

Because plugins are not provided by the core b2evolution package, they cannot make real use of the T_() function for translations.

Therefor I'd like to add a T_() method to the Plugin class. This could for now just use the global T_() function, but later we can provide i18n support for plugins, by allowing them to have a "locales" subfolder themself, which contains the translated messages.

It's a common behaviour, that user's think about file permission (chmod) issues, when they get a "Permission denied" message!

E.g.

"Permission denied! (blog_genstatic:any:1)"

It should be a bit more verbose, e.g.

"Group/user permission denied by ".$app_name."! (blog_genstatic:any:1)"

fp: OK

Currently a Plugin can have "$help_url", which points to the homepage of the plugin and a README.html file for local help.

For the README.html there can be special html IDs be used to (automagically let) link to a specific paragraph/chapter.

The README.html handling is implemented through helper function in the Plugin class (get_help_link()/get_help_file()) and should move IMHO out of there. To _plugin.funcs.php?

Also, I want to allow easy linking to the manual.b2evolution.net wiki, because I think that the documentation should rather get moved there and the advantages of a local REAME.html (bundled with the plugin and browseable when offline) file are small compared to the advantages of using the Wiki (collaboration, up-to-date).

IMHO, the auto-linking to specific IDs in README.html and the ability to link a setting manually to some help entry in the "internal help", should get removed completely. It's a nice feature, but adds complexity. Instead, a param should get used, that either links to an anchor on the manual page (http://manual.b2evolution.net/Plugins/[plug_classname]#PARAM), another wiki page or to some absolute URL.

(Because then there's no auto-detection if we can provide a help icon with a plugin setting, a property like "help_link_all_settings_to_manual" (default false) could be useful later)

Update:
Current (local) state: a plugin can set the 'help' key for a setting: "#anchor" or empty means: $help_url (with anchor of course in the first case), absolute URL or true, which gets dynamically expanded to $help_url.'#'.$set_name.
$help_url defaults to 'http://manual.b2evolution.net/Plugins/'.$Plugin->classname.
If a README file is present, it just gets linked as an icon in the "Plugin info" fieldset.

Committed:
- README.html now only get linked to as a JS-popup (if there are options/view perms, because I did not want to catch the "disp_help" and "disp_help_plain" actions in plugins.php before the general perm check)
- By default, the HP of a plugin is at manual.b2evolution.net and Plugin (user)settings can be easily linked to some specific section therein or a absolute URL

Unicode/UTF8 support is not very mature in b2evolution yet, but essential for languages that use non-latin charsets.

The solution seems simple: use UTF8 throughout the application!

UTF8 as default

UTF8 should be the default in the whole application. Luckily moving from iso-8859-1/latin1 to utf-8 is quite easy, because latin1 encoding is included in utf8 - so reading a latin1 encoded file is the same as reading it as if it were utf8 encoded (AFAIK).
fp: WRONG! That's only true for 7 bit ASCII. é (a common Latin1 character I use daily) is encoded differently in latin1 and utf8.

What needs to be done?

* Send "Content-Type: text/html; charset=utf-8" header with every page we generate
** Backoffice: /blogs/inc/VIEW/_menutop.php
** Frontoffice: just before we display the skin.
** Skins/general: The [meta http-equiv="Content-Type" ...] lines should be changed to "charset=utf-8" also
fp: BAD IDEA: on some shared hosts you cannot override the charset which is forced by an HTTP header directly by Apache. Sometimes though that forcing *is* UTF-8 !!

** Abandon use of $locales[xx-XX]['charset'] / locale_charset(): it should only be used to define the character encoding of the messages file, but better to just expect utf8 there
fp: NOWAY: using a single byte charset can dramatically decrease the size of the pages in some languages.

* $EvoConfig->DB['connection_charset'] should default to "utf8", because this executes "SET NAMES utf8;" and defines the encoding of the data we get from DB. (Note: "Setting character_set_connection to x [what SET NAMES does] also sets collation_connection to the default collation for x." [http://dev.mysql.com/doc/refman/4.1/en/charset-connection.html]; this is equivalent to having "default-character-set=utf8" in the "[mysql]" section in the MySQL option file)

I've tested this locally and it seems to work very well, at least with the Arabic snippet I've taken from the forums..

Problems with MySQL

* "utf8" is supported in MySQL since 4.1 [http://dev.mysql.com/doc/refman/4.1/en/charset-unicode.html]

We might also want to make sure, that utf8 is supported, by querying MySQL like so:
SHOW VARIABLES LIKE 'character_set%';

(check smilies too)

Also, we loose the img command when entering a subdirectory.

When you try to select a destination dir you get a

Fatal error: Call to a member function on a non-object in d:\www\b2evo\blogs\admin\files.php on line 912

The smiley renderer plugin replaces ";)" in

alt="some text ("24")"
(when not in a CODE block).

I have already a callback_on_non_matching_blocks() function locally for make_clickable() to not make things clickable in Anchor tags.

This could also be used for the smileys plugin:

callback_on_non_matching_blocks( $text, '~<[^>]*>~', 'replace_smileys_callback' );


This would call the callback on the blocks that are not HTML tags.

The wording in the user interface should be consistent.

François, you've started using "Plug-in", which I also like, but it's quite uncommon this way.

fp>> let's go for plugin

The permission to allow an user to generate static pages was always denied, when there were no other user specific permissions.

The method to check this (User::check_perm_blogusers()) returned false, if there were no user perms in evodev_blogusers, but the blog_genstatic perm is based on user level (> 1).