I recently wanted to update our install of WordPress to the latest version. WordPress is a fairly easy install, and we could learn a thing or two about application set-up by examining their code. But I recently switched to using subversion to deploy and maintain our install. In just the little bit I’ve used subversion so far, I believe development and deployment of our internal applications would be simplified by employing it for all our projects. Here’s a quick outline of the process, with examples based on my WordPress deployment.
While working on the Benchmarks search I wanted to try and provide a feature I find useful on Google and other search engines: word form expansion (lemmatisation). A little research showed to me that this would require more work than we really should be spending on search functionality. Especially considering that the built-in MySQL full text search capability is sufficient for our needs. So I decided to focus on a feature that would still provide value but require little time: word stem expansion.
I made a few updates to the school reports at the request of the researchers.
- Added a save feature so that packet/item selections for a report can be retrieved at a later date.
- Added the ability to set thresholds that must be met before the script will include statistics in the report.
- Updated tables to reflect changes in displayed information and formatting.
In regards to the above changes, the save feature is of particular note for it inscrutibility. While the technique used to save/retrieve the report setting is adequate, the code to enable this functionality is not well-implemented. Unfortunately, time constraints required a fast, rather than best, implementation.
As modifications are requested this script is getting to be a little harder to work with. The code was created over the course of a week or two back in January. I was able to make quick work of it by using some concepts I initially worked out for summary table generation (and based on discussions with Brian W). While the data is stored in a psuedo object-oriented format, the script itself is fairly linear in design. If more modifications are requested the script may need some rewrites to enable a bit more flexibility.
The number produced by summary table 8 in the items utility were not quite correct. The researchers noted that the means by which calculation of answer selection was performed was not quite as they wanted it.
Luckily table 8 uses a new summary table generation technique I borrowed from the school reports. The data, display, and summarization code is segregated to a certain degree (though not as much as would be preferred). This allows me to update one aspect of the script without having to monkey around too much with other aspects.
The data is currently stored in a data array that is organized to allow for relatively easy access. The summary information is currently compiled inline in the code. While this isn’t ideal, the method used (summary arrays) should allow for better segregation in the future. The calculation of concern is stored in its own function,
answer_selected(). That function includes some basic versioning capability and so I was able to add a new version of the calculation that matches the researchers expectation without changing anything else in the code.
I think a modification of this technique would work well for all tables in the utility and should not require significant investment in development time. As additional tables need work I may investigate adding them as components of the new summary table script (summary_table.php).
IIS can’t find php.ini
I installed PHP on the Windows server today and ran into what seems to be a fairly common problem (BrianW can affirm): sometimes PHP is unable to find the php.ini file when processing web-based content. In my case PHP was installed as an ISAPI filter. I suspect that when using the ISAPI filter PHP must be looking in the in the location IIS is running from, rather than the location of the ISAPI DLL (which is located in the PHP folder).
To address the problem I added a PHPRC environment variable. Now everything seems to work as expected. There are a number of options for specifying the location of the php.ini file. See the PHP documentation for runtime configuration.
IIS returns an error
If you’ve fully set up PHP and configured IIS correctly (including enabling the Web Service Extension) then one last thing to check is the path to the DLL specified for the Web Services Extension vs. the value for the application extension in the web site properties. These should match exactly.
The search upgrades and bug fix have been implemented and uploaded to the development and production servers.
Search filtering by current bm, old bm, prose has been corrected.
Fulltext viewing is now available for each search result (‘fulltext’ link following the truncated text), or all search results (‘Output Format’ menu option).
A new results formating option currently labeled ‘Custom1′ is in the Output Format’ menu which displays the results in table format similar to old BOL search result output.
index.php, bol_search_func.php, bol.js
Jill is working on a new topic (
Processes that shape the earth/Plate Tectonics Version II (PT)) which shares a number of misconceptions with another topic (Earth Science: Processes that shape the Earth / Plate Tectonics (EP)).
Problem: She changed the topic of those misconceptions believing it would be available to both topics. Once she realized this was not the case, she changed the topic back, but the numbering was off.
Solution: She provided me a list of which misconceptions were out of sync. Because adding a misconception involves updating multiple tables I actually had to add the misconceptions through the Item interface and then change the numbering on the backend.
Conclusion: The conclusion is that the conclusion is pretty obvious. This functionality needs to be revised. Changing the topic of a misconception has considerable consequences throughout the Items utility, so I think it may be necessary to add an additional step to this process. For example, have the current topic displayed along with a check box and a disabled/hidden topic menu. Then use the checkbox to enable/disable the menu and possibly some kind of textual warning (“Changing this is likely to break something.”).
Another note is that the ‘code’ column denoting the numbering sequence is not a unique column so we could have the numbering be editable on the interface. Although this could have some duplication complications.
I also found it strange that when submitting a new misconception, there is no notification and you are not redirected back to the miscon list. I found out the hard way that once you submit a misconception you are essentially in edit mode (not Add New Miscon anymore) and any changes made are being made to the record you just added. It wasn’t obvious to me the difference between Add and Edit mode.
As I was meddling with registrant_list_demo.php I found that the demographics were not showing up for any of my test cases. I was under the mistaken impression this data was obtained from an external server, but it is actually taken from a data dump from the nces stored on our server in a database called ‘demographics’ (go figure). The demographics data appears to be sorted by zip code. I am surmising that this data dump is requested from nces after the registration process is complete and an updated list of zip codes has been generated.
I’m sure Mr. Sweeney can provide details of this request procedure upon his return. The demographics script is working fine, but the demographics data is most likely out if date. Cari indicated the demographics data will not be needed for a few weeks.
When I first opened up the register dir I found register.php, review.php and review.v1.php. Based on script and notes in the script the registration and review registration processes were consolidatedby Mr. Sweeney in register.php, but perhaps at one point they were separate. review.php and review.v1.php turned out to be the registrant listing scripts.
This names were confusing so I renamed them to registrant_list.php and registrant_list_demo.php (demographics).
I added a filter (by year) to limit output results. However it is not technically filtering by year. There was already a date limit written into the existing query (2007-04-27, I think) which I used as the start range marker for 2007. The start range for 2008 is 2008-01-01. The messy part is that everything prior to 2007-04-27 is marked as 2006 in the filter when in fact the records only go back to 2007-04-17. I expect to be working on this script again in the near future (see “Updates to field test registrant_list_demo”) at which point I will probably change the filter to just ‘Prior’.
Mostly minor or content changes, not worth mentioning.
Cari did have some concerns about the distribution of assigned topics so I disabled the array_rand() method of topic selection and wrote a function that tallies current registrant topic assignments and selects which ever is least.