You’re supposed to get that response when you visit an OAI URL using a web browser. However, other things seem to be wrong with your installation – and you’re running a version of OJS which is more than 7 years old. I’d strongly suggest that you start by upgrading.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi Asmecher,
Thanks very much for your reply.
Yes, it is a 2.2.1 version of OJS. I’m aware that some things are wrong with the installation, but I cannot find out what is actually wrong.
I have been asked for help by the institution on charge of the journal, and have also recommended them to upgrade. But I’m not 100% sure that core code has not been altered, as they say they had a technician on board some years ago who might have accidentally edited some files. Furthermore, I’m not quite sure that the installation process was deployed as it should have been.
Actually, I’m lost. I’m new to OJS and don’t know whether installing a clean 2.4.6 version and then try to migrate the database would suffice.
Sorry if this is much for a single topic, but I think I need a roadmap to face the problem and produce a reliable solution I can recommend and apply for them.
Any advise would be deeply appreciated.
Thanks in advance,
Juan
Take a stock copy of OJS 2.2.1 and use the standard diff tool to compare it to the installation. This will help identify any modifications that have been made to the code. You’re likely to find cosmetic changes, but probably not anything too much deeper than that.
Get a fresh copy of the latest stable release of OJS. Use this to run a “full package” style upgrade (described in docs/UPGRADE).
Re-apply the changes you identifiedusing diff. These will likely require some work, because the upgrade is so significant.
The big question is whether the database upgrade process works smoothly, since the upgrade is such a big step. It most likely will, but if you do get an error message, post it here and I’ll see if I can help. If the data upgrades successfully, you should have a working journal site on the new code and you’ll just have to worry about matching the costmetic changes to the layout.
Regards,
Alec Smecher
Public Knowledge Project Team
HI @asmecher,
thanks for your reply.
I’ve downloaded a stock copy of a OJS 2.2.1 and decompressed it on my PC. I’ve also downloaded the installed version to my PC. Is this correct for comparing both instances?
If so, I understand I should not go for a full compare diff, as I will be getting lots of differences which are not errors. If I am right in this approach (which I think I may be not), which files or directories should I focus the comparisson on?
Thanks in advance for your help.
Regards,
Juan
When I’m doing this I perform a full comparison, but then remove anything referring to the cache/ directory, as those files aren’t relevant. That will usually bring the .diff file down to a reasonable size that I can review manually. (Alternately, if yo’ure working on copies of the installation, you can remove everything from cache/ before using the diff tool to compare.) The files_dir (as configured in config.inc.php) shouldn’t be inside your web root – if it is, be sure to move it outside for reasons described in docs/README – so it shouldn’t be captured in the comparison anyway.
If it’s a typical modified installation, you’ll probably see a bunch of scattered template changes and little else. This is where most front-end tweaks happen and most installations just have a few of those.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
Thanks for your reply.
I used the software Beyond Compare as I’m not familiar with the standard diff tool. I found no significant differences, between the installed verstion and the stock copy, except for certain folders which are not in the stock copy (as expected), such as cache, or files and files_bk.
In the config.inc.php file, all variables appear to be set to the correct values (installed=On, database name and credentials, locale=es_ES, connection_charset=utf8, database_charset=utf8, files_dir (I think this was configured to be placed inside de installation). But repository_id is set to a value between quotes, which I don’t know if it is correct. This is set as “ojs.www.pasosonline.org”, including quotation marks.
Actually, the OAI url is something that the institution in charge of the Journal needs to sort out urgently, as they need to provide it to several scientific publications indexers. They are inserting references manually as they have not been able to provide a valid url for harvesting.
Something that seems relevant is a 7MB error_log file with lots of PHP warnings, some PHP Fatal errors and some OJS: DB Errors.
There is also a file named articles.sql, which seems to be a sort of database dump they did once.
Further to the OAI issue, the bugs users are currently pointing out are:
When submitting an article metadata cannot be saved in languages other than Spanish. The correct form is
displayed, but information is not saved, displaying an error message.
System does not inform on changes in article records to their supervisor editors. No mails are sent
When an issue is published, an abstract should be shown. But it won’t
Thaks again for all your help, and sorry for such a long post.
I attach the results of my analysis to this post, just in case you can have a look at it and can provide me with some extra advice, which I will deeply appreciate to move on further towards a solution.
Kind regards,
Juan
Unfortunately I can’t review this in detail, but since OJS 2.2.1 is so old, I’d suggest starting with an upgrade and seeing if that knocks a few issues of your list. I suspect it will, and should also massively decrease the size of your error log – PHP has changed in a lot of ways since OJS 2.2.1 was released. Then we can work on the individual issues from there.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
I’m proceeding with a “full package” upgdrade, following instructions in docs/UPGRADE.
I downloaded a 2.4.7-1 version of OJS and decompressed onto the same hosting as the current 2.2.1.
Copied the current 2.2.1 config.inc.php to the new 2.4.7-1, and the folders public/ and files/.
I’m now on the step “Replace the current OJS directory with the new OJS directory, moving the old one to a safe location as a backup”, which I’m not quite clear about its meaning.
The current installation is on a directory which was named “/ojs”
I decompressed the 2.4.7-1 in a directory which I called “/ojs247”
Do I need to move (or copy) all contents of the new /ojs247 into the current /ojs ?
Will moving the current contents of /ojs to another location be enough as a backup that can be reverted in case everything fails?
Hi @asmecher,
I did a copy of my current OJS so I can work with it for upgrading testing, prior to doing on the live installation.
I have two questions regarding upgrade to 2.4.7-1 procedures:
1) The upgrade doc says I need to migrate Stats. I understand I have to download the geolocalization database and decompress it in the plugins/generic/usageStats directory of the new OJS, as there is no such directory in my current 2.2.1. I am right?
2) I’m following the Full Package procedures. When it says “Replace the current OJS directory with the new OJS directory”, does this mean I will have to move all directories and files in the root 2.4.7-1 OJS directory into the root OJS 2.2.1 directory?
The upgrade doc says I need to migrate Stats. I
understand I have to download the geolocalization database and
decompress it in the plugins/generic/usageStats directory of the new
OJS, as there is no such directory in my current 2.2.1. I am right?
Yes, that’s correct – see docs/UPGRADE for details.
I’m following the Full Package procedures. When it says “Replace the current OJS directory with the new OJS directory”,
does this mean I will have to move all directories and files in the
root 2.4.7-1 OJS directory into the root OJS 2.2.1 directory?
Alternately, you can move your old directory out of the way, then just bring in the elements you need to the new code – the contents of public, and your config.inc.php configuration file, typically.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
Thanks for your reply.
This is what I’ve done:
I decompressed a 2.4.7-1 in the server where a I have the 2.2.1 running.
I followed the instructions in the upgrade doc.
Copied my current 2.2.1 config.inc.php file, and public/ and files/ directories into the 2.4.7-1
Copied the whole contents of the 2.4.7-1 back to the 2.2.1, replacing the contents of the current OJS (2.2.1) directory with the contents of the new 2.4.7-1 OJS directory
Before I proceed to reviewing the Configuration Changes section of the release notes in docs/release-notes/README-(version) for all versions between 2.2.1 and 2.4.7, I would appreciate if you could tell me whether what I’ve done is correct, as I it looks a bit confusing.
It’s better to start with a new directory, rather than copying the contents of the new version over the contents of the old. In some cases the old version will contain files that don’t exist in the new version, and this will make a mess.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
Thanks for your reply.
This is what I’ve done.
Uploaded and decompressed 2.4.7-1 into the hosting. Copied into the 2.4.7-1 the following directories from my current 2.2.1 installation:
/flies
/public Uploaded the geolocalization db to plugins/generic/usageStats in the new 2.4.7-1 and decompressed it
Modified the following in the 2.4.7-1 config.inc.php:
charset_normalization: On
connection_charset and database_charset: ut8 (not utf-8), this is how it is in the live ojs 2.2.1 and also I read a post in which someone says this should be this way.
persistent_connections: On (this is how it is in the live 2.2.1)
cache: file (as in the live 2.2.1)
FileInfo (MIME)
—I see that the line “mime_data…” is commented in the 2.4.7-1 and not in the live 2.2.1. I’ve left it commented.
I’m now proceeding to database upgrade, and have kept “installed=Off” in the 2.4.7-1 confi-inc.php
If I now access the url where I have the 2.4.7-1 I’m presented with the 2.4.7-1 installation page. I intend to skip installation and go directly to the upgrade option: “if you are upgrading an existing installation of OJS 2.x, click here to proceed”
My questions are:
Do you think the above is correct?
If so, will I need to increase php.ini max_execution_time prior to upgrading? (it is currently set to 30)
Sometime between 2005 and present, the file option for caching stopped being listed config.inc.php. I haven’t looked carefully, but I suspect the value of file will now effectively be a value of none.