Neatline bug in 2.6.2? (Records no longer displaying in published exhibits)


#1

Hi! An Omeka project we have on university servers recently upgraded Omeka and Neatline (Omeka to 2.7 and Neatline to 2.6.2). We had several Neatline exhibits created in Neatline 2.5.1, and in the latest version of Neatline:

-the base image layer is no longer the default layer. This seems to be an easy fix: it just looks like the Neatline upgrade overrode previous default settings and things were fine once I changed the Default Spatial Layer to “None” (which privileges the image layer). Just wanted to document that here in case other folks working with Neatline exhibits with image layers had noticed a change on the view of their projects. Additionally, when I’m in edit mode on exhibits, the image layer is not the default layer in this view, so I have to click to swap in the layer (minor thing, but seemed worth noting).

-The bigger issue: the records I created for these exhibits all still exist and are visible in edit view, but they are no longer visible in the public-facing versions of these exhibits. Any ideas why they might not be visible any more?


#2

Hi Jim,

Thanks so much for reporting this. I’ll get the info to the development group asap.

Ronda


#3

Thanks! Happy to provide more context if this doesn’t seem like a bug and has more to do with our particular Omeka/Neatline setup.


#4

Hi Jim,

Just so I understand:

  • You were running a site using Neatline 2.5.1. This site included exhibits that uses a static image as the base layer;
  • When you upgrade to Neatline 2.6.2, the value for the Image Layer field is removed? Is it still there, but not being used?

There isn’t a way to set the Default Base Layer to None in 2.5.x or 2.6.x. So I’m wondering if that was possible in prior Neatline versions, and something between 2.5.x and 2.6.x changed that introduced a bug we didn’t know about.

I’m going to see about replicating this locally, and if I find more I can report back here, or you can follow any subsequent conversations on our Github issue that Ronda posted

Cheers,
Jeremy


#5

I just pushed up a bugfix branch that I should address the second bigger problem you describe. Seems I managed to avoid the SQL injection and improperly write the GEOMETRY query in the process. The branch is here:

If you can check out the branch and confirm it fixes your issue, I’ll tag a 2.6.3 release with this patch.


#6

Thanks Jeremy! I’ll pass this info along to our library contact (this Omeka instance is on their servers) and see if that does the trick.


#7

Hi Jeremy! Yes, that branch fixed the issue! Thanks so much for your fast response and your attention to this bug!