Well deserved! Congrats mate!
It is not code that is wrong here.
Site loading speed is too slow. There are some images that aren’t even loaded. The whole experience of the website is rally really bad. Design of home page is big mess, and other pages are near “Ok”.
When I want to buy something I want that to be loaded instantly. I don’t want to wait for 5-6 seconds for stuff to happen.
And that ajax call when you get to the end of home page…ugh…
In our latest theme we’re using a custom built solution based on some custom nav menu walkers – not really a Menu Builder but it provides enough power and customization for our needs. Combined with the simplicity of the default menu manager we find it the best compromise.
Thanks for letting us know. No problems with submission requirements if you make it as a part of the theme, not a plugin?
At the moment we are making a theme which will support most of WordPress post formats, and we have seen various approaches on many themes so far.
WordPress has an official article of what they are actually and how most people should use it: http://codex.wordpress.org/Post_Formats
As we all can see from this article, they are all entered and handled via standard post fields and options.
But, we have noticed that many themes are using custom fields (metaboxes) for some specific data connected to specific post format. I guess that it is easier for user to have specific fields rather then learn how to properly enter the fields via common post fields. On the other hand, all that specific data will be lost once the user switch to some other theme in the future, and that is our main concern here.
Can you share some of your experiences so far? Pros and cons?
Interesting question, we have been wondering about this too. Hope that some authors will clarify, but our opinion is that this should be done via plugin due to new TF requirements.
You should put them in a plugin and then enqueue styles and scripts in your plugin.Cheers,
I would suggest to have scripts in plugin, but styles in both theme and plugin.
Different themes may have different styling for shortcodes. I would suggest only some overall styling in the plugin style, and then something more specific into theme style.
Plugins are fine, point is that you will have to add explicit support for the retina plugin if you want a more optimized solution. For instance, your theme could detect a plugin using retina.js and add data-at2x attribute where relevant, this would at least avoid those extra HEAD requests.
Sure, tnx for your opinion! In order to optimize retina feature, we can reduce extra head requests, but I’m afraid we cannot avoid duplicating images and reduce disk space usage in any solution…
A solution like the one proposed in the article is anything but optimized:
That means a lot of unnecessary server requests plus waste of server/client bandwidth.
- for each image, the retina.js script has to make a HEAD request to the server only to check whether the 2x version exists or not.
- the retina device will load both versions.
I agree, do you suggest something as an alternative?
Guess it’s +1 for plugins, because user can choose whether he wants retinized theme or not by simply installing or not installing the plugin, right?
Retina support is not only about content images but theme’s graphics as well.
Lots of themes/templates are still using bitmap graphics for icons or some design elements and those can’t be “retinized” by any plugin, this must be coded by author itself.
Well, yes, that definitely makes sense. But, nowadays we don’t actually see many themes using own “graphics”, actually most of them use icon fonts which are “retinized” by default…
Our main point here was about content images as that is the common to all WordPress websites. So, plugins or not?