It looks like 1.6.1 now automatically adds a rel=”slb” (plus some slb_group) to image links pointing to url’s ending in a known image postfix. While a nice idea in theory, this does not work well with links pointing to non-image content that ends in an image postfix.

Steps to reproduce:
1. Create an image link pointing to a picture page in Wikimedia Commons.
2. Try clicking the link with SLB activated.

What happens:
SLB tries to lightbox the Commons page.

What I expect to happen:
I’d expect SLB not to mess with the link so that when I click the image, I’m taken to the Commons page as usual.

Other notes:
I don’t think there’s any way around this other than disabling the automatic rel=”slb”’ing feature entirely (which the plugin currently, AFAICS, doesn’t allow me to do). There’s no reliable way to determine a link *really* points to an image just by looking at the url.

Aikoinaan kun Squeezeä Lennyä testasin, tuota hidastelua aiheutti se, että Nautilus (tai jokin) halusi nuuskia verkossa näkyviä Windows-verkkokansioita. Sen keksittyäni sen estäminen oli helppoa, mutten kyllä enää kuollaksenikaan muista että miten.

Edit: Taisi olla niinkin vanha kuin Lenny se jota testasin.

Yksi helposti kokeiltava niksi on ottaa laitteistokiihdytys (Hardware Acceleration) pois päältä flashin asetuksissa. (Mikäli sillä ei ole vaikutusta, se kannattanee palauttaa takaisin oletusasetukseen.)

Mitenkä on, onko bugien raportoinnissa syytä olla tavallista harkitsevaisempi näin varhaisessa vaiheessa kehityssykliä (ennen feature freezeä)? Järjestelmähän on tässä vielä liikkuva maali, eli bugeja tulee ja menee jatkuvien muutosten myötä joka tapauksessa. Vievätkö bugiraportit tällöin kehittäjien resursseja turhaan, vai olisiko ongelmat päinvastoin hyvä raportoida mahdollisimman pian, jotta mahdollisimman monta myös ehditään korjata ennen julkaisua?

Solved!

On the ’Advanced’ page of the BIOS, there was a switch for the Onboard LAN Boot ROM, and by default it was set to disabled. I switched it on and can confirm that ATASX works on this board.

I now see the ATASX documentation does make a mention of this in passing, saying ”you have to activate the ability to boot from network card”. So this was a simple case of RTFM on my part. :)

I’d still be interested to know how if at all this’ll work with an SSD.

I’ve been thinking of getting an SSD with built-in encryption, such as the Kingston SSDNow V+ 100E Series. From what I gather, utilizing the encryption would require that the BIOS supports HDD passwords. This is what lead me to ATASX.

My current motherboard is an Asus M4A78-EM with the latest available AMIBIOS for it, revision 2101.

For all appearances, I’ve successfully configured the ATASX.ROM module for my setup, managed to embed it into the main BIOS ROM using mmtool, replacing the existing PCI ethernet module (10EC:8168) with it and flashed the resulting ROM file into my BIOS chip.

Yet, during the boot, there’s no indication that the extension is in fact there: the prompt for security setup doesn’t appear and, when listing the harddisks, POST doesn’t say anything about the security extension as it does in the example images.

Did I read the documentation wrong when I thought this method didn’t involve burning an EEPROM? Have I made some error in the process, or is it just that the AMIBIOS for this motherboard somehow isn’t compatible with ATASX?

And in the end, would even having support for ATA security enable me to utilize the built-in encryption on modern SSDs? I only came to think of this when I read in another thread there’s a user with an SSD for whom ATASX apparently doesn’t work (if I’m reading the Google translation right).

Is it just me, or do the plugin’s settings get reset back to defaults with each update? Is this intentional and if so, why?

Nvm, I got in. It just took 5 minutes to happen. And it seems to remember the credentials now that they work.

I installed the new Facebook app, but I can’t seem to be able to log in with. It just hangs there on the login screen trying to connect (”Loading…”). This is on a Nokia 6220 Classic.

With the old Snaptu I’m still able to login to FB just fine.

Another issue: when I cancel the login and exit the app to try again, it doesn’t remember the login credentials I’d entered earlier. Typing the 160-bit password on a cell phone is arduous so I wish the app would remember it. I also wish it would remember which connection I want to use since I only have one on this phone and asking about it is therefore in vain.

Apparently either results.php or head.php (in view/admin/) refers to an image called small.gif by a path that doesn’t work: every time I use Search Regex I get 404 hits for a ’/images/small.gif’, when it should in fact refer to [site root]/wp-content/plugins/search-regex/images/small.gif. Apparently $this->url() precluding the path in the code doesn’t work — maybe $this is out of scope?