-
2011-10-27
gb
The message says all. Fresh install of DokuWiki sources of today, chmod -R 777 data, fired up the browser. This message appears.
-
2011-10-30
lupo49
This is not related to Windows systems.
It appears when you browse the Wiki after setting it up through install.php?
-
2011-10-30
gb
Of course it's not related to Windows systems :-)
It appears from a fresh clone of the current master tree (only chmoding 777 the data subdir).
-
2011-10-30
andi
I guess we need to check for the writability of the conf folder now. Similar to what we do for the data folder(s).
-
2011-10-30
gb
Would something like:
+ $configdir_path = init_path(DOKU_CONF);
+ if(empty($configdir_path)) {
+ nice_die("The config directory does not exist, isn't accessible or writable.
+ You should check your config and permission settings.
+ Or maybe you want to <a href=\"install.php\">run the
+ installer</a>?");
+ }
in init_paths() of the init.php file be acceptable?
-
2011-10-30
gb
lupo: install.php already checks writability of the conf directory, so no issue when you install DokuWiki through that way.
-
2011-11-03
ach
That means we can close this issue, right? When installing, it would be necessary to make ./conf writable anyway...
But maybe it's worth putting that into '?do=check'?
I will update
http://www.dokuwiki.org/install:permissions accordingly.
-
2011-11-04
gb
IIUC this plugins.local.php gets refreshed or rewritten some time, right? If so, then the conf/ dir has to be writable not only for installation but for standard operation (running the wiki) and thus making the config dir writability check is needed whatever.
-
2011-11-04
ach
But plugins.local.php doesn't behave differently than any other file in the conf folder. Nearly all of the files in that folder need to be writable (not just during installation). So what is different here? The only difference I can see is that this file is new.
Do you have any checks for the others which should include this file? If yes, which checks exactly are you talking about? Is there more than one?
-
2011-11-05
andi
The problem is that the new plugin enable/disable mechanism runs automatically the first time to ceate this file if it doesn't exists, resulting in this error message.
Guy's suggestion from comment #4 would be one possible soltion, another would be to *not* write an empty file. But this would still produce an error if a user upgrades an installation with disabled plugins.
BTW - I just noticed we deliver a preconfigured plugins.protected.php file - this makes it impossible to adjust this file on your own as it would be overwritten on updates :-(
-
2011-11-05
gb
1. I'll modify check() to test if conf/ is writable. It's already done for the users.auth.php file, but is missing for the acl.auth.php file (in case useacl=1) and missing now for plugins too. If there is a test on conf/, than the test on users.auth.php (and the missing test on acl.auth.php) is useless. Worse, the current test (is the file conf/users.auth.php writable) outputs wrong result when the file does not exist (fresh install of a wiki). If the conf/ directory is writable, than the files (users.auth.php, acl.auth.php, plugins.whatever.php) will be.
2. Concerning the plugins.protected.php file itself, is that really needed? In lib/plugins/plugin/admin.php the bundled scripts are already specified as protected, but maybe that's different, I don't really understand the cascading logic/stuff currently. If that is needed, than a better logic would have been to distribute a plugins.bundled.php file (with hard locked plugins for the core wiki) and leave plugins.protected.php up to the admin of the wiki (with maybe a plugins.protected.php.dist file distributed as an example).
-
2011-11-05
ach
Concerning your second point, I guess it's best if Hakan and Piyush will have a look at this. Although I understood most of the logic at some point, I lost track since then.
-
2011-11-05
gb
-
2011-11-06
piyushmishra
The problem with bundled and protected plugins is that some of the bundled plugins are not protected.
Protected plugins do not allow disabling at all while some of the bundled plugins, popularity for example, do.
As I understand now, plugins.protected.php file with the install is not meant to be edited by the user for this reason. (as Andi pointed out)
If they need to add other protected plugins, they should add it to the cascade in their preload.php
Or if we really want to support adding plugins to the "default protected" file, we can make the installer add the protected plugins to the current plugins.protected.php?
May be adding another bundled file will help as all logic will move to a single place. (the check in the plugin is redundant it should not be trusted)
When installing DokuWiki, I never hit this issue as I always did "chmod 755 conf/ -R". As Anika pointed out, I assumed that was what it needed.
-
2011-11-06
ach
Andi, Hakan, Piyush, regarding "plugins.protected.php", wouldn't a "plugins.protected.local.php" be created for local changes? At least that would follow the current general rule.
-
2011-11-06
piyushmishra
We can rename the current protected to "plugins.protected.default.php" or "plugins.default.protected.php" to show that this is the default file and should not be edited?
-
2011-11-06
ach
No, I don't think that's necessary (as we don't do that with the other config files either).
If my assumption is correct that it will be possible to have local plugins.protected.php files in the config cascade (sorry, I don't remember), then I think we can close this task.
-
2011-11-06
ach
To go the same way as the other config files, we could probably distribute the local .dist file as well: plugins.protected.local.php.dist and add it to the config cascade.
That way it would also make clear which file to edit...
-
2011-11-06
piyushmishra
yes the distribution file would make it simpler :) we just need to add the filename to the cascade then
-
2011-11-06
ach
For the record, we just discussed it on IRC:
http://irc.dokuwiki.org/index.php?d=2011-11-06#msg359543
Conclusion:
a) change plugins.protected.php to plugins.required.php
b) add both to the cascade (so that protected acts as local and can overwrite required)
c) don't add any .dist files (as it's a rare case someone would want to use it)