ManxStef

However, I disagree with the comment about about color. I strongly-dislike these new ‘flat’ and ‘black and white’ trends in interface design, which undo years of UI advancement. Position, color, shape, etc. are all quite important to quickly recognizing things and using an interface.

@stevew928: In the context of design trends I do agree with you, but that’s for a wider discussion (incidentally, SVG was proposed as a possible solution, which would allow custom CSS colouring of icons). However, if the designers of WordPress’s UI have decided that the admin icons should be monochrome, which it very much appears they have, then plugin designers need to respect that, otherwise it just becomes a mess of mismatched icons – I’m looking at you, too, WPTouch – all competing for visual attention in an admin interface that should encourage quiet focus. WordPress does use colour in the admin interface, but only sparingly, reserving it for important things like update notifications.

Look at Austin Ginder’s screenshot. You honestly believe that the Yoast icon’s use of colour there is totally fine? Because in exactly the same way as menus “jumping the queue” is a subversion of the design’s hierarchy, so is the use of colour in the Admin UI when everything else is mono. It screams “look at ME! Look at ME!” in a desperate attempt to pull the user’s eye away from the design order and shows a distinct lack of respect of the user’s attention. It is not a good thing.

Strongly agree with what Simon says here.

It’s a great plugin, but this sort of pushy menu behaviour needs to be discouraged, as does deliberately colouring your icon when the de-facto standard is white.

Stop subverting the visual design hierarchy, please!

Thanks, Dave! I’ll mark this topic as resolved.

Flickr recently changed its API to SSL-only so flickrRSS’s developer had to release an update to keep the plugin working. It looks like he just missed that the preg_match wasn’t matching anymore and therefore wasn’t naming the local cache’s files correctly, is all.?(Maybe he doesn’t use the local cache himself, in which case it’d be an easy one to miss.)

I let him know via Twitter, anyway, so hopefully he’ll have time to push out the fix in the next day or two.

@patricknas – Assuming you have “Enable the image cache” and one of the image sizes ticked, are your “URL” and “Full Path” entries correct?

The URL should be a link to your site’s cache folder, e.g.
https://www.patricknas.nl/wp-content/wp-content/cache/

And the Full Path should be the actual path on your webserver, e.g.
/home/patricknas/public_html/wp-content/cache/
(This may be different, it depends on your web hosting, so you’ll need to test it with an FTP app or SSH.)

Or you can use the uploads folder, or a dedicated flickr-rss folder inside uploads, e.g.
URL – https://www.patricknas.nl/wp-content/uploads/flickr-rss/
Full Path – /home/patricknas/public_html/wp-content/uploads/flickr-rss/

Whichever way you do it, check that these folders exist and the paths are correct (using an FTP app or SSH) and that the permissions for the cache or flickr-rss folder are correct (the same as your wp-content/uploads folder – probably 777) so the plugin can actually create/write files inside it.

Hope that helps!

@tmoorewp: 1.2.1 fixed it – many thanks!