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?
Np, @RavanH, glad my contribution turned out so helpful!
On a hunch, I instead opted to change Upload Url Path (of the main site) to point to where Fileupload Url already was pointing, and lo and behold, now the uploads get url’s with a /files/ base (which I feel is best).
Funnily, despite this same setting on the testing site, the url’s there have the wp-content/uploads base (like I mentioned in the previous comment), as if Upload Url Path didn’t have an effect. There doesn’t seem to be a Fileupload Url setting there — perhaps it’s deprecated? (The testing site runs trunk, whereas the main site runs latest stable.)
(Usually it’s the other way round: something that works in testing won’t work on the production site.)
I’m chiming in with my experience just in case more reproducers are of any help. I’ve encountered the issue @RavanH described in the initial post on my multisite install: files uploaded onto the root blog get url’s with blogs.dir while subsites (in subdirectories) get url’s without it.
I was running WPMU just prior to it getting integrated into WP proper, but unfortunately I can’t say for sure whether I did a clean reinstall or an upgrade to WP (non-MU) at that point.
I’m only running a single network with none of the plugins mentioned in this thread thus far. Well, no, actually I do run another multisite for testing purposes, completely separate from the first, and there this issue doesn’t manifest.
The upload-related variables for the main site are as follows:
`Upload Url Path:
Upload Path: wp-content/blogs.dir/1/files
Fileupload Url: http://mummila.net/files`
I suspect the Upload Path is what’s causing this; further evidence is that on the testing site Upload Path: wp-content/uploads results in url’s withoutblogs.dir.
I’m thinking of changing Upload Path, but I’m unsure where it ultimately shouldpoint to. If wp-content/uploads results in corresponding url’s, is that the default for the root blog? If so, is there a reason why it deviates from what the sub-sites have, which is sitepath/files? I’d expect the root site to have /files/ as attachment url base.