OJS, PHP 5.3.6 and Blank Pages

[jje]

We have been running our journal on OJS 2.3.3.3 very successfully over the past few months. However yesterday our web host (Rochen) upgraded PHP to version 5.3.6 and since then all that is displayed is a blank page with no error message. Having contacted Rochen support they have replied that they can see nothing wrong from the server side and the problem is a 500 error being generated from within OJS itself. As an experiment I did try a fresh install with OJS 2.3.4 but the installer would not even load and again was faced with a blank page.

Our host is using Apache version 2.2.19, PHP version 5.3.6, MySQL version 5.1.56 on a linux server. Can anyone advise where this configuration is now incompatible with the OJS software.

We've spent a considerable time and effort setting up OJS and were very pleased with platform so any advice would be gratefully received.

Thanks
Joseph

[jmacgreg]

Hi Joseph,

I haven't heard of any bugs specific to OJS/PHP 5.3.6. Did your service provider change whether/how eg. FastCGI works on your server? Typically, you can check to see what kind of error you are running into with these instructions, and your service provider should also be able to give you more advice by looking at the error logs; it would be very strange indeed if you were seeing a blank page but with no errors.

Let us know if you see anything, and if not we can investigate further.

Cheers,
James

[jje]

Hi James

Thank you for your reply.

I tried entering ini_set('display_errors', E_ALL) in the php.index page and turning on the stack trace in the configuration file to no avail. All I ever got was the blank page and our host said no error was being generated. In fact they showed no interest in finding what the issue was, said the problem was with OJS itself and closed the help call.

As the site was down for several days and in order to get us back up and running we moved host to one who specifically deals with OJS. They transferred the site for us and everything is now working again. As I said in my earlier post we are delighted with the OJS platform but seem to have been unlucky in the choice of our old host.

Regards
Joseph

[jmacgreg]

Hi Joseph,

Well, at the very least it's good that you are now on a host that can help you out. While it's always possible that our software doesn't play well with any given service setup, we've gone out of our way to ensure that the basic system requirements are low, and we know of many, many OJS instances running on barebones hosting services -- even GoDaddy, Yahoo, etc. It sounds like perhaps your former service provider wasn't providing much in the way of service or support. Anyway -- good to hear that everything is back up and running, and let us know if you have any further questions!

Cheers,
James

[eamoore]

Hi, all,

I'm brand new to OJS. I just installed the latest version and am also seeing a a blank page with no error (when I try to pull up the OJS install in Firefox) and an HTTP 500 error (with Internet Explorer).

I've unpacked the OJS files, changed permissions, and I can see the install.php file in my html_docs directory.

Anything obvious I'm missing?

Thanks much for any help you can give me,

-Emily

[jmacgreg]

Hi Emily,

See http://pkp.sfu.ca/wiki/index.php/PKP_Fr ... do_I_do.3F for what to do when you encounter a blank page.

Cheers,
James

[acardh]

Hi,

I was also getting a blank page. I added the command ini_set('display_errors', E_ALL); to my index.php

My code in index.php is now:

Code: Select all

<?php

//Next line added by me to cause error messages to be sent to the browser:
ini_set('display_errors', E_ALL);

/**
 * @mainpage OJS API Reference
 *
 * Welcome to the OJS API Reference. This resource contains documentation
 * generated automatically from the OJS source code.
 *
 * The design of Open %Journal Systems 2.x is heavily structured for
 * maintainability, flexibility and robustness. For this reason it may seem
 * complex when first approached. Those familiar with Sun's Enterprise Java
 * Beans technology or the Model-View-Controller (MVC) pattern will note many
 * similarities.
 *
 * As in a MVC structure, data storage and representation, user interface
 * presentation, and control are separated into different layers. The major
 * categories, roughly ordered from "front-end" to "back-end," follow:
 * - Smarty templates, which are responsible for assembling HTML pages to
 *   display to users;
 * - Page classes, which receive requests from users' web browsers, delegate
 *   any required processing to various other classes, and call up the
 *   appropriate Smarty template to generate a response;
 * - Action classes, which are used by the Page classes to perform non-trivial
 *   processing of user requests;
 * - Model classes, which implement PHP objects representing the system's
 *   various entities, such as Users, Articles, and Journals;
 * - Data Access Objects (DAOs), which generally provide (amongst others)
 *   update, create, and delete functions for their associated Model classes,
 *   are responsible for all database interaction;
 * - Support classes, which provide core functionalities, miscellaneous common
 *
 * As the system makes use of inheritance and has consistent class naming
 * conventions, it is generally easy to tell what category a particular class
 * falls into.
 * For example, a Data Access Object class always inherits from the DAO class,
 * has a Class name of the form [Something]%DAO, and has a filename of the form
 * [Something]%DAO.inc.php.
 *
 * To learn more about developing OJS, there are several additional resources
 * that may be useful:
 * - The docs/README document
 * - The PKP support forum at http://pkp.sfu.ca/support/forum
 * - The technical reference (and other documents), available at
 *   http://pkp.sfu.ca/ojs_documentation
 *
 * @file index.php
 *
 * Copyright (c) 2003-2011 John Willinsky
 * Distributed under the GNU GPL v2. For full terms see the file docs/COPYING.
 *
 * @ingroup index
 *
 * Bootstrap code for OJS site. Loads required files and then calls the
 * dispatcher to delegate to the appropriate request handler.
 */

// $Id$

// Initialize global environment
define('INDEX_FILE_LOCATION', __FILE__);
require('./lib/pkp/includes/bootstrap.inc.php');

// Serve the request
$application =& PKPApplication::getApplication();
$application->execute();
?>


After that, instead of the blank page, I am getting this error message in my browser:

Code: Select all

Warning: require(./lib/pkp/includes/bootstrap.inc.php): failed to open stream: Permission denied in /var/www/html/index.php on line 64 Fatal error: require(): Failed opening required './lib/pkp/includes/bootstrap.inc.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/html/index.php on line 64


I know that it is an error from PHP but still I do not know how to fix it.
I am in charge of the server, I am running Scientific Linux 6.0 with Apache 2.2.15-5, PHP 5.3.2-6, MySQL 5.1.47-4 and OJS 2.3.5 which was successfully installed by line command.
Any help will be appreciated.
Thanks

[acardh]

In order to see if PHP is working fine, I made a new file called "test.php" and placed it in my root web dir, inside that file I put this:

Code: Select all

<?php
ini_set('display_errors', E_ALL);
phpinfo();
?>


Then in my Firefox browser I put the address http://localhost/test.php

PHP test page

php_test.png (100.18 KiB) Viewed 7611 times

With that output we know that the PHP is working fiine.

Again, if I put in my browser the address http://localhost/ the output is:

Code: Select all

Warning: require(./lib/pkp/includes/bootstrap.inc.php): failed to open stream: Permission denied in /var/www/html/index.php on line 64 Fatal error: require(): Failed opening required './lib/pkp/includes/bootstrap.inc.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/html/index.php on line 64


I have changed the permissions of bootstrap.inc.php and of functions.inc.php to 755 and also to 777, and in both cases I am still getting the same output error in the browser.

What is it the problem? Any ideas?

[acardh]

OK guys, I have solved the problem. The issue was generated by wrong file permissions, PHP cold not read some needed files. So, I set recursively the file permissions to 755 on all the files and directories. Only the directories "cache", "public" and the one created for the upload of files are set to 777 permissions.
In order to set recursively the file permissions in the "lib" directory, you can use:

Code: Select all

chmod -R 755 lib/


The same for all the other directories and files.
That's it, that did the trick.


Next I will put a post with all the steps that I followed from the beginning for the setup of the OJS. I guess that might be useful as a future reference.

[asmecher]

Hi acardh,

Glad to hear you've solved the problem -- but watch out for those 777 permissions; they're very likely a security risk. The best way to set this up varies from system to system, but the main thing you have to figure out is which user account PHP uses to try to upload files. Try uploading a file through PHP in your current setup, and see what user the file belongs to. It'll likely be "www-data" or similar. Then use chown -R to set the same owner for recursively in your "public" and "cache" directories (and anything else you set 777), and use chmod -R to drop the permissions down to 755 (or even lower -- 700 should work too).

Regards,
Alec Smecher
Public Knowledge Project Team

[julian]

I had this problem too - tried all the recommendations in the forums but got nowhere.

Eventually put some echo statements in code and found that the problem was a missing cache folder

created

cache\t_compile

And everything worked

[ramon]

Hello Julian,

The cache folder and its subfolders are contained within the .tar.gz compressed file.
This means you used a tool other than "tar" to decompress the file or used a Windows environment for this.
Winzip will NOT decompress empty folders, so you should use Winrar instead if that was the case.

Also, in the file ojs2/docs/README those folders are specified, which means they should exist for the system to be installed.

[julian]

Thanks - but that is not useful

Most people on Windows use Winzip - not WinRAR - and I am not going to install WinRAR just in case I run into this sort of problem.

Solution: Put it in the knowlegebase somewhere or put a blank text file in the empty folder.

Using WinRAR is not an obvious solution - my previous post was intended to help other Windows users and save them from wasting a lot of time (which unfortunately I had to go through before finding the problem)

[treydock]

I'm experiencing this same issue. Navigating to the path of the web directory results in a blank page, no Apache errors (even with LogLevel debug), and nothing reported when PHP error reporting is enabled. I've enabled all the debug options for OJS, but still nothing.

My system is CentOS 6.0, PHP 5.3.3. I've verified that ini_set is not disabled, and a test.php with the phpinfo shows correctly. This same server is currently hosting things like Drupal , Wordpress and Joomla just fine. The apache user owns all files and even tried chmod 777 with no luck.

I've tried versions 2.5.6 and 2.3.3 variants with no luck. Any suggestions are appreciated. If I could just get some debug output that would help me resolve this too, but all debug options enabled results in nothing.

Thanks
- Trey

[ramon]

Hello Trey,

Very difficult to identify what is going on without actually looking directly at your server.
Did you make sure to change owner of the application to the Apache user?