[dev] [commits] Horde branch master updated. 92777395c80c6ae515570038e14afb47ceb27175

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>>> 1cc360a A couple of more required files in IMP
>>>> 3bb74a2 A couple of more required files in Turba
>>>> 8416270 Another required file for passwd
>>>> b320317 Another required file for kronolith
>>>> d2035ef More required files for ingo
>>>> bda74fe More required files for gollem
>>>
>>> There's no sense in checking for those, because we ship them, and  
>>> they no longer need to be created by the users.
>>
>> ....Except we hear all the time about people that have issues  
>> precisely because they have removed these files.
>
> Really? I don't recall any. Which doesn't have to mean anything. But  
> "all the time" is definitely not true. What really happens all the  
> time is that people have incorrect .local.php file, see below.

Seems to me that there is all sorts of incidents where people force  
reinstall from PEAR and things are fixed.  This wouldn't fix issues  
with *.local.php files, so *something* is happening.

Obviously, reinstalling fixing this could be due to other issues.  But  
you must admit that this almost certainly COULD be the issue also:

mv prefs.php prefs.local.php

>> And more important... this opens up the ability to check for  
>> *.local.php files.  And even MORE importantly, this opens up the  
>> ability to do syntax/lint checking on these user generated files.   
>> So a user would know via the test page if one of their local config  
>> files is broken. (Also to do things like comparing to the shipped  
>> files and issuing a warning if the user simply copied it over).
>
> This would obviously only cover syntax errors. Unfortunately it  
> won't help against outdated .local.php files from earlier versions,  
> but it would be a start.

Anything other than syntax errors is beyond the scope at this point.   
But once again, there is traffic on the list for people that either

* don't know PHP syntax -or-
* Forget <?php at the beginning of the file

If we can prevent these issues, it is that many less unsatisfied  
people.  And it is that many less people who might give up on the  
installation altogether and try a different solution.

Maybe I should move the rest of my rant to a new topic, but I grow  
frustrated by hearing people think that Horde is "difficult to  
install".  I personally think it is no harder than any other web  
application.

As an example, I often look at other open source products out there  
(and go through their installation process) and see how they compare  
to us.  And for the life of me, I can't see how this is a "better" way  
of doing something like configuring a database (an example from  
another webmail application):

// Database connection string (DSN) for read+write operations
// Format (compatible with PEAR MDB2):  
db_provider://user:password@host/database
// Currently supported db_providers: mysql, pgsql, sqlite, mssql or sqlsrv
// For examples see  
http://pear.php.net/manual/en/package.database.mdb2.intro-dsn.php
// NOTE: for SQLite use absolute path:  
'sqlite:////full/path/to/sqlite.db?mode=0646'
$config['db_dsnw'] = 'mysql://xxx:@localhost/xxx';

Really?  This is supposed to be superior to our way of installing?  In  
what world?

But as long as people comment that our install/troubleshooting is the  
weak link and preventing them from using Horde, I will continually  
look at ways to tweak the install process/documentation.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]