We have a set up for /var/virtualservers/ path and of course we don't allow ftp access for clients deploying off our servers
Drupal 7 assumes one has ftp access set up to the server for the client. That's neither a secure nor very diverse option to have when developing themes.
Perhaps this is more of an architectural issues with Drupal in seeing that I don't authorize ftp on port 25 period, let alone be the means to uploading new themes for clients to do so.
At the very least Drupal 7 should have sftp on port 22 as one option and a general Debian solution for Drupal should think about the deployed solution first as to how best to distribute files and how a solution could be easily accessible for clients and maintainers of the drupal package installed.
I'm surprised Drupal 7 didn't address more of this. Seeing as I control the server I can handle the means upon which Debian handles how it distributes Drupal's core files versus client/user account themes.
It just seems cautionary to think that we make sure not to break any standard approach to theming that Drupal currently expects with the template php files and what not when going to a non Debian deployment server.
Presently I'm sudo cp gz archives under a client account's theme path and then extracting them which Drupal will then recognize.
That is not what I call hands-off and very slick as a solution Drupal decided to be as the hidden option possible when uploading Themes other than non-secure ftp port 25 access.
Perhaps it's a big future feature to offer Sftp, WebDAV and other means to allow clients to upload their own custom themes but it would be nice if the package maintainer submitted a request to at least get the ball rolling on Sftp port 22 as an option where themes can even be installed under a clients home account ala $HOME/drupal/user/themes or something to that extent that allows Drupal access to read the theme files only before serving to the web client.
- Marc On 09/05/2011 08:49 AM, Kasper Loopstra wrote:
On 09/04/2011 09:22 PM, Luigi Gangitano wrote:This would be possible to use for sites/default, since a default site should not change (or should it?) during the course of the install (outside of updates via aptitude).Hi all, /usr/share is not an option since there should be no user-created file there (see FHS 2.3 athttp://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#THEUSRHIERARCHY<http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html>).I agree it is predictable for config files. However, image data (PNG files) are probably not considered a config file.I used /etc/drupal/7/sites for configuration files (settings.php belongs there as the equivalent files for horde or phpmyadmin do), so that a predictable path could be used by maintainer scripts and utils.The same kind of symlink currently used in /sites/default/files might be used to move everything under the sites/all folder to /var/lib/drupal/7/sites/all/.Probably module files belong to /var/lib/drupal, which should be created ad-hoc, but drupal as many other web apps is not so distribution-friendly since it expects files to be under its main folder (currently /usr/share/drupal7).Especially the large amount of data in themes, as well as the libraries and modules.Is there any other file you wish to be moved?Thank you very much for you attention, Kasper Loopstra.Regards, L -- Luigi Gangitano -- <lu...@debian.org <mailto:lu...@debian.org>> -- <gangit...@lugroma3.org <mailto:gangit...@lugroma3.org>> GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26
-- Marc J. Driftmeyer Email :: m...@reanimality.com <mailto:m...@reanimality.com> Web :: http://www.reanimality.com Cell :: (509) 435-5212
<<attachment: mjd.vcf>>
