denyerec.co.uk

I love my D800. Admittedly not as much as my Fuji, but it’s a great machine to work with. For a while now since getting several gigs as a Poledance Photographer I’ve taken to shooting tethered via Adobe Lightroom. Now, due to not being able to afford a fast laptop (D800’s are expensive…) I make use of a loaner machine, a rather lovely Dell XPS15 (2013 model). Prior to the Windows 8.1 update everything was running smoothly, but after the jump, the D800 stopped working.

On connecting the camera you’d hear the “USB Device Connected” chime, but it would only display in device manager with a yellow /!\ exclamation mark and would not show up in windows explorer. In device manager the camera would show up as a code 28 “Driver not installed”. I knew there was an issue with the MTP driver, but couldn’t get Windows to “forget” the device to install a clean version. Nikon blamed Adobe (And in fairness, verified my exact setup on their own machines as working), Microsoft blamed Nikon and asked for $99 to remote desk to the PC to investigate it, and Adobe? Well, it turns out Adobe don’t DO customer service. They have a “user forum”, where you can sit and wait for the wind to answer your questions and that’s about it.

I wouldn’t be blogging this if I hadn’t fixed it, so what was the fix?

1. Disconnect the camera, run USBDeview and remove the camera from here. You should see it listed as a not connected Nikon D800.
2. Install the MTP Porting Kit. I’m not sure if this is required, but I did it anyway. Reboot.
3. Reboot into safemode, then run “sfc /scannow” at the commandline
4. Reboot normally, then reconnect the D800. You’re not done yet, as if you have my issue, it will still be registered as a code 28.
5. This is the important step. In device manager, open the D800 then “Update the Driver” for the D800, and select “Browse my computer”. Select “Let me pick from a list”, then scroll down looking for “Portable Devices”.
6. (If you don’t see this, hit “Have Disk” and point it at c:\Windows\Inf\wpdmtp.inf )
7. Now select (Standard MTP Device) from the left column, and MTP USB Device in the right. OK everything, even if you get warnings.
8. Reboot. Hope for the best.

If you’re lucky, the MTP driver will now install correctly. What I think is happening is the MTP association failed originally and it was impossible to “purge” the driver associations from Windows. Forcing the issue by convincing it that it really is an MTP USB Device seems to work.

Bizarre? Yes. Frustrating? Immensely. Resolved? Yes.

As a bonus tip, if you have trouble with Lightroom not detecting your D800, open Lightroom and go to File->Plugin Manager – disable the Leica and Canon tethering plugins if you don’t need them. I found the Leica tethering application was firing up and blocking the Nikon one from detecting successfully, your mileage may vary.

An additional bonus tip, sometimes killing the tether_nikon.exe process in task manager can encourage LR to gets its act together and play nicely. Sometimes.

You might find yourself wanting to install Bug Genie, or some other such newfangled toy onto Ubuntu 10.04 “Lucid”.

You might find yourself stonewalled at the suggestion that your PCRE version (7.8) doesn’t meet the minimum requirements of 8.x

You might then have found yourself here.

The solution is thankfully straightforward. Just add the precise pangolin repo temporarily to your apt sources and install via apt.

sudo nano /etc/apt/sources.list

Comment out all the lines by placing a # at the start of each one. Then add the following to the end:

deb http://archive.ubuntu.com/ubuntu precise main restricted universe multiverse

Ctrl+X then ‘y’ to save from nano, then do:

sudo apt-get update
sudo apt-get install libpcre3

Then go back and restore your apt sources.list to its former state, and run apt-get update again.

If you’re using TYPO3 along with the jolly-lovely FED/Flux templating system then you may well have tried to make an FCE preview in the backend that includes an image preview.

Here’s where I started:

{namespace fed=Tx_Fed_ViewHelpers}
{namespace flux=Tx_Flux_ViewHelpers}

<f:layout name="FCE/Photo" />
<f:section name="Configuration">
	<flux:flexform id="photoConfig" label="Photo Configuration" enabled="TRUE">
		<flux:flexform.sheet name="photoDetails" label="Photo Details">
			<flux:flexform.field.file name="photoFile" internalType="file" allowed="jpg" maxItems="1" showThumbs="1" label="Selected Photo" />
			<flux:flexform.field.input name="altText" label="Image Alt Text / Title" />
		</flux:flexform.sheet>
	</flux:flexform>
</f:section>

<f:section name="Preview">
	<f:image src="{photoFile}" height="80" alt="{altText}"/>
</f:section>

However, this doesn’t work out so well. A quick showed that the returned image resource path was relative, such as:

../typo3temp/pics/d2d39d7307.jpg

This ain’t gonna work as we’re in the BE context and I wasn’t able to fool it with any number of ../../ attempts as it always resulted in a Resource Not Found error.

The solution? FED includes an Image viewhelper (Docs) that’s crazy powerful, BUT, and here’s the important part, it renders the resulting image resource out with an absolute path, making it useful in both FE and BE contexts.

The result?

<fed:image src="{photoFile}" height="80" alt="{altText}"/>

Job done.

Update:

Code snippet from Floxx:

<f:section name="Preview">
	<img src="<v:format.replace substring=".." content="{f:uri.image(src: '{file}', height: '50')}" replacement="" />" />
</f:section>

While we’re on a roll here, how about removing the ridiculous inline styles from Blockquote tags, and allowing your custom CSS classes to hold their ground?

This one is buried right inside the bowels of the CSS Styled Content standard TypoScript, you can knock it on the head here:

lib.parseFunc_RTE.externalBlocks.blockquote.callRecursive.tagStdWrap.HTMLparser. \n
  tags.blockquote.overrideAttribs >

The above should appear on one line, without the \n, that was just to fit it in the code window without a scrollbar. I’m pretty confident this is a very very legacy bogeyman that no-one has bothered to clean up, due to the relatively small user-base that requires customisable Blockquotes in the RTE. Either way, now you know.

When configuring the TYPO3 RTE, it’s a common requirement to restrict the tags available to the editor. The RTE has dropdowns for block types which, by default, contains everything from p, through h1…h6, section, aside and so on… Not good news if you’ve got creative editors.

Removing these involved digging into the source here http://typo3.org/api/typo3/class_8tx__rtehtmlarea__blockelements_8php_source.html to discover a seemingly undocumented property in the RTE.

You can set this up as follows in your Page TS:

RTE { 
    default {
        buttons.formatblock.removeItems = h1,h5,h5,pre
    }
}

If anyone finds this, and wants a more detailed guide on adding and controlling the custom classes in the RTE, just shout loudly in the comments! Best of luck keeping your editors under control 😀

UPDATE: Also, watch out to make sure you’re reading the most up to date version of the RTE manual… DOH. I was reading an outdated one, which did not document the above. The current RTE manual can be found here, and outlines this feature. Always watch out for that, the Typo3 documentation can be a bit of a maze!

Just recently I’ve been plagued by an issue with a Magento cart checkout performing slowly between stages 5 and 6 of the standard one page checkout process. Some bad code in Magento’s core helped reduce the delays (Loop limit counters that are initialised INSIDE the loop? Hello?), along with judicious increases to DB and PHP cache sizes. However the problem remained, leaving me with a 6-10 second delay (Down from 15-20 I must add) when hitting the final button in the checkout to head off to the payment gateway of choice.

The culprit?

An open_basedir directive in the http.conf file for the VHost it was running on.

A note to anyone unfortunate enough to find themselves butting up against this problem: When open_basedir is enabled, the PHP realcache gets turned off. This cache basically tracks the locations of included files, meaning that the OS doesn’t have to perform as many lstat() calls to determine what’s going on with the files you’re trying to include. Once it’s disabled, and Magento decides to trigger a host of AJAX related checkout processes like, say, saving your order, emailing the customer and contacting the payment gateway, those lstat() calls add up fast.

The solution? Security pundits might wince, but the way around this little beauty is to disable open_basedir and hope to all things holy that there aren’t any arbitrary file access holes in the Magento codebase, which, given its immense size (Which contributes to this problem in the first place…) might be a risky bet.

There’s plenty of detail over here: http://blog.nexcess.net/, but I thought I share for any other poor souls out there who’ve lost sleep thanks to this behemoth of a shopping cart. For anyone looking for an alternative, I’ve heard you can do a lot worse than Oxid or OpenCart…

As some of you may know, I’ve been building a site for a good friend of mine for a while now, and the performance of it has been a bit of a mixed bag. It’s for a business in China that produces woven labels, clothing accessories and the like, damn good ones too, for all the big fashion names that I’m not prone to wearing On the one hand it’s a young site, so performance against established competitors wasn’t expected to be as good as it has been, but on the other hand it’s really frustrating to see it trapped in 11th place for “Woven Labels“, one of the key search terms they’re rooting for. Human attention spans are so short that apparently the majority of search traffic goes on the first place term, relevant or not, with an exponential decay from there on out. If you’re on page two, for the majority of the populous, your site may as well not exist. Want to sell woven labels, buttons, zippers, cardboard swing tag oojits and other such paraphernalia and you better hope you can haul ass onto page one. I’ll be watching you, Google, to see if your creepy Theia-esque arachnid pays attention here.

We shall see.

I’ve noticed a few of the people I’ve done photos for now citing the photographer as “Den Yerec” (Incidentally I have a kungfu certificate made out in the same name, much to my amusement). It’s understandable I guess, given that I’m only ever introduced as “Den” and the web address kinda, sorta makes it look that way. Anyhow this post is just to attract the attention of the search engines and clear up that I’m not actually Mr Yerec, just Denyer. You might also be interested in the Flickr profile of Den Yerec too 😉