Ticket #446 (new task)

Opened 7 years ago

Last modified 4 years ago

Extensible architecture for Wikka components

Reported by: DarTar Owned by: unassigned
Priority: high Milestone: blue-sky
Component: architecture Version: 1.1.6.2
Severity: normal Keywords: modular plugins addons
Cc:

Description (last modified by DarTar) (diff)

The current architecture allows little flexibility/configurability. After a discussion with JavaWoman on #wikka we decided to implement, as of 1.1.7, some preliminary changes that should allow more flexibility for components such as actions, handlers, formatters and language packages in forthcoming releases. This is a coordination task for the following planned changes:

1. Dedicated folders

Moving each component to its own subfolder provides several advantages, in particular the ability to add further support files (images, libraries, metadata, settings) for each component. So instead of calling an action as actions/calendar.php we will call it as actions/calendar/calendar.php. Component folders are also useful to provide drop-in support for user-contributed plugins that may come as zipped files or tarballs to extract and put in the appropriate directory, e.g.

actions/
.....myaction/
........css/
........img/
........inc/
........js/
........lang/
........myaction.php

As for language packages, this modification will allow to store localized definitions for default pages within specific language folders, e.g.:

lang/
.....en/
........defaults/
........en.inc.php

Subtasks

2. Directives

Currently, information on how to handle content associated with a specific handler is hardcoded in the core. For instance the core engine contains instructions on the different kind of HTTP headers to be sent along with handlers such as /raw, /show, /mindmap.mm etc. Instead of hardcoding these directives, we should put them in an .inc buddy file, coupled with each component. Every time a handler is called, the engine will check in this buddy file what kind of directives need to be followed.

Subtasks

  • Prevent mutiple calls #634

3. Metadata

Buddy files can hold not only procedural directives, but also metadata about a component. For instance, a remote URL to check whether the installed component is up-to-date. Component metadata could then be used by plugin managers to display information about installed actions, handlers and formatters.

These changes can be implemented little by little. Our goal as of 1.1.7 should be to prepare a file structure compatible with this general plan (i.e. at least step 1).

Related tickets

  • #56 Event reaction system
  • #287 Module/Plugin Capability
  • #774 Preprocessing step before formatting to include dynamic content
  • #817 Hooks to preprocess page output

Change History

  Changed 7 years ago by DarTar

  • description modified (diff)

  Changed 7 years ago by DarTar

  • description modified (diff)

adding subtasks

  Changed 7 years ago by DarTar

  • description modified (diff)

  Changed 7 years ago by DarTar

  • description modified (diff)

  Changed 7 years ago by DarTar

  • description modified (diff)

adding subticket for default pages #485 and upgrading example accordingly.

  Changed 7 years ago by DotMG

About the 2nd directive,

In your opinion, where is the best place to include the buddy file?

There are a lot of possible solutions, but we need to choose altogether which one is the best?

1) A single config handlers/content-type.txt, in the syntax of mime-types.txt

2) buddy .inc file in each handler subfolder, ex handlers/grabcode/grabcode.inc

(I dislike the existence of a lot of small files, which anyway consume larger space on hard disk, complex handling, ...)

  Changed 7 years ago by DarTar

I think I prefer option (2) (grabcode.inc.php) because this will allow simple drop-in extension (with extensions downloadable as zipped folders). Others?

Also to keep things simple, we'll have to provide defaults for cases in which the buddy file is absent or invalid.

  Changed 7 years ago by JavaWoman

I prefer buddy files of the 'grabcode.inc.php' naming convention as well - this can be applied for all plugins.

BTW, don't forget that different feed formats need different Content-type - the internal format of the buddy file should support this.

  Changed 7 years ago by DarTar

  • description modified (diff)

adding related ticket

  Changed 6 years ago by DarTar

  • description modified (diff)

follow-up: ↓ 12   Changed 6 years ago by BrianKoontz

(In [1179]) Multiple path support. Refs #446

in reply to: ↑ 11   Changed 6 years ago by BrianKoontz

Replying to BrianKoontz:

(In [1179]) Multiple path support. Refs #446

For the rationale behind this code change, please search the mail archives for the subject "Proposed change for handling external 3rd party actions/handlers".

Basically, the change supports the following plugin architecture:

plugins/                                                                        
....actions/                                                                    
....handlers/                                                                   
....formatters/                                                                 
....templates/   

Anything in these directories will override anything in the install directories. The plugins/ subdirectory should never be modified or deleted by the installer.

  Changed 6 years ago by NilsLindenberg

(In [1198]) refs #446: fixing constant name (reserved by PHP)

  Changed 6 years ago by BrianKoontz

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

  Changed 6 years ago by BrianKoontz

(In [1270]) Added comma to list of mulipath separators. Refs #446

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • description modified (diff)

  Changed 6 years ago by BrianKoontz

  • milestone changed from 2.0 to 1.1.7

  Changed 5 years ago by DarTar

  • milestone changed from 1.2 to 1.3

Retargeting to 1.3. Code for this ticket may have already been committed to trunk, from which 1.3 will be branched. Consider backporting urgent issues to 1.2.X

  Changed 5 years ago by DarTar

  • description modified (diff)

added ref

  Changed 5 years ago by BrianKoontz

(In [1483]) Ported from trunk to 1.2 branch. Refs #446, #447.

  Changed 5 years ago by BrianKoontz

(In [1484]) Port of [406] from trunk to 1.2 branch. Refs #446, #452.

  Changed 5 years ago by BrianKoontz

(In [1485]) Ported [407] from trunk to 1.2 branch. Refs #446, #452.

  Changed 5 years ago by BrianKoontz

(In [1486]) Ported [407] from trunk to 1.2 branch (removed page dir). Refs #446, #452.

  Changed 5 years ago by BrianKoontz

(In [1487]) Port of [408] from trunk to 1.2 branch. Refs #446, #452.

  Changed 5 years ago by BrianKoontz

(In [1488]) Port of [445] from trunk to 1.2 branch. Refs #446, #452.

  Changed 5 years ago by BrianKoontz

(In [1489]) Partial port of [273] from trunk to 1.2 branch (lang files). Refs #485, #446.

  Changed 5 years ago by BrianKoontz

(In [1490]) Ported [273] from trunk to 1.2 branch. Refs #446, #485.

  Changed 5 years ago by BrianKoontz

(In [1491]) Ported [274] from trunk to 1.2 branch. Refs #446, #485.

  Changed 5 years ago by BrianKoontz

(In [1492]) Update default pages in preparation for removal from install script. Refs #446, #485.

  Changed 4 years ago by BrianKoontz

  • milestone changed from 1.3 to blue-sky

  Changed 4 years ago by GeorgePetsagourakis

This proposal needs to be rethought in the light of a better OOP system available in PHP 5.

-note-to-self: Hustle the development to update requirements. note-to-self-.

Note: See TracTickets for help on using tickets.