I have found another issue with search that is related to my earlier post. I have found that the search function, which used to search all of my albums now searches ONLY the albums in my slideshow album set. I have three other album sets - Fishes, Invertebrates, and Videos (a total of 31 albums) and the search is no longer returning ANY results for these other three. The album sets are in separate folders in my web site (needed to keep URL length reasonable). I have verified that only the Sideshow album set is being searched by searching for terms that occur only in one or another of these and not in my Slideshows set. I would appreciate ideas on what may cause this and how to fix it.
If I can fix the above issue, I will use my 45 years (yes 45) of experience writing SQL queries to customize the search results myself. For this, it would be helpful to know where the search query is housed and named. Thanks
I have been working the problem and have found the major issue was related to a database corruption. I have cleaned the database and reloaded data and all album sets are now searched.
I also found a second issue that is completely specific to my site and its customization. Searches of my single image pages do not return all the information in the displayed page. This is because some of the text on those pages is served through a phplugins insert of formatted data taken from several metadata fields and Backlight Search does not pick this data.
I figured out from the various descriptions of the search function that pages and single image pages are searched differently and this is not explicitly stated in the limited documentation. It appears that the full text on pages is included in the search, but for single image pages the search includes ONLY data that is contained in the title, caption, filename and keywords metadata fields and not in anything else displayed on the single image page. If this is correct, it would explain why some of my searches do not find images in my non-slideshow single image pages. However, that data is picked up by search in my single image pages for slideshows because the relevant metadata is fed into the field whereas on my other single image pages it is fed in through the which is not searched.
Now that I have figured that out I should be able to solve the problem by feeding the relevant data into one of the four metadata fields that are searched. I have not figured out how best to do that yet and will not have time for a few days at least o find the best option for doing this either in Lightroom or phplugins or both.
Replies to my earlier post were very helpful in pointing me where to dig for the source of the issue - Thanks to all for this!
Again, search operates on data stored in the database, within a particular schema; not what’s displayed on the page. By that logic, your PHPlugins additions will not be searchable.
For anyone who wants to have search apply to several metadata fields that are not included in the search locations identified by Matthew, here is how I did it using the Backlight album template and css.
First, I loaded all the metadata tokens for the fields I wanted to search into the Captions field of the Album template. You can add several tokens, in my case 6 metadata fields that I wanted searched. In order that this long string of metadata does not show up as an image caption I used css to make figcaption hidden. That it. Simple and functional.
There are some other things that can be done if needed. For example, if you need an actual caption for your single_image, you can add that through the metadata panel (use a metadata field other than caption for this). Also, if you want to display metadata on single_image page you can do so. I have done this on my site using the same tokens that I had inserted in the Caption field to get them searched.
Finally, although I have not fully implemented this yet, I believe the Caption field can be used to prioritize certain albums in the search protocol by simply repeating the same token in the Caption field for higher priority albums. This should result in duplicate hits on any search term that appears in one of the tokens and, since the search protocol claims to prioritize by number of hits within a given page this should give the higher priority album a boost in search prioritization. Note that I have not positively confirmed this search strategy works yet as I don’t need it for the vast majority of searches performed on my site since the almost all searches result in few hits.
Not helpful. Better documentation might help, especially for those who do not want to implement things exactly as TTG envisions a web site must be. I can certainly evaluate a search protocol, presumably an SQL query, if I know where to look for it.
As the author of the search I thought it best to clarify that point and save you the time to try to implement repeated terms. I would consider that helpful.
Yes, I have seen that file. In fact, that information (with corrections) has been on my search page for the last week or so. My predisposition for better documentation comes from my experience in designing, managing and administering data bases and complex scientific data extraction, analysis and presentation programs to use that data. I started back in the old days with algol , fortran and punched paper tape data entry (yes, I am that old) and have progressed to administering and managing databases that are many orders of magnitude larger and more complex that any that Backlight will ever use (my Backlight site may be one of the larger ones 13,500 pages and counting). The worst mistake I encountered over and over again in my long association with data management is the lack of documentation, particularly when programming language, programmers, and database sophistication has moved from one decadal step to another.
BTW. The Backlight search function is now pretty slow and I believe much of the issue is the structure of the database (page generation time is also relatively slow). Designing a more efficient database structure should probably be somewhere down your todo list.
We need to take a step back and think about what Backlight really is. As per our product page, “Backlight is a unique website creation and photo publishing platform, allowing photographers to create, manage and personalize their online photo galleries.” This isn’t a tool for hosting large volumes of data. It’s not a tool for fine-grained and performant searching of large volumes of data.
I can see where you’re coming from. I too have a background in large and complex data sets*. My day job is for a tool that selects and transforms data from hundreds of tables with millions of rows and returns results to hundreds of concurrent users in a matter of seconds. But that system is entirely different in its purpose and nature to Backlight.
(* of course, what one person considers large and complex may be considered as trivial to another. The sky is the limit with data.)
The data structures in Backlight are kept fairly simple. The design has been carried through in various forms from entirely different back-ends, from CE2 to CE4, and Backlight 1 through 4. We’ve provided upgrade paths across those different versions. So for legacy reasons, it’s kept simple and compatible. The performance issues you’re encountering are likely scalability issues from our use of SQLite. We love SQLite, as it provides a robust and efficient way of searching through photos for the use case that Backlight is designed for. Most importantly, it provides a zero-config way of providing a backend database. The common Linux hosting database of MySQL is not something we want our customer base to deal with and not something we have the resources or inclination to support. But, as you’ve found, SQLite does not scale well to large amounts of data.
Similarly, search is kept simple. It does what it needs to do for a photography website. This is reflected in the provided functionality and accompanying documentation.
I’m not suggesting that it can’t be improved, but that your use case is pushing beyond what Backlight is intended for. It’s closer to something that would be better handled by a bespoke system tailored to your specific needs.
Hi @dsegar, this may be of interest to you. We have increased the search scope to include all metadata fields. This included the Outlets set in the template and the values for the Metadata Panel.
This will be released in the next feature update.