Tag Archive: Drupal


Tonight was the second hackathon. Whereas last time most of the group was working on migrating pages from the old page to the new one, this one was focused more on the coding issues. I was part of the team working on creating the forms to be used to create new pages, which involved creation of the HTML to be put into the Drupal site to provide the form, a PHP page that processed the form data and both outputs the RDF and the Drupal page (if applicable), and some Javascript pages that go along with the HTML. Within our group, I was working on creating the form for adding the In The News instances for the Announcements.

After figuring out how to get onto the server, I grabbed all of the example files that Evan had made for the Presentations creation form and looked at those. I started out by writing the HTML, figuring that was the easiest place to start, since it was just some simple HTML editing by adding the fields needed, which I found out with a combination of exploring the existing RDF files on the server as well as examining the OWL schema file using Protege. After this, I worked on the PHP since I’d need that to test the new HTML, and because I didn’t have write access to the dev site yet to test it anyhow.

At first, it was just some simple editing of the processing to match with the form data in the HTML. I also removed the section of code that created the Drupal page since the announcements don’t have a page of their own. After tracking down and editing everything I thought was needed and getting write access, I managed to get the HTML into a Drupal page. I ran into several issues here because I had not noticed the Javascript files, which were essential for filling in the multiple selection menus (they pulled a listing of the necessary URIs to be placed into a certain element given the URI type, and enabled filling of the selection boxes and autocompletion capabilities on other fields). This turned out to be a pretty simple fix, just needing basic edits to a new javascript file, and the form became functional.

Most of the time was spent on the next part, which was to make sure that the PHP called by the form processed everything correctly. At first, it seemed to be working, since I would submit the form and get what looked like valid RDF out of it. However, there were many issues of some fields not being written to the RDF, which was due to me not remembering to edit the section grabbing all of the GET variables correctly. Throughout this, I continued to try testing this, but I was not able to get the RDF to successfully be displayed on the front page. Evan looked at it and confirmed that the RDF was finally complete (this was 3 hours into the hackathon already…), but ran into an odd problem which was preventing it from being displayed. He tested the RDF by trying to query the triple store for the site to find my RDF file, but although it returned fine when searching for tw:InTheNews, it would not return when searching for tw:Announcements, although InTheNews is a subset of that.

By the time I left, this problem was still unresolved, but at least the form seems to work in grabbing the input and generating the RDF, and we think the error lies somewhere in how the announcements are being generated.

Advertisements

Today was the TWC Hackathon for the upcoming shiny new website, which I came to (although I had to leave early). I had thought I would try to help with the migration of the old pages onto the new site, but I actually ended up doing some debugging for the site. Patrick had started the meeting by listing all of the various things that we hoped to finish, one of which being some issues when viewing the site using Internet Explorer, so I volunteered to look into those.

The known issue was the front page tables exploding, so that was the first thing I worked on. I started out by just looking through the source to get an idea of how the front page was put together. Most of the others thought it was a CSS issue, so I tried to examine those first, trying to look through the various CSS files to see what affected the area, which I had narrowed down to some issue with the sizing of the announcements column. I didn’t really see anything, so I went line by line through the encompassing tables to try to figure out where the sizing issue was coming from.

A really useful note is that, before examining the code, I realized that I wanted to be able to test changes so that I would know more definitively what was broken/how to fix it, since I would be able to test it. However, since we suspected that the issue might lie in the CSS and because the saved copy would not work right without the accompanying images/CSS/etc, I used a trick that I figured out earlier this year for a reason I now forget, which was downloading a page and its attached files without breaking the links so that they still import correctly. To use this method, you need to have access to the wget facility, which is most likely installed already if you use Linux/Unix. You can also install it on Windows, which I had done already.

A brief intro to wget…or at least the features of it that I use. Wget is a really great utility when it has an opportunity to be used (this is only the second time I’ve used it actually…but it is definitely THE method I know to quickly get a local copy for editing). What it basically does is download files from a given URL, but with flags it can do really useful stuff like downloading a site recursively (-r), converting the links to work with the other locally downloaded files (-k), and grabbing needed imports (-p). I just wanted to download the front page so I could edit and test it offline, so I used wget -k -p URL to grab it.

Back to the actual front page work, I eventually figured out that the issue was actually due to an tag, where the image source was actually something like 900 pixels in width, although the page was displaying it at 100 pixels. However, because the tag had no width attribute specified, it was somehow displaying the 100px resized image, but still trying to make the table fit a 900px width space, causing horrible things to happen to the front page. I tried to edit the page myself to fix it, and realized that the code in the back was actually using Drupal to generate the HTML via the .rq query and the .xsl formatting code, so I talked to Patrick and he edited the .xsl file to fix the front page.

Another reported issue was some sort of error with people’s profile pages, but I did not see any issues, so I moved on to exploring the site on IE to try to see if any other issues were present. A major issue that I found was when using the search form. It had a weird issue where the results would display fine if the user was not logged in, but would seem to lose all the CSS styles if the user was logged on. I attempted to figure out what the issue was, but was unable to determine it from looking at the code, and I was unable to test changes to try to find out that way since I could not log-in using my local copy. After talking to Patrick, I submitted a trac report so that it can be resolved later.

While writing that part of the blog, I just realized that this could have been why I didn’t see any problems with people’s profile pages. I quickly checked it on IE while logged on and sure enough, the profile pages have the same loss of information. I guess this means that my suspicion about it being something about the search code was wrong, but it does mean that the error must be something similar between the two, which should hopefully make fixing it easier. Now to go track down my report to append this to…