zeroed down

Today was the rarest of programming days. My headphones were on by eight a.m., and while the code didn't flow, the ideas did; when I next looked up, it was after one p.m. I zeroed down on the section of code I had my suspicions about, and started testing, line by line. The book clubs problem eventually presented itself as a three-headed beast.

The first problem was the one I expected; having seen a similar array problem on another page, I knew what to look for, and it was easier to isolate this time. Once I corrected the inconsistency, information began flowing. Just not all of it that I needed.

The second problem I had also seen before, but I still don't have an answer for it. There seems to be a problem -- likely, a collision -- between the Thyme calendar and drupal whenever the $_cur_cal variable has been brought into play. When methods involving the $_cur_cal variable are brought into play in standalone pages, they work beautifully, but when used in a drupal page, the code dies silently every time. I don't understand why, but in both instances, I have been able to create a workaround by building a smart little query to the database that brings me all the results I might need.

I might not know how to lock the trapdoor so I don't fall into it, but I have figured out how to walk around it.

The third problem is a .htaccess problem. It should have been the simplest of the three, but my ineptness with regular expressions has caught me off guard again. Every time I encounter a problem that can be solved by regular expressions, I learn a bit more about how they work, but I am a slow and fitful learner. They are alchemy and pixie dust, and they don't always work the way I need them to work.

The page in its current incarnation contains links like this:


Click on the link and the page continually reloads itself, and provides year and month information to build queries from (end result: shows book club information from that year/month combination). The problem is that I can't do this directly in drupal, and it requires some rather obfuscated workarounds. The logical option would be to build a new URL like this:


The problem is that you can't do that through drupal alone. Drupal's URL aliasing system doesn't let you use wildcards, and I refuse to add in a new alias for every month and year combination -- that's a very wrong-headed approach. Since you can't say "if it starts with /bookclubs/ followed by a six-digit numeric string, do this..." you have to resort to a regular expression in the .htaccess file. I have to take all of the requests that match that pattern and route them to a single page, something like


The end user never sees that address -- all they see is what they typed. On that page, I then use $_SERVER['REQUEST_URI'] to pull out that six-digit number they typed, squish* it into the format I need, and show the books the book clubs read for that month/year combination.

Once that is solved, the book clubs problem-in-three-parts is solved. I can build the end-user's pretty links, insert them into the menu system, and move on to the next architecture problem. I've promised myself that I'll save the look-and-feel questions for last, and that I'll sit on my hands and refuse to tinker with the look until it's time. Bones before skin. Structure before surface. Build it correctly from the start, and the rest is just window dressing.

The frustrating thing? I may not be able to finish this tomorrow, or anytime this week. If a certain vendor comes back with a usable quote on a print project, I have to drop everything and work feverishly on that project until it can go to press. The web project, although it is the overarching issue, has to let the print project take precedence.

Assuming I get the .htaccess issue sussed* out, that puts me one major step closer to full beta. (Fingers crossed that the potential solution Adam sent to me via SMS fixes the logjam.) I've got just under two months to my totally arbitrary and self-imposed deadline.

We'll see.

* Technical terms.

all tags: