[TYPO3-ect] [TYPO3-core] Wishlist from ECT

[Ernesto Baschny [cron IT]]

Elmar Hinz wrote: on 12.02.2007 16:06:

>> - global PEAR installation has nothing to do with TYPO3. The system
>> administrator installs it in /usr/share/php or whatever directory the
>> system default is. This information is given in php.ini and
>> (include_dir=...) and every PHP application on that server can make use
>> of it, including TYPO3

> This one is of minor interest. A successfull extension can't depend on
> a system administrator getting in action first. But good as
> additional solution for the professional agencies. The next one for the
> masses.
> 
>> - for local PEAR installations the user has to install the "pear" TYPO3
>> extension. The extension is installed in typo3conf/ext/pear/ and will
>> create a typo3conf/tx_pear/ directory (local to the current
> 
> That is the innovative suggestion. Is this conform with the coding
> guidelines?

The suggestion came from the core list (Martin Kutschker). I think there
is currently no guidelines on where extensions can install their "local
stuff". The requirements are:

a) will be local to the current installation (typo3conf fits to that)
b) will not be overwritten when I upgrade the extension itself (which
then excludes typo3conf/ext/<ext-key>).

So the logical place would be typo3conf/<something>/. As the typo3conf
tree already is known as "local installation", it will be included in
backup tools so one could replicate the same setup just by

a) installing typo3_src from SOURCE
b) copying the common directories (typo3conf, fileadmin, uploads) to the
new location

So I think this is the "best location" we currently have.

>> installation). In typo3conf/ext/pear/ext_localconf.php the extension
>> will add that path to include_dir (using ini_set(...)) so that any
>> "require(<pear-class>.php)" will find its stuff there. The "backend
> 
> That is the point that I am frightend of. The point that needs to be
> reliable. Does this work in any case? Aren't there often cases were
> this setting fails because of the providers settings, CGI/module
> stuff, whatsoever. What tells experience about this?

I never had problems in setting the include_path using ini_set. Or would
you go the "hard way" and load PEAR modules using div/lib routines? How
would you handle PEAR modules loading other PEAR modules on its own?
They usually do a "require('classname.php')" and expect that to work. We
cannot change that in PEAR classes... So we need to have the PEAR path
in the include_path, else PEAR won't work. Setting this at runtime is
possible the most reliable option and I don't see any hint in PHP
documentation telling us that it of restrictions on how it can be used
(safe mode, cgi bin etc).

>> module" to install aditional pear modules will simply drop its
>> additional pear packages in typo3conf/tx_pear/ (pointing the php_dir
>> setting to that directory and possible calling the pear CLI to do the job).
>>
>> Won't that work?
> 
> Maybe. I am not sure if it would work reliably under all circumstances. A
> reliably working PEAR installation is the prerequest to get mature forms
> libraries into action quickly and not only them. It's the default PHP
> library system.

Now I understand that the main problem is to be able to have the
extension manager "know" about pear dependencies. E.g. someone wants to
install extension "abc" that requires PEAR module "Forms v1.0.0".
Ext.Manager either has to know about PEAR, or better:

The "pear" extension has to hook into Ext.Manager so that those new
dependencies can be handled. E.g a hipotetical ext_emconf.php:

        'constraints' => array(
                'depends' => array(
                        'php' => '4.2.2-',
                        'typo3' => '3.6.0-',
                        'pear' => '1.0.0-',
                ),
                'pearDepends' => array(
                        'Forms' => '1.0.0-',
                ),
                'conflicts' => array(
                ),
                'suggests' => array(
                ),
        ),

something like that. Ext.Manager checks for "pear > 1.0.0", and "pear"
hooks into Ext.Manager so that it can interpret the "Forms > 1.0.0"
dependency (using "pear list" or whatever mode there is to detect that)
and offer to install the missing pear packages in typo3conf/tx_pear/.

The "global sysadmin" can choose to install in /usr/share/php, which
will also be found by the dependency checker of tx-pear or the user can
install its "local" version using the TYPO3-Backend as Admin (no need to
bother the sys-admin). Either way the dependency will be checked and
recognized by the extension manager.

I would agree upon such a framework, and would also "negociate" the
required hooks into Ext.Manager to get that done. But.. we still need
someone to code that. :)

What do you think?

Cheers,
Ernesto