Illegal OAI verb in base URL

Software Support
1

Hi,
I need to send my base url for OAI Archive to a harvester. I’m getting the following error:
OAI-PMH xsi:schemaLocation=“http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd”>
2015-10-01T09:12:17Z
http://www.pasosonline.org/ojs/index.php/index/oai
Illegal OAI verb

Any help will be appreciated.
Thanks in advance,
Juan

2

Hi @jascanio,

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

3

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

4

Hi @jascanio,

Here’s what I’d suggest:

  • Back everything up
  • 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

5

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

6

Hi @jascanio,

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

7

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. :grimacing:
    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
8

Hi @jascanio,

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

9

Hi @asmecher,
Ok, I understand is a lot of things. I’ll start by trying to upgrade.
Regards,
Juan

10

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?

Thanks in advance for your reply.

Regards,
Juan

11

Hi @jascanio,

See e.g. http://pkp.sfu.ca/files/docs/quickreference/quickreference.pdf in the section on backups for information what to include in a backup.

Regards,
Alec Smecher
Public Knowledge Project Team

12

Hi @asmecher,
Ok, thanks for your reply.
Regards,
Juan

13

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?

Thanks in advance for your advice.
Regards,
Juan

14

Hi @jascanio,

  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?

Yes, that’s correct – see docs/UPGRADE for details.

  1. 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

15

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.

  1. Copied my current 2.2.1 config.inc.php file, and public/ and files/ directories into the 2.4.7-1
  2. 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.

Thanks in advance for your help.
Regards,
Juan

16

Hi @jascanio,

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

17

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:

  1. Do you think the above is correct?
  2. If so, will I need to increase php.ini max_execution_time prior to upgrading? (it is currently set to 30)

Thanks in advance for your advice.

Best regards,
Juan

18

Your process generally looks reasonable.

There was a recent discussion which indicated that charset_normalization is probably no longer needed.

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.

The mime_database_path may affect the evaluation of new files uploaded to the server, but this MIME detection will also depend on other server settings. Keep an eye on this.

If you are upgrading through the web interface instead of the command line, increasing your PHP timeouts as much as possible is strongly recommended.

19

Hi ctgraham,
Thanks for your reply.
I have proceeded with upgrading via web.
I get the following message:

DB Error: Duplicate entry 'interest-4096-90' for key 'controlled_vocab_symbolic'

Any idea or recommendations?

Thanks in advance for your reply.
Regards,
Juan

20

This is similar to the topic here:

And I think is already a current conversation here:

Best to continue on one of those threads.