kenyan's picture

Posted by kenyan on February 28, 2010 at 3:19am

It may be due to changes that were done on Godaddy servers but in essence, the new version of openpublish (1.7.0) will not install normally on Godaddy.
The reason I say it may be due to changes was that I originally was able to install OP 1.6.* without making any changes to php.ini but an an attempt to upgrade to the new version led to some issues:

1. After doing the upgrade as per instructions http://www.opensourceopenminds.com/openpublish/openpublish-16-17-upgrade... I noticed errors especially to do with context but was also not able to reset overriden 'Feature' components to default settings. But, other than that, the install was working.
2. I already had articles and events before upgrading and these seemed basically untouched as documents. The issue though was that the views seemed to be messed up somehow. For example, featured articles should be one on the frontpage with the rest degrading to the article block view etc.. Instead, all my articles were showing as featured on frontpage and then repeated again at the block view... hence my left sidebar content was too long.. I figured this had to do with context.

Since the install seemed to be working fine apart from above issues and after checking and realising that infact the context module and a bunch of other modules with the install profile were outdated, I updated these and then updated the database. Things didnt improve. So, I decided to do a clean install of OP 1.7.*
Then all hell broke loose.

Where I had previously been able to install OP 1.6 pretty effortlessly on godaddys shared hosting (normal drupal of course installs just fine) I now could not get past the white screen. I did not even get to the point where I input database data etc.
To note though with Godaddy is that a php.ini file is available in the web root for shared hosting but I believe that any settings made to do with execution times and memory in this particular file are overridden elsewhere. So, looking at the new requirements:

I knew I was in for trouble with installing on the shared hosting due to the fact that I would not be able to change these settings. For shared hosting, Goddady seems to cap memory limit at 64M and as stated earlier, any changes to php.ini get overridden.
I then decided to revert to OP 1.6 which I luckily still had saved on my hard-drive (as it turns out, locating older versions of OP is tricky). I then realised that I could not get past the white screen with 1.6 either. Something must have changed over the few months that had passed while using the original install.
So now, here I was in creek valley without a functional website when I was doing just fine a few hours before I noticed the that OP had a new version. Lesson? Yeah, back it all up however smooth and simple things seem to be running.

But, I did note that the install runs fine on the shared host. All I needed to do was get it installed. I then deleted my old files (I was way gone already anyway) while retaining my settings.php and uploaded the OP 1.7 files as usual and replaced the settings file with the saved one.
I went into phpmyadmin and cleared out all the tables.

I then did a local install of OP 1.7 on my local computer on which I am running Ubuntu Linux. So I wouldn't have to change too much, I used the same login and password on the local install as I would on the server. Same site name, emails etc. and made sure not to add any extra modules so that my local and remote files were similar. The local install ran pretty quick on 128M memory though I could have raised it if needed. I had the execution time at 60 seconds.

Now, all I had to do was backup my local drupal OP database and then export it back to my currently clean online database. After some searching online I realised I should clear my caches before I saved the databases to make sure these cache tables were empty when I exported.
I am mostly lazy and clueless when it comes to mysql without a GUI. I wasn't going to mess around trying to backup my database via command line. I simply installed the Backup and Migrate module http://drupal.org/project/backup_migrate
I enabled the module and proceeded to do a quick backup of the database as both a .txt file (1MB) and a .ZIP file (110KB) since I was not sure which would work better on Godaddys phpmyadmin. Eventually, I used the text file which is saved as SQL commands.
I quickly imported into the remote database and pointed the browser at my site. Viola!!
Well, the excitement only lasted a few seconds as I realised only the home page would show. All the other pages showed a 500 Error message and any attempts at going into any of the pages that needed admin access led to entry denial while I could not login due to the white 500 error screen.
At this point, I am not entirely sure what causes the above behaviour. I went back into the database and removed the tables for the Migrate Module (3 of them) and tried again. No cigar.
I then decided to update the database by going to /update.php but of course I had no permission to update as I was currently locked out of admin. Luckily Drupal offers a setting in settings.php to allow non-admin update:

I changed the setting to TRUE and carried out the update. I could kinda tell I was in the clear when there were no error reports at the end of the update. A quick login and look around confirmed that the install indeed was working just fine!

So, after my long pointless rant, I believe this process should work for most hosts that can run a normal drupal instalation with a little extra memory for performance. And, in short, the process is:

1. Download and install OP to local server using similar login and site information etc.
2. Upload files to remote server and change database settings in settings.php.
3. Remove write permissions from settings.php and the default folder.
   4.Download, install and enable the Backup and Migrate Module. Proceed to backup your local OP install.
4. Import the backup SQL file into your remote database (piece of cake with phpmysql etc)
   6.Remove the Migrate module tables from the database (not sure this is necessary though).... tell me
5. Do an update of the remote drupal install. Grant update_free_access if required and change back later.
6. Cross your fingers and login.

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: