Backport of multiple path support

[BrianKoontz]

This is a backport to 1.1.6.6. of the multiple path support made available as part of the extensible architecture for Wikka components initiative.

Related tickets: #446

[BrianKoontz]

(In [1228]) Backport of multiple path support. Refs #805, #446.

[BrianKoontz]

(In [1229]) Incorrect config param for handler_path specified. Refs #805.

[DarTar]

Brian, I tried adding a custom actions/contact.php action in 1.1.6.6 but it doesn't seem to override the default action.

[BrianKoontz]

I just tested this successfully using the following procedure:

• Check out branches/1.1.6.6
• Install using the wizard
• Copy actions/contact.php to plugins/actions/contact.php
• Modify line 12 in contact.php to read $replace = array("[@]", "[.]");
• Place {{contact}} action in SandBox
• Reload page, verify "@" and "." were replaced by "[@]" and "[.]"

Please verify that your wikka.config.php file contains the following:

    'action_path' => 'plugins/actions:actions'
    'handler_path' => 'plugins/handlers:handlers'
    'wikka_formatter_path' => 'plugins/formatters:formatters'
    'wikka_template_path' => 'plugins/templates:templates'

[DarTar]

Brian, I didn't have the alternate paths specified in the config file indeed, it works fine now.

Two questions:

• do we really need to specify the path override in the config file? Why not just have as default behaviour that plugins/actions/myaction.php (if exists) always overrides actions/myaction.php?
• if we do, maybe we should adopt a less linux-ish convention than a colon as a path separator.

[BrianKoontz]

Replying to DarTar:

Two questions: - do we really need to specify the path override in the config file? Why not just have as default behaviour that plugins/actions/myaction.php (if exists) always overrides actions/myaction.php?

I've always detested "hidden defaults." Coming from a Unix background, it's just second-nature for me to permit the greatest degree of customization possible, with a set of default customizations for those who don't have the time/energy/knowledge/care to customize.

- if we do, maybe we should adopt a less linux-ish convention than a colon as a path separator.

Well, see item 1 for an explanation :) I thought about whitespace as a separator, but unfortunately, certain mainstream O/Ses still support whitespace characters in directory names, so we'd have to play games with quotes. How about a compromise: ":" for the Unix folk, ";" for the Windows folks. (Take this in the lighthearted way it's intended: I really don't care either way!)

[DarTar]

OK for an explicit setting in the config file if you find it useful, it doesn't do any harm. As for the separator my concern comes from the fact that in the config file we already allow three different types of separators: commas, new lines, double colons. What if we used commas as a default and allowed colons and semicolons as valid alternatives?

[BrianKoontz]

(In [1269]) Adding comma as a multipath delimiter. Refs #805

[DarTar]

tested an action override (also changing path separator in the config file), works fine for me.