最近我编辑joomla的Gantry theme的时候,经常碰到css等文件,保存以后变成不可写“unwritable”的情况。
把这些文件的权限改成755,通过joomla一编辑保存,又变成555了。

在网上Google了一下,发现碰到这个问题的人还真不少。
比如这里这里,都用一堆人说这事。Gantry theme的用户也说这事

开始我以为是apache或者php什么地方的配置有问题。但是写了个简单的php脚本,跑了一下发现没这个问题,创建出来的文件的权限很正常。

直到看到这篇文章,才发现这是个老问题,从2006就有人不停的在抱怨了。

起因就是在joomla的模板组件的controller文件administrator/components/com_templates/controller.php里有这么几行代码:

// Try to make the template file unwriteable
if (!$ftp['enabled'] && !JPath::setPermissions($file, '0555')) {
	JError::raiseNotice('SOME_ERROR_CODE', JText::_('Could not make the template file unwritable'));
}

我也没看明白,没什么不使用ftp就要把文件权限改成555?自己改成不可写,然后再告诉用户”那个文件不可写”,还不说问什么。

当然像我这样不求甚解的人很多,这几行代码就被广泛的粘贴复制了。比如本文开头提到的Gantry theme

更加好笑的是,joomla的team在不断发布新版本。在最近发布的joomla 1.6.1里,似乎处于安全性考虑,之前设置文件权限为755的地方都改成了644。而这几行代码也顺理成章的从555变种成了444。

//administrator/components/com_templates/models/source.php
// Try to make the template file unwriteable.
if (!$ftp['enabled'] && JPath::isOwner($filePath) && !JPath::setPermissions($filePath, '0444')) {
	$this->setError(JText::_('COM_TEMPLATES_ERROR_SOURCE_FILE_NOT_UNWRITABLE'));
	return false;
} else if (!$return) {
	$this->setError(JText::sprintf('COM_TEMPLATES_ERROR_FAILED_TO_SAVE_FILENAME', $fileName));
	return false;
	}

现在这个问题的解决办法,就是把555换成755,或者444改成644。至于什么时候joomla官方能给出个正解,就不知道了。

相关文章

    共享到: