[development] drupal vs. free hosting action points

[Gabor Hojtsy]

Hi,

Since there is a significant interest in the Hungarian Drupal user crowd 
to use Drupal on several of the free hosting accounts provided in our 
country, and there were quite a few problems before, I decided to look 
into installing Drupal on the two major free hosting services (ultraweb.hu 
and freeweb.hu). Here are my observations on supporting free hosting 
providers (it was not straightforward, nor easy for a beginner).

1. Everything is under the webroot. You can put nothing out of the webroot 
folder. This makes you lose the private files feature, and forces you to 
set up an upload temp folder under the webroot. Fortunately Drupal tries 
to suggest a folder under the files folder, so the temp folder is also 
(supposed to be) protected from malicios PHP files, if .htaccess would be 
supported. => Nothing to do here, just a fact.

2. Htaccess files are not allowed. At least you are prevented from 
uploading them via FTP. You can create them with PHP (the .htaccess in the 
files folder is created), but then the contents does not matter. I bet 
they have AllowOverride None set. => Implication: Clean URLs are unusable, 
PHP settings are not set as ideally expected by Drupal. Fortunately Drupal 
is capable to work even in these harsh conditions, given the code to 
programatically turn off magic_quotes for example. But there are security 
problems, since the .module, .theme, .install, etc files are not 
protected. Only phptemplate theme files are protected because of their 
free hosting friendly .tpl.php extension usage.

  Action point: maybe we should revisit using .module.php, .theme.php,
  .install.php etc file extensions

  Action point: look around what is affected if the expected PHP
  settings are not there

3. Some of the PHP functions are disabled, so the screen is full of 
errors, instead of Drupal working right. The affected functions on the two 
hosts are:

  - ini_set (in settings.php) => nothing set with this is effective
    (even where this is enabled, the settings are set with php_admin_value
    in Apache, so we cannot override several settings)

  - mkdir(), chmod() (in the files and temp folder setup) => cannot create
    the folder and/or chmod() them to the right permission

  - realpath() (used in files related code)

  Action point: wrap the ini_set() call into a disabled_functions check

  Action point: replace realpath() with drupal_realpath() and use a less
  secure but at least somewhat working alternative if realpath()
  is not available (see http://php.net/realpath user notes)

  Action point: think about making the mkdir and chmod calls
  conditional too

  Action point: provide a compatibility summary page, where the existing
  GD, clean URL and other stuff is moved to, plus PHP settings and other
  stuff is checked for and displayed => one knows how secure or capable
  his system is by visiting this page (Q: how is this affected by
  the install system?)

4. Because of some restrictions on the runtime of PHP scripts, it is not 
surely possible to import the Hungarian translation in complete. Some of 
our users manually split the po file into six or more chunks (with po 
headers added to all chunks), and import these one-by-one manually. This 
is ehm, quite lame to suggest... What seems to be a solution is to get 
back to SQL imports for languages, at least for supporting these 
restricted hosts. This has other advantages of setting up language 
specific parameters (while we are waiting for an installation profile 
system :).

  Action point: investigate providing translations as SQL dumps additionaly
  to PO files

By the way our free hosting services are not employing any of the CPanel, 
Plesk or other web admin software. They all developed their own home-grown 
solutions, so the limitations, setup screens are all different (and 
sometimes quite confusing even for experienced people like me). Mail 
sending has its different tricks on different hosts, some have nice 
daily cron support, some have no cron support. All use phpmyadmin though, 
so this is the common starting point.

I would suggested we first discuss these action points, and then find 
people to implement those desired.

Gabor