Am developing a website using Zenophile and have had no problems so far. I am relatively new to drupal and am far from being an expert.
Have, however, noticed your advice under Filesystem Permission issues. The drupal installation is in a folder drupal6 off what appears to be the root (/) but the hoisters say they don't provide root access. It is a Linux site. When you say "you’re not using Zenophile in the manner it was intended to be used" what exactly do you mean and, as I have had no problems so far am I likely to have them in the future?

Comments

Aham’s picture

Hi

Generally I don't develop on shared hosting. I just use shared hosting for a completed site. I develop on a local server (my computer) until the site is perfect, then upload the whole Drupal directory to the public_html folder on the shared hosting site and import my the mySQL database. I have used wamp, xamp, and quickstart linux virtualbox (my personal favorite)) to develop locally. These programs create an environment just like your shared hosting to run Drupal on, but you have root access to everything.

I suggest once the site is developed on your local machine. Disable the Zenophile module and any other development style modules and then upload via ssh or ftp (hopefully with one compressed file) to your shared hosting folder.

Your shared hosting provider should have a control panel of some kind. In the control panel there should be a place where you can uncompress the file you uploaded to your public_html directory. You can also use the command line via ssh.

I hope this is helpful. If you have anymore question please ask.

Jonathan

bogorman’s picture

HI Jonathan,
Thanks for your helpful post.
I used to develop locally using MAMP but then went over to developing remotely on the shared hosting site. I do not seem to have any problem. What are the advantages of developing locally?
What I can't understand is the importance of having root access. If I have never experienced problems to date am I likely to experience them with, say, updates to Zenophile, or for any other reason.
Also, you suggest disabling Zenophile before uploading to the remote (shared hosting) site. Why do I need to do this? I have, on more than one occasion restored backups (copies of all the drupal files downloaded to my local machine plus a mySQL dump file which I created on my local machine which I imported). These restored with no problems and they included the Zenophile files.
Sorry to be so long winded but I still can't understand why Zenophile when run on a shared hosting server is "not using Zenophile in the manner it was intended to be used".
If course the site I am developing remotely is not "live". I will only go live when everything is working ok.
Would very much appreciate your further comments, Jonathan, on these various points.
Brian

Aham’s picture

If you really want to develop remotely, there are virtual private server (vps) packages which give you full control for about the same price as shared hosting. I was looking around last night and came across http://vpsdeploy.com/# and I could not believe that the price was only $4.95/month. Normally, these are $25 a month or more and running on SSD hard drives too! Some of them will install a lamp stack for you but with other vps packages you may have to follow a tutorial. Not hard to do. I would recommend choosing an Ubuntu image for your server. It seems to be the most seamless distro of Linux and good for beginners.

To answer you question though, I would say that you will run in to problems if you do not have root access, at least for development. No root access can impede development in general. For instance, how do you install drush without root since you have to use the sudo command? Drush is an essential, almost standard tool for Drupal development. It is a command line utility for drupal. You can download and unpack a module into the correct directory with "drush dl modulename" or enable a module " drush en modulename" or clear the cache "drush cc all", etc... super fast!

I have not used Zenophile, so for specifics about it maybe a Zenophile expert can jump in here. =) I hope I was helpful anyway. If you need help with the vps contact me. I have some scripts that make it a bit easier.

Generally working locally on the first version of your site is considered best practice.

Cheers,

Jonathan

bogorman’s picture

Hi Jonathan,
Thanks so much for your help.
I will certainly think of changing the hoster though as I have just moved to the present one and as I am very pleased with their service I am reluctant to do this.

I suppose, judging by your comments, if I am not experiencing problems at present I could continue with my present system with the disadvantage of not having root access. I have never used drush and I know that I cannot use it with the present hoster. It would appear that drush provides a much more efficient way of developing a drupal site - installation and updating modules for example. At present I just use an FTP program to do this which is laborious but it works. Perhaps there are other advantages.

Anyway, thanks very much indeed.

If there is an expert in Zenophile it would be good to hear from them particularly regarding the statement "not using Zenophile in the manner it was intended to be used" on the Zenophile help pages.
Brian

Garrett Albright’s picture

Status: Active » Closed (works as designed)

Brian;

I could go off on all the advantages of developing locally versus remotely, as they are nearly infinite, but I'll keep it short and just stick to how it relates to Pathologic.

Typically, but not always, the web server daemon (Apache, usually) on a web host is running as a single particular Unix user on the server (often "apache" or "www") as it serves pages for every hosting account on that server. This means that the files that the daemon creates are going to be owned by that daemon user. Now when you access the server via FTP or SSH, you're probably logging in as a different user than the one the web server daemon is using. When that's the case, then depending on various factors, you may not have access to read, edit or delete the files in the theme directory that the daemon creates at Zenophile's request.

Now if you have root access to the server (such as if the server is located on your local computer), this isn't a problem, since with a single command you can change ownership of the directory back to your account and get to work. And it's almost a given that people who are developing sites are doing it on servers they have that level of access to. However, it's certainly not a given that that can be done on a "live" site, especially if it's on a shared hosting provider. That's why I strongly discourage people from using Zenophile on a shared hosting provider; before I had that warning in the documentation, there were at least a couple posts in this issue queue by people who had this exact problem.

At any rate, if you wish to advance as a web developer, I strongly recommend you get into the habit of only developing locally and only putting stuff up on the live server when it's in a stable state. Any truly professional web developer doesn't work any other way.