“Contains characters not allowed in the key”

Wow, sorry about that… it’s obviously not supposed to do that. It should only affect the new one and give you the form again in a state like where it was before you put in a bad key.

I’m looking at the code to try to figure out what happened. I confess that it always takes me longer than it should to read and understand my own code when I haven’t worked on it for a while.

Questions:

1. Are the old queries and their keys still in the form? Asking so you can copy them somewhere as backup if in the worst case you have to regenerate them.
2. What was the new key? Need to know if I should add some characters to the whitelist
3. If you open a new browser tab/window and call up the settings form again does it give you the same mess of error messages? Are the old queries gone?

All my old queries are gone. I hadn’t even tried adding the new key yet. I went to the page to do that and all my old, previously functional, queries are just gone. All of the keys were simple alphanumerics, and all of the queries associated with them were generated from functional PubMed searches.

I have attempted reloading and clearing my cache and whatnot with no change.

• This reply was modified 5 years, 6 months ago by moeuf.

That’s terrible.

Unfortunately, I can’t reproduce the problem on my test site without more information about how it happened.

Looking at the code, which is in settings/query_form.php the error message you are getting happens when php compares a “sanitized” version of the key with what was input. It should not be evaluating true for alphanumerics, although it doesn’t like periods in the current version. But it looks like it thinks it’s seeing non-alphanumeric content, which is really weird.

Once it’s getting a false positive for each old key, it’s deleting that key-query combination from the list when you submit the form. But I’m mystified about why it could think there’s non-alphanumeric in your alphanumeric keys.

Am I correct that you are seeing the old keys in the form next to blank text boxes?

No, I’m not seeing the form at all – literally just a big block of text with no line breaks that lists all the key errors.

OK, that makes sense. I assume you are still seeing the new key entry field and the Save Changes button below the errors.

Yes, but attempting to enter a new key appears to do nothing.

What is your setup like @moeuf?

Is it something where you have control the server or is it a on some kind of hosting service?

I’m wondering about whether you’d be able to test some things if we can work out a way for me to get test scripts or code snippets to you.

Do you do github?

Unfortunately it’s a managed server, run by university IT. I can probably to convince them to do some testing next week, though.

I’m now seeing this on our shared host but not on my local machine.

I just tried to make a new release. Unfortunately, while it seems to work on my laptop, it is failing on the hosting provider where I see the problem.

My hosting provider’s tech support was able to set me up to where I could see a compile error in the regular expression that prevents SQL injection for the keys. Not sure why this only happens on some hosts.

Should be fixed in 1.41 but the preexisting queries will be lost. You may be able to find these in the wp-options table for the wordpress site by searching for options with the name matching ‘wp_pubmed_reflist’ The queries are buried in the data structure of that entry if they have not been previously lost.

Thanks for the update! I’ll have our IT guys install the update and see if they can dig out the queries.

Update seems to have fixed things – thank you! Still waiting to find out if my queries can be salvaged, but at least I can start filling in the critical ones again.