[pLog-svn] LifeType2

[Oscar Renalias]

Pre-P.S: I hope you don't mind that I'm replying via plog-svn, I just
thought that this discussion could be useful for everyone...

Hi,

thanks for your feedback, we always appreciate that :-)

> I'm Ahmad Saleh, I work in AL-Bawaba portal, we use LifeType for our
> blogging service.
>
> If you don't mind, I have some suggestions to increase LifeType performance:
>
> 1) Re architecture LifeType plugins:
>     a) The issue here that you load plugins each time the server
> receive request
>         (such as index.php) whatever the page is cached or not.

The problem with this is that some plugins need to perform their
action regardless of whether the page is cached or not. One good
example are the anti-spam plugins, that hook themselves up in the
filtering pipeline. The pipeline always runs, even if the page is
cached, so those plugins should run too.

I agree that for some other plugins it does not make sense to load
them, but it's very difficult to tell at run time whether a plugin
needs to be loaded when the page is cached or not.

>
>     b) LifeType create plugin object for all plugins, a lot of plugins
> don't need that
>         object, some plugins just for adding "Admin Actions", some to check for
>         request, and some for blogs ... .
>
> So I suggest to separate between each process in separated file, some
> thing like this:
>        - plugin_menu.xml: just load it wen you need it.
>        - plugin_adminaction: just load this in lifetype front
> controllers (index.php, admin.php)
>        - plugin_class: to create plugin object if this file exists.
>        - plugin_hooks

I don't think I understand this suggestion, can you elaborate a bit more?

> 2) Very very flexible lifetype:
>     The good thing that lifetype is very flexible web site, however,
> this decrease
>     lifetype performance, so what about decreasing some of this
> flexible to increase
>     lifetype performance (such as removing lifetype configuration from database
>     and keep it in a file)

The Config class is designed so that you can easily change its storage
backend, meaning that you can either use a configuration file or a
database backend (there are no more backends available) I haven't
tested this feature for a long time, and you need to change some code
to use a different backend, but it can potentially work.

On the other hand moving things to a configuration file makes things a
bit less secure, as the config file would need to be world-writable so
that it can be updated via the user interface. Unless of course you
disallow updates via the user interface...

Thanks,

Oscar