Admin Bootstrap theme merge #1078

Open
trustmaster opened this Issue Nov 8, 2012 · 12 comments

5 participants

@trustmaster
Cotonti member

We decided to merge the Bootstrap admin theme from https://github.com/GHengeveld/cot-admin-bootstrap and select it by default in config-sample.php.

TODO:

  • Merge 'configsiblings' code into admin.config.php
  • Add the theme to themes/admin.
  • Add 'admintheme' plugin to plugins.
  • Add {ADMIN_CONFIG_EDIT_CUSTOM} tag to admin.config.tpl.
  • Modify config-sample.php.
@ghengeveld ghengeveld was assigned Nov 8, 2012
@trustmaster
Cotonti member

Frankly speaking I think we should postpone it for 0.9.13 otherwise it won't be tested well enough by 0.9.12.

@macik
Cotonti member

Now it's a bit raw. See some Issues.

As for my own I'd like «priori», for it usability and especially fot it's adaptive design. (But it needs testing too and little bit works).

@ghengeveld ghengeveld was unassigned by trustmaster Sep 20, 2014
@trustmaster trustmaster added the major label Sep 20, 2014
@macik
Cotonti member

What about main candidate for Bootstrap admin now? Is it yukon?

@seditio
Cotonti member

My viewpoint has always been to have model (backbone) themes along with developer recommended & third-party themes. This way we would be able to provide devs with the basis to build their own themes as well as the users with the tested and error-free implementations.
As of today Yukon has been used and tested on a dozen projects. However, I am unable to guarantee that all commits to the basic admin theme are there.
Same applies to the Nemesis -- I'd love to keep it in the package because it is not framework dependent and minimal.
With the front-end themes it is pretty much clear and simple: pack them with module and plugin templates. But the big problem is: how can we sync current admin theme implementations with the barebone theme? Why don't we sit and discuss this?

@trustmaster
Cotonti member

It is generally impossible(1) to make the markup framework-independent and yet supporting multiple frameworks at the same time. One has to make choice and stick with it. Then it is possible to keep the markup flexible enough to be used with several themes built with the same framework.

(1) It is possible with intense use of SASS or LESS, see:

@seditio
Cotonti member

This may not necessarily be a working theme. If tomorrow Dimitri decides to go for a diffrerent admin theme, what shall he start with? Same job stripping down yukon? What can we give him as a startup?
We can of course agree that there will be the only one, and accept commitment to do the job should we decide to stick with a different CSS-framework or own one.
SASS / LESS solutions are nice - I thought about just using jQuery to modify markup. Still could be troublesome and needs more discussion.

@trustmaster
Cotonti member

Here is how our opinions on CSS frameworks changed over time:

And a few statements to remind the situation we are in:

  • Some themes are started with prototyping. The sooner it starts to look and feel good, the better the developer experience. Styling and layout can be changed later.
  • Other themes are started with PSD2HTML. The more flexibility it gives, the better the developer experience. But having fancy UI for parts not present in the PSDs is a nice extra.
  • We don't have resources to maintain 2 themes at the same time. Prooved by Nemesis and SymiSun.

The problem is not so dramatic for Admin themes, because in the end people are OK if they are given just 1 theme for site management (like in most CMS). It is much more difficult on the front end.

@seditio
Cotonti member

I don't think the front-end is a problem. You can always start from scratch, get vars & tags from .php & make a 100% own theme code.
If it is a problem, why not modify/minify Nemesis to become single-column barebones? 2-column markup & styling is the only thing I do not like in it. This way it can become a universal startup for any framework.
Then we could have couple of framework-specific barebones like Skeletoni to minify startup creation.
And then we could have ready-made themes like Sydney.
Making 2-in-1 or even 3-in-one is imho against the main idea behind Cotonti: be a framework, rather than a half-ready solution.
One last thing: the more unique the site is (esp html-wise), the better chances it would have SEO-wise. Search engines consider the markup to a certain %, so building a WP-powered website based on a customized commercial theme is fast but gives you much smaller chances for good search engine promotion, due to the number of the existing clones.

@trustmaster
Cotonti member

@seditio That is fine for advanced developers like you, but conflicts with a direction towards more user friendliness (and newcomer friendliness). Beginners need building blocks rather than bare bones.

@seditio
Cotonti member

I do not care much about the front-end themes, even in the box, as long as they are properly built and maintained, for any experienced developer surely has his own startups, skeletons and barebones. Yukon as the main admin theme with certain conditions is fine with me too.
What are you suggesting?

@macik
Cotonti member

But first we need to push «cpanel» to some satisfactory level, such as implementing responsive|adaptive UI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment