Simple Refinements

Search Refinement

While working on another application, the good people at University of Notre Dame Press pointed out that searches for "Garces" and "Garcés" were returning different results. From a "technical" stand-point this is understandable; The é is a different character than the e.  However, not everyone will know that María Antonia Garcés has two diacritic marks in her name.  After a bit of communication with Tom Lehman at the Hesburgh Library, Tom was able to point me to the entqr parameter. In layman's terms (pun intended), the entqr=3 option means that each letter with a diacritic is treated the same as it's "base" letter; So e, ê, é, and ë are treated as e (e.g. "Gårcés", "Garces", and "Garcés" will all return the same results). Needless to say, this was also applied to Conductor.

Improved Data Portability

In our ongoing effort to provide greater data portability, I've went ahead and added JSONP support for pages, news, and events. This will allow you to fetch data out of conductor via JSON and make use of it in your own javascript application.  Simply request the page with a callback=variable_name parameter, like so http://conductor.nd.edu/home.js?callback=variable_name.

Change in Request Routing

When Conductor receives a request to a URL, it goes through a list of options on what to do.  In some cases there are URLs (e.g. /admin/login, /news) that are not dynamically determined. In other cases, Conductor looks at various components to determine what to show, looking at pages, uploads, specific events, and lists redirects.  All fairly common stuff for a content management system. This update brings a modification to this routing scheme.

Prior to the change we had the following order of execution (there is more going on but for the example's sake, we'll use these 4):

1. Static URLs (e.g. /admin/login)
2. URLs that match a specific pattern (e.g. /news/1234-article would render news article 1234) 
3. URLs that match a redirect (e.g. redirect /from/here --> /to/there) 
4. URLs that match a page's URL (e.g. the Contact Us page is at /contact-us)

After the change, the order of execution is:

1. URLs that match a redirect
2. Static URLs
3. URLs that match a specific pattern
4. URLs that match a page's URL

But Why?

Why make the change? Quite simply, we want to allow greater customization for URLs, and this can most easily be done by pushing the Redirect check to the front of the line.

Navigation Caching

Prior to this update, the administrative navigation was dynamically generated with each request, when in reality, the left navigation information changed so very little. So I have added some functionality to cache each user's left navigation (i.e. the Pages, Uploads buttons).  This cache is cleared whenever anyone on the site updates anything in the admin; After all if you are granted new permissions by someone else, you should see them when you refresh the page.

But Why?

This is part of my ongoing effort to address potential latency issues.  By itself this update may not help all that much, but each little improvement helps.