This is a problem with TinyMCE 3.0. They don’t currently have align attribute working properly, so they’ve substituted float: left; to temporarily solve this problem. “float” is applied to the image using the “style” tag, but the base install on TinyMCE does not come with the option to add style attributes to images, so you have to add it into the list of usable tags using the ‘extended_valid_elements‘ settings.

Achieving this in Drupal is easy: go to the plugin_reg.php file which is located in your TinyMCE module directory. Find the line that says

$plugins['advimage']['extended_valid_elements'] = array('img[class|src|alt|title|hspace|vspace|width|height|align|onmouseover|onmouseout|name]');

and make sure you add |style to the very end, like so:

$plugins['advimage']['extended_valid_elements'] = array('img[class|src|alt|title|hspace|vspace|width|height|align|onmouseover|onmouseout|name|style]');

If you’re using TinyMCE with any other software, I suggest doing a search for ‘extended_valid_elements’ and see if you can find where it’s being defined for ‘img‘. It probably looks very similar to this everywhere.

Problem: I have a website running on a local MAMP install with Drupal and it’s working perfectly. I move the entire site, database and everything, over to a Network Solutions host. Everything looks fine, except when I log into the admin, I get an access denied error. The login works and it takes me to the admin area, but when I click around, I get pages with just content loaded that say access denied. No style sheets, no theming, but it is trying to pull in the content. Which means it’s accessing the database fine. It’s just having some sort of session problems.

Solution: Another one of those odd scenarios where it ends up being something totally simple and unexpected. The new server was using CGI instead of Apache, which, yes, will cause some problems. But this problem was actually related to the immense number of domain names associated with the account. There were about 5 or 6 domain names which all pointed to the same host. Drupal’s admin only lets you resolve to one domain name, and it was picking the first one it found alphabetically. Because the site we were trying to load started with a T and the first domain name on the list started with an E, going to the admin area from the T page caused an error. Going from the E domain was smooth sailing.

I still consider this topic open. What if we really want to be able to do everything from the T domain? Why does Drupal’s admin care what domain you’re reading from? Maybe we can find some answers here.

I recently installed this text-based database user forum for a client using myUPB, my job was suppose to just be changing the template to match their current site. However, as the client started to use the software, we noticed some wonky things happening. Lost password e-mails never got sent, or, when they did, the included URL provided no host name. Just http://?request_ID=1&passcode=20076. Funky!

I did some research into the forum software and poked around the code a bit and found it was using $_SERVER[‘REQUEST_URI]; as well as $HTTP_HOST and other such fun server based variables. After a Google search of said keyword, I found this great blog post by David Walsh.

According to him, the problem could very likely be that the hosting server was IIS. I checked with the host, and bada-boom! IIS was indeed the problem. I implemented his code which retrieves $_SERVER[‘REQUEST_URI] in another way.

I’ll update this post as I work my way through all the other problems having this forum on IIS is causing.