I just upgraded to 2.5.1 from 2.3 and am getting the message that “items/show/1605 is not a valid URL” on the item (or any item). I had some problems initially, first the “upgrade database” message and then broken links on the admin page – this was because the htaccess file did not copy over properly, so I re-added it. I also tried deleting it and adding the new htaccess file. In any case, neither one seems to work. Is the best option to try and again from scratch to upgrade or is there something else I need to try?
Can you see them on either side (admin or public)?
Wait nevermind. YEs I can see them on admin side (but not public).
Is there a difference between the way the admin and public side handle URL rewrites? I don’t really have a clue as to where to look for this. The htaccess file seems to clearly be working for most the site. Why would it not work for handling the item public display?
I’m also unable on the admin side to get Item Type Metadata- Text to load (so on either side it won’t show the text of an item stored under ITM - Text in the database), but I was having that issue before the upgrade. I doubt they’re related though.
The simple question: are you logged in when viewing the public side items? “Not a valid URL” is an expected error for going to the page for a private item if you’re not logged in.
Still no luck, I’m going to try tomorrow… am I going to run into any trouble if I just get rid of the upgrade and go back to 2.3.1? I had to choose to upgrade the database when I installed 2.5.1, but I’m running into so many problems that it’s not worth it.
Definitely logged in as super user / admin.
@jflatnes just a quick question. I’m thinking of just restoring the backup I have of the site from last night. I think it will be faster than dealing with the mess of the files at this point. Do I also need to run a backup of the database, was there something changed with the “upgrade database” button I had to choose to install 2.5.1?
Clicking “upgrade database” definitely changed the database. You’ll want to restore to a backup from before the upgrade if your plan is to downgrade.
Alright. Maybe I’ll hold off. I am just really frustrated at this point - I am not sure why the item URLs aren’t showing and the Item Type Metadata - Text never shows (including on the admin page). Is there really nowhere else I can check? The old site worked fine with the URL rewrites. Is there a global setting somewhere that handles the show.php rewrites???
Also, I don’t know if this makes a difference, but I can see all files I’ve uploaded and the PDFtoText text on the files from within the admin. It’s just the ITM - Text that refuses to show up. I attached a screenshot in another post earlier. Our site is pretty much a heavy text site, without that field it’s pretty worthless.
I did a total wipe of 2.5.1 and then started over, following the codex instructions for upgrading very precisely again (but this time replacing only db.ini, files, themes, etc and leaving plug-ins as deactivated for now). I end up with EXACTLY the same problem: is not a valid URL and ONLY when I’m on the public side navigating to show.php for individual items.
Meanwhile, I have the old omeka (2.3) in another folder (just changed db.ini to use an old backup up copy of the database). That one has no trouble showing the item.
Is this a server issue? Is there a setting somewhere in the omeka database this is amiss? If so, where do I check? I’m at a total loss, and I need this to work.
Can someone tell me what changed in the database upgrade? @jflatnes @patrickmj I don’t see it in the release notes but maybe I’m looking in the wrong place?
To give you some more details. Accessing omeka/collections/show/10 works. So does /omeka/items/browse/. It seems it is JUST /omeka/items/show that does not.
Also, I’m still having the ITM problem with Text. When I select “Text” from the dropdown, all I see is “Original Format” and not “Description.”
Ok this is definitely weird… I took a look at the backup of the database on the backend from Oct 2 and noticed that in the omeka_item_types_elements table that there was an important row missing in the upgraded database (namely, the row that gives ITM - Text the text descriptive field). So I added it back:
Now the field shows up under ITM - Text in the admin panel. However, it still refuses to display the text.
Meanwhile, in the old version of Omeka in the other folder, I changed the db.ini to the Oct 2 backup copy of the database and voila, everything works perfectly again. No “is not a valid URL” messages, no missing text data.
I still would rather us upgrade and use 2.5, but perhaps I should start by using this older backed up copy of the database before things went awry. If I do that, then I presume I will be prompted again to upgrade the database. If it doesn’t work then I guess I’ll reinstall 2.3.1.
As a side note, can someone tell me where the ITM - Text on each item should be pulling from, i.e. where’s the code that pulls it from the database? I need to check the fields.
All the element text displays work from the same code. So, there’s a couple different ways that Dublin Core gets output, but they’re the same ways that Item Type Metadata get display. Depending on the theme, that might be the metadata() function, or the all_element_texts() function, which relies on the allElementTexts() helper function in views.
Another common trick for hunting down mysteries like this is to see if a plugin is doing something odd, so disabling plugins and checking results is a possibility.
Could you give a full, live URL to one of the offending pages?
@patrickmj @jflatnes Unfortunately it’s password-protected, but that was never a problem (and still isn’t) with the previous install. Anyways, here’s the screenshots, one from admin page (works) and one from public page (doesn’t).
Same item, public:
Any reason why one would work but not the other?
I took a look at the htaccess file and there’s nothing special so far as I can tell, but I am not a rewrite guru, that stuff is a bit of a mystery to me:
# Omeka .htaccess: Apache configuration file
# This file is required for Omeka to function correctly.
# --------------- #
# Error Reporting #
# --------------- #
# Uncomment the SetEnv line below to turn on detailed on-screen error
# reporting.
#
# Note: This should only be enabled for development or debugging. Keep this
# line commented for production sites.
#
SetEnv APPLICATION_ENV development
# ------------- #
# Rewrite Rules #
# ------------- #
RewriteEngine on
# If you know mod_rewrite is enabled, but you are still getting mod_rewrite
# errors, uncomment the line below and replace "/" with your base directory.
#
# RewriteBase /
# Allow direct access to files (except PHP files)
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule !\.(php[0-9]?|phtml|phps)$ - [C]
RewriteRule .* - [L]
RewriteRule ^install/.*$ install/install.php [L]
RewriteRule ^admin/.*$ admin/index.php [L]
RewriteRule .* index.php
# -------------- #
# Access Control #
# -------------- #
# Block access to all .ini files.
<FilesMatch "\.ini$">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</FilesMatch>
# --------#
# Caching #
# --------#
# Uncomment the lines below in order to enable caching of some files
# (after a finished site has gone live)
#
# <IfModule mod_expires.c>
# <FilesMatch "\.(js|ico|gif|jpg|png|css)$">
# ExpiresActive on
# ExpiresDefault "access plus 10 day"
# </FilesMatch>
# </IfModule>
# ------------ #
# PHP Settings #
# ------------ #
<IfModule mod_php5.c>
php_flag register_globals off
php_flag magic_quotes_gpc off
</IfModule>
If you turn on debug.exceptions in your application/config/config.ini file, the 404 page should show a more detailed error message.
Yikes… thanks, just did that… got a really nasty Zend error. :x It begins as such:
Zend_View_Exception
script 'common/partial.php' not found in path ([domainpath]/httpdocs/omeka/themes/seasons/:[domainpath]/httpdocs/omeka/application/views/scripts/:
And that goes on for a while…