Article in limbo

Are you an Editor, Author, or Journal Manager in need of help? Want to talk to us about workflow issues? This is your forum.

Moderators: jmacgreg, michael, vgabler, John

Forum rules
The Public Knowledge Project Support Forum is moving to http://forum.pkp.sfu.ca

This forum will be maintained permanently as an archived historical resource, but all new questions should be added to the new forum. Questions will no longer be monitored on this old forum after March 30, 2015.
drjhf
Posts: 27
Joined: Sat Feb 18, 2006 8:31 am
Contact:

Article in limbo

Postby drjhf » Thu Apr 27, 2006 12:59 pm

An editor for one of our journals moved previously accepted articles from submission through acceptance to scheduling without uploading a galley, assigned the articles to a new volume and then published them. Of course, no PDF showed up.

Trying to upload a PDF as galley at that point failed - the upload led to a blank screen. The article can be removed from the volume, but it says that it is in scheduling...which is fine...but it is not...it is in editing and there is no way to move it to scheduling...since the system thinks it is there already.

Is the only way out to archive the article and resubmit it?

Thanks for helping unravel this.

asmecher
Posts: 10015
Joined: Wed Aug 10, 2005 12:56 pm
Contact:

Postby asmecher » Thu Apr 27, 2006 1:20 pm

Hi Dr. Fisher,

This is probably a few things in combination. There is a known issue in OJS <= 2.1.0 (bug #2114) whereby articles that are published, archived, then restored end up "stuck"; for now, you can list articles in this situation using:

Code: Select all

SELECT a.article_id, a.title FROM articles a, proof_assignments pa WHERE a.article_id = pa.article_id AND a.status=1 AND pa.date_scheduling_queue IS NOT NULL;
Then, if the list looks correct, unstick them by executing:

Code: Select all

UPDATE articles a, proof_assignments pa SET a.status = 2 WHERE a.article_id = pa.article_id AND a.status=1 AND pa.date_scheduling_queue IS NOT NULL
(This assumes you're using MySQL; if you're using PostgreSQL, I can send you the relevant SQL.)

As far as the blank page you're seeing, this usually indicates a PHP error. Check your server log for details. While uploading a galley, this usually indicates a file permission problem.

Regards,
Alec Smecher
Open Journal Systems Team

drjhf
Posts: 27
Joined: Sat Feb 18, 2006 8:31 am
Contact:

Blank screen on upload

Postby drjhf » Thu Apr 27, 2006 1:28 pm

Thanks, Alec...I will either try that or have them reprocess the articles, and the latter may be easier for them!

As for the blank screen, add this to your repertoire - as I have confirmed it - the PDF files they were uploading are in some way malformed - while they open in Acrobat and can be saved, they fail repeatedly to upload - with the blank screen appearing - and other PDFs upload nicely for those articles!

asmecher
Posts: 10015
Joined: Wed Aug 10, 2005 12:56 pm
Contact:

Postby asmecher » Thu Apr 27, 2006 1:31 pm

Hi Dr. Fisher,

Is it possible that these PDFs are too big for your upload limits as configured in php.ini or your Apache configuration? See docs/FAQ:
2) Uploads of large files fail inexplicably.

A: This can be caused by certain Apache or PHP settings.

Apache 2.x has a LimitRequestBody directive that, if set to a low number, can lead to this behaviour. In particular, the default PHP packages for recent
versions of Red Hat Linux set LimitRequestBody to 524288 bytes in
/etc/httpd/conf.d/php.conf.

Low values for the PHP ini settings like post_max_size (default "8M"),
upload_max_filesize (default "8M"), and memory_limit (default "8M") can also
cause this problem.

In any case, check your server log to see if there are any messages there that might clarify.

Regards,
Alec Smecher
Open Journal Systems Team

drjhf
Posts: 27
Joined: Sat Feb 18, 2006 8:31 am
Contact:

File size

Postby drjhf » Thu Apr 27, 2006 1:37 pm

That was the first thing I thought of, and the files are tiny (20-30K). Some in the original set they used upload perfectly, but others fail repeatedly...and other PDFs (nonsense files unrelated to the journal) upload perfectly. So gremlins in the files or on the outer membrane must be the culprits. Will check the log later.
Thanks
Julian

drjhf
Posts: 27
Joined: Sat Feb 18, 2006 8:31 am
Contact:

Upload issue

Postby drjhf » Fri Apr 28, 2006 2:17 pm

When I enter a new manuscript, having archived and then deleted the manuscripts that were problematic, I am able to upload a layout galley that worked before, but not the correct PDF that I just created from scratch from a carefully formatted ASCII-to-Word doc, then I go to replace the wrong PDF that I uploaded with the correct one, and the screen goes blank, but if I back up, the correct document has uploaded...

There are no errors recorded on the server. What is happening?

Julian

asmecher
Posts: 10015
Joined: Wed Aug 10, 2005 12:56 pm
Contact:

Postby asmecher » Fri Apr 28, 2006 2:21 pm

Hi Julian,

This is probably a text indexing problem, then -- you can confirm by running the tools/rebuildSearchIndex.php tool and seeing what output you get. If you see an error message, post it here; otherwise, let me know and I'll give you some suggestions for things to check.

Regards,
Alec Smecher
Open Journal Systems Team

drjhf
Posts: 27
Joined: Sat Feb 18, 2006 8:31 am
Contact:

Further glitch

Postby drjhf » Fri Apr 28, 2006 2:44 pm

I repeated the process, successfully, until I moved the next article uploaded with the first load - reload technique, to scheduling and received this error..

155) in <b>/usr/local/ojs-2.0.2-1/classes/core/Request.inc.php</b> on line <b>32</b><br />
HTTP/1.1 302 Found
Date: Fri, 28 Apr 2006 21:42:20 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-16
X-Powered-By: PHP/4.3.10-16
Set-Cookie: SEISID=35302c9367661b7ab033df2d8d4846dc; expires=Sun, 28-May-06 21:42:20 GMT; path=/ojs/
Location: http://scholarlyexchange.org/ojs/index. ... Editing/38
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

0

Your thoughts, please, Alec...and thanks.

asmecher
Posts: 10015
Joined: Wed Aug 10, 2005 12:56 pm
Contact:

Postby asmecher » Fri Apr 28, 2006 3:24 pm

Hi Julian,

Part of the message is missing; when you receive this error message, could you view the page source and ensure you grab the entire message from the source view?

Regards,
Alec Smecher
Open Journal Systems Team

drjhf
Posts: 27
Joined: Sat Feb 18, 2006 8:31 am
Contact:

Upload issue - continued

Postby drjhf » Sat Apr 29, 2006 2:37 pm

Further elucidation: when uploading layout galleys to a new test manuscript that has been accepted, the ones that failed before continue to fail, giving the blank screen after upload (and nothing actually uploads). These are PDFed Word docs created from pure ASCII text generated by an author, so there should be no stray or bizarre characters. All are 20-40 K, and other files do upload for this manuscript. On one occasion, I uploaded another random PDF file and it worked - but gave me a file size of B - just that letter, no number, no KB.

Then I created new content in Word, apart from the scholarly submissions, PDFed it and submitted it. It worked - as it should have.

Any thoughts on document content that might cause the parser to get upset?
Thanks

Julian

asmecher
Posts: 10015
Joined: Wed Aug 10, 2005 12:56 pm
Contact:

Postby asmecher » Mon May 01, 2006 9:36 am

Hi Julian,

Could you email me two sample PDFs at pkp-support@sfu.ca -- one that works, and one that causes the blank-screen problem?

Regards,
Alec Smecher
Open Journal Systems Team

asmecher
Posts: 10015
Joined: Wed Aug 10, 2005 12:56 pm
Contact:

Postby asmecher » Mon May 01, 2006 10:42 am

Hi Julian,

You're going to have to enlist some help from a server tech on this. Here's what I'd suggest testing:
  • Put the two files in a directory on the server
  • Create a command-line PHP script containing the following:

    Code: Select all

    <?php

    echo "First MIME type: " . mime_content_type('first_file_name.pdf') . "\n";
    echo "Second MIME type: " . mime_content_type('second_file_name.pdf') . "\n";

    ?>
    If both these files come up as PDFs when you execute the script, move on to the next step. Otherwise, you'll need to investigate your server's mime type detection setup (e.g. the mime.types file).
  • Try temporarily disabling indexing to see if the problem goes away. To do this, edit classes/submission/form/ArticleGalleyForm and comment out lines 118 and 146 (ArticleSearchIndex::updateFileIndex ...)
Post your results here and I'll provide a few more steps.

Regards,
Alec Smecher
Open Journal Systems Team


Return to “OJS Editorial Support and Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest
https://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=879
pkp.sfu.ca
crawl=CC-MAIN-2016-40
54897
application/http; msgtype=response
sha1:7LRKLDCBD7A7HAIZYJ2Y3SOEMVIEIJII
<urn:uuid:424f4fca-1f42-4aa7-baa0-2a64e1ff31e9>
2016-09-28T20:45:06Z
142.58.129.159
sha1:55EWJVA2ZXG6UQTLYSMDPF7RN3TQBQCP
<urn:uuid:266ab138-81ef-4051-b97b-8e7277d9b9f9>
https://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=879
length
response
<urn:uuid:0c0b27d9-6114-4285-8821-ccb17b711100>
robots: classic
hostname: ip-10-143-35-109.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2016-40
operator: CommonCrawl Admin
description: Wide crawl of the web for September 2016
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf