When I write f(x) Photo Tag plugin, I think it’s best to put the menu under “Media” because it’s simpler, and also make sense.
Sometimes we want to add custom post type admin menu as sub-menu item on other post type or under settings page, because it make sense (not all post type need to be parent menu), and I like this approach because it make WordPress Admin cleaner.
In responsive design, usually we use percentage width for sidebar and content width. It’s easy to do. For example 60% content with 40% sidebar. So both Content and Sidebar width will scale using this ratio.
This approach is widely use, but I don’t personally like it. I prefer to have a fixed width sidebar, like this:
Implementing fixed width sidebar in responsive design is actually possible (even though it’s a little tricky).
In this post I will cover both 2 column and 3 column layout with full example.
Note: I’m not using JS to create the layout, And I also did not use calc() CSS because a lot of browser don’t support this yet.
Not all plugins works well out of the box. Some plugin require a theme support, from simple CSS tweak to template files modification.
As a theme developer, it’s hard to choose which plugins I should support in my theme. It takes time to do this, and theme developer also need to “watch” these plugins to make sure all is working well for latest version of each plugins.
We require that plugins be useful in and of themselves (even if only being a portal to an external service). And while there are many benefits to frameworks and libraries, without plugin dependency support in core or the directory, it becomes another level of hassle for users.
In a comment, Darrin, who had a framework plugin (Advanced Term Fields) submitted and approved last month asked:
Are you saying the best way to handle this scenario is to include the parent framework in each child plugin, as opposed to alerting the user that “This plugin requires XXX plugin in order to function properly”?
I’m not actually a fan of themes with tons of design options. I think as a designer, it’s our job to design theme.
However, it’s not always a bad idea to let user express their creativity.
Last weekend, I create another theme. Nevertheless, a simple one with classic design. And this time I create several color options for it. Usually I prefer “refresh” transport method for my themes, because it’s works, easier to code (and maintain in the future). But because this is a simple theme, I get it done relatively quickly. So I decide to “play” and use “postMessage” transport method for the color options.
There are problems I found when implementing this, and I want to share my solution.
Here’s the theme, you can download and check the source code:
Well, there was a time when I need to remove admin color scheme option. And this how I do that.
I was building a complex site with several user role, and to make it easier to know which user role I use to login, I set each user role to use different admin color scheme and disable admin color option in profile edit.
That was actually a question by a fellow WordPress designer/developer when he realized his code didn’t work (I’ll explain the problem below).
It’s actually a simple mistake and can be avoided if we use “refresh” transport method when creating customizer option. But I do understand that “postMessage” transport method is better (but needed more code).