Every site more complex than "10 End" (the original BASIC program) has a vulnerability to bugs. Just ask Bill Gates. Here, we catalog things we've run into, and the solutions.
Well, now, that just had me baffled: all of a sudden the images in the Stingray Dynamic panel disappeared, and the image attachments on the various pages underlying them disappeared, as well. Logging in and out of my admin-enabled account did nothing. Then I tried logging in as "admin", and they all reappeared, only to disappear again when I logged out, or into any other account. That's just plain wierd.
Finally, after fussing with permissions and views and module settings, I simply "cleared views' cache", in Site Building/Views/Tools. Bingo.
Strange, but it fixed it.
I suspect this has to do with some sort of Drupal bug, since during part of time when this display failure occurred I was adding an events page format.
Tom Harrison
In the process of creating a blog entry, we encountered a problem uploading an attachment file -- a 20K .pdf file -- that should have loaded just fine. But it didn't, and Drupal kicked out an error message about it being too big.
The problem was that the error message was wrong. The system was having trouble with the file NAME, not the size. It just didn't know quite what to do with a filename like "M66 and 67 Final Ballot Title Coalition Objections.pdf".
The solution was simple enough: replace the space characters in the name with underscore characters. The upload module accepted "M66_and_67_Final_ Ballot_Title_Coalition_ Objections.pdf" just fine (I added a couple of spaces in the name just for formatting on this page; no spaces were in the name used to upload).
Which begs a second comment: do filenames have to be attempts to set the Guinness record for longest sentence?
Advice: keep filenames reasonably short, and space-free. We don't have to pretend we are using DOS, but we shouldn't pretend that any filename, no matter how complex, is perfectly OK, either.
Tom Harrison
This had me going for a while, for sure. The original title pattern for the Problems and Solutions section was "YYYYMMDD -- Description". I had just finished putting in the entry for pesky files, and tried to edit it. Hmm. The character sequence "-->" was in the upper-left corner of the left side panel, the right side banner items were instead at the bottom of the page, and between them and the node edit area were the administration tabs that are normally on the left side. None of the buttons or links in the edit area worked, although the major menu lines still worked just fine.
So, I used Firebug to examine the the edit screen. Upon mouse-over on the View/Edit/Outline/Revision button region, Firebug revealed that same "-->" sequence right after an easily-found <div> sequence. It turned out that the double-dash in the title was confusing the bread crumb sequence, which was commented out. The double-dash terminated the comment, leaving the extra double-dash as text to be displayed, and totally messing up the rest of the page's interpretation.
Solution: avoid double dashes in titles. Probably a good idea to avoid them in any single-line entries, actually.
Tom Harrison
In the first few days of November, I noticed that the ShareThis links on the site stopped working. A quick look at the Error Console in Firefox revealed the error "shareel is null". Oops. Something broke, and I suspect it was because I allowed an update to happen that contained a bug. After a frenzied search, I found that the Drupal community had discovered that the solution was to step back to a previous version of ShareThis.
Share this should now be working again. You can take addtional steps to customize the ShareThis pop-up. To do that, follow the link to the ShareThis site that is included below the Javascript code window on the Share This Settings page.
After configuring a "view" to support an event calendar for Clackamas County, I posted an event, logged out, and discovered it appeared twice on the "Upcoming" block, but only once in the database. Some sort of permissions issue caused the duplicate to disappear when logged in as an administrator. Very strange.
The solution was to navigate -> Administer -> Site building -> Views -> calendar_event (the name of the view created for normal calendar items) -> Edit -> Upcoming -> Basic settings -> Distinct, and set "Yes".
What appears to be happening is that because there is both a start and end time for this event, there are two distinct date fields to search on and capture. From the database: "18 18 0 2009-12-09 02:00:00 2009-12-09 04:30:00 NULL", while other events had identical dates in both fields. Setting Distinct=Yes forces the view engine to doublecheck that each node is only displayed once for each actual event, not just the found unique dates and times.
Fascinating. I still don't know why that only happened outside of certain permission sets, but "Distinct" fixed it.
All of a sudden, two fields designated <h2> in the right banner area started displaying extra large. Hmm. Code checked out OK on each of them, but they were displaying too large for the area, truncating off the right side. A quick review with Firebug (you did load that, didn't you?) showed that the tags for the fields included the added tag <big>, but the source view of the page did not show that. Instead, the front page teaser for a recently posted article included a <big> tag with no matching </big> tag, because Drupal had chosen to break the article at that point, leaving the <big> tag open for the rest of the page construction.
Boo-hiss. Bad Drupal.
Well, there is a trick to be invoked here: inserting a teaser break FORCE (see the Tips article on Teaser Control). A quick edit of the offending article, and all is well.
Here's lesson 1: when editing, do try to keep the font enhancements for last, lest you accidently delete a trailing tag without knowing it. Not the case here, but it can happen.
Lesson 2: Be sure you check the REST of the page before you call your recent construction good. In this case, viewing the Home page after promoting the article would have revealed the problem.
Lesson 3: Use "<!--break-->" when you need to.
Well, I finally got tired of trying to manage the Dynamic Display slider area by re-editing new nodes to get the order right. We tried resetting the posting date, but it had no effect. So, I dug into the ddblock module to find out why. Simply, there was no option to use the news item fetch from the database without RESORTING it somehow, because there were only three options: random, ascending, and descending, and the ordered sorts were tied to Node ID. This can be fixed, to allow the views module item "news item" to do the sorting, and have the ddblock module leave it alone.
This requires an edit of the script "ddblock.module", but it's not complicated.
For the ORP, we have set the view to sort by posting date, because this is easily modified by editing the news item. Now, in order to "shuffle" the slider display to sort like we want it to, we simply adjust the posting date (the date and time, actually), so that the one we want first has the most recent date. As you might guess, the news item view is configured to sort on Node: Posting date, descending.
I should have done that a long time ago....
Probably nowhere.
Drupal editing is flexible, and stores whatever you enter. The rendering of that content, however, is based upon filtering controlled by the node's Input Format. Edit the node, and expand the Input format item just below the body window. Most pages require Full HTML to correctly format.
Change the Input format, and see if that fixes the problem.
The "CRON" function is a periodic update of modules, used to do things like check for updates and grab news feed updates and such. Fairly important function, that.
Well, the Splash module was interfering with it. A not-too-complicated patch fixed it. I applied it manually, first making a backup copy of splash.module, found in the folder ~/public_html/org.oregonrepublicanparty/sites/all/modules/splash/. I saved the original as splash.orig.module, and made a copy to edit, named splash.cron.module.
In splash.cron.module (version = "6.x-2.6"), I searched for the line:
// We are not on the front page (cannot use drupal_is_front_page here)
Just above it, I inserted these four lines (the second and third line below are really one line):
// We are being called from cron, don't redirect.
} elseif (strcmp(substr($_SERVER['REQUEST_URI'], strlen($_SERVER['REQUEST_URI']) - strlen('/cron.php')),'/cron.php')==0) {
$splash = FALSE;
$reason = 'Must not mess with cron';
Save the edited copy, put both files back into the splash folder, and finally copy splash.cron.module on top of splash.module.
The email servers for ORGOP.Org are not provided by the same service that hosts the web pages, but the web page hosting service doesn't know that -- or even care, for that matter. So when the Drupal structure attempts to send an email to an address in the "ORGOP.Org" domain space, using internal routing, it fails.
Solution: use email accounts or forwarding addresses in the OregonRepublicanParty.Org domain space, which is entirely hosted on the same server as the web pages. From there, any email generated can be sent anywhere else, and the hosting service mail senders get it right.
Unusual to have split hosting for domains, but not THAT unusual.