Go to your Worpdress installation directory, and rename the offensive theme’s directory to something else. WordPress will detect the problem and revert to the original theme. You can then access the blog’s administrative area again.

Thanks to this post.

Today I tried to set it up to work with my Mac. The router is old enough to show OS X 10.3 (I think) support information on how to connect the Mac to a printer attached to its print server. I am on OS X 10.5 and there was one thing that was pretty darn off:
On OS X 10.5 your choices are more limited than on that older version in that photo. The add printer dialog box offers you three options for network connections: IPP, or Internet Printing Protocol – which is used by my router, LPD – a UNIX network printing protocol, and HP JetDirect, HP’s proprietary printing protocol.
Still, my printer would not work and after a while I found out why. The router’s network print server uses a URL such as
http://192.168.2.1:1631/Printers/My_Printer
The add printer dialog only allows you to add a printer by specifying its IP address and port, as well as its queue name. What it does not allow you to specify is what *protocol* to use when using IPP. The result URLs stemming from the dialog look close to the one I needed, but not right:
ipp://192.168.2.1:1631/Printers/My_Printer
If you notice, the URL is now with an ipp protocol prefix. And that does not work because it is simply the wrong protocol. There is literally no way to make this happen, through the ‘conventional’ means offered by OS X – this add printer dialog. I doubt that this is too big of an issue for too many people, but the fact that it used to work in previous versions of the operating system is a bit sad. So how do you still make it work?

A few years ago, Apple took over one of the biggest undertakings of the open source community – making printing on UNIX and Linux suck less. The CUPS project actually achieved that goal and its print server is built into every OS X machine. CUPS, like on any UNIX machine, can handle virtually any common printer on any protocol – part of the beauty of open source. And on OS X you can access its administrative screens (a bit rough but very usable) by going to the URL
http://localhost:631
Once there, you can follow CUPS’ web-based wizard to add a new printer and lo and behold – it offers a network print protocol option of (drumroll), of Internet Printing Protocol over HTTP. Make sure you have your password for the machine to actually complete the printer but once it is added, it appears in the normal, OS X printing screens.

In short – it appears to be an OS X bug or omission, but luckily not something beyond the realm of accomplishing.

Could not find anything to require this in the XMPP specifications for multi-user chat.

Oddness.

UPDATE:
This is apparently the way it is supposed to be according to the XMPP protocol or as explained to me on the Openfire dev boards.

1. After joining a Multi-User Chat (MUC) independently, without invite, I was forbidden (e.g. error 403) from finding out who the administrators or owners of the room were. I could not find anything about this in the documentation.
   The workaround was not too bad: apparently the method getOccupant() allows you to get an Occupant object which does hold affiliation and can report admin rights.
2. In some situations – not sure when yet – the owner of an MUC was able to grant another user admin status by just using his/her nickname, without using the full JID. That is
   grantAdmin("nickname") worked just as well as grantAdmin("nickname@conference.server"). Nonetheless, when trying to use the method getOccupant() as mentioned above, the full JID form worked while the nickname-only one failed.

I am using Smack 3.0.4 and Openfire 3.5.2. Weird.

Google at least claims to have Chrome tested before unleashing it unto the world. Microsoft apparently does not even test its own products. Trashing mercilessly. I know.