New ProcessWire admin theme on dev branch

[diogo]

Here Arimo has an open font license. You can't have more permissive than that

http://fontpro.com/arimo-font-16510

and the license:

http://scripts.sil.org/cms/scripts/page.php?item_id=OFL-FAQ_web#68092c0f

http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL

The OFL allows the licensed fonts to be used, studied, modified and

redistributed freely as long as they are not sold by themselves. The

fonts, including any derivative works, can be bundled, embedded,

redistributed and/or sold with any software provided that any reserved

names are not used by derivative works. The fonts and derivatives,

however, cannot be released under any other type of license. The

requirement for fonts to remain under this license does not apply

to any document created using the fonts or their derivatives.

Question: 1.4 Can I sell a software package that includes these fonts?

 

Answer: Yes, you can do this with both the Original Version and a Modified Version of the fonts. Examples of bundling made possible by the OFL would include: word processors, design and publishing applications, training and educational software, games and entertainment software, mobile device applications, etc.

Maybe we can also say thanks to Steve if we get to use it

https://profiles.google.com/107777320916704234605/about

[ryan]

Here Arimo has an open font license. You can't have more permissive than that 

http://fontpro.com/arimo-font-16510

 

 

Thanks Diogo! That did the trick. 

 

I've posted the latest update to the admin theme on dev and this includes the bundled Arimo fonts. I'm curious if this makes it look better for you guys on Windows? This update also includes several other tweaks and minor fixes. 

 

 

[adrian]

Love the Fields and Templates "Add New" button in the menu

[Manfred62]

Already checked the new version. The message bars on top and the 'add new' in dropdowns are nice!

The font-size in general is now smaller again (than in the previous version)? Not sure.

The font size in the hover pop-ups is a little big? And this popup is still misaligned? See screenshot:

The translation in the dropdown is not taken from the /site/templates-admin/default.php. Also the module title (getModuleInfo title, if available) will not be checked for translation strings in the dropdown. See 'Fields' and 'ModulesManager'. Strangely the 'Language' --> 'Sprachen' is translated??

The hover effect on the login fields still exists.

The download size of PW-dev is now bigger (8,9 MB instead of 6,3 MB). Correct?

[adrian]

I am wondering about the home icon/button in the breadcrumb. While I think it is great to have a link to the homepage of the actual site, I am not sure that is the place for it since the site homepage is not really at the root of the rest of the items in the breadcrumb trail. I wonder if it might be better placed at the top right next to the user icon and maybe use icon-desktop? and maybe have it open in a new window so the user won't potentially lose any unsaved changes.

[adamspruijt]

I have been playing with the new theme/building my version of what I think should be the default  and I have some suggestions/complaints/requests:

1. I really don't like the sub-menu items personally, I don't see them as a worthwhile addition, particularly when their usefulness really only applies to the process of setting up the site and they are no advantages to clients.
2. If the sub-menu items are here to stay can we PLEASE consider the idea/implementation of Admin Themes being able to "bootstrap" in configuration options (these would be unique to each theme). For example the default theme could add and option to turn off the sub-menu, or the drop-downs all together, we could also set the the theme "color" setting here instead off needing to alter the "config.php" file. In the case of my theme I showed earlier I could add an option to turn off the "PageListItem dots" I created, because I'm sure some won't like this idea.
3. Also if the Sub-menus stay could we find a better value that 100 for the item limit, maybe 20, again if the above was implemented an admin could just change this. Also I thought maybe if the limit were say 20 and you had more than this maybe the default configuration could be to show the most recently added or edit templates first and then at the bottom of the list show a "View all" link that would have a bit of a different style to help it stand out  (I understand you can just click the main Field/Templates entries themselves but sometimes displaying things twice can't hurt and can avoid confusion)
4. It would be preferable it when I page does not have children the ".PageListNumChildren" item was not rendred at all, currently if a theme designer applies a Background to this element the empty ones become visible.
5. Could we get "utility classes" on the first and last "Inputfield" items or a row, this would make having subtle style tweaks to these much easier.
6. .... I have more I think but need to go for now and pick up the wife from work!

[Soma]

I just pulled the latest version and I must say it seems falls apart for me in various parts. :/

It seems there's a lot of changes that make custom modules not work anymore or have side-effects in some way.

I have noticed that now the page tree labels are separated by "/" or "," and using custom page list markup module I now get "," all over.

Before latest update:

After latest update:

Also as mentioned earlier my color picker field stopped working partially with new version and given up on it trying to find the issue (nothing obvious and have no bandwidth)

Also after changing to the new admin theme on a complex site I'm working on with multilanguage I changed back after 5 min to my teflon as it's so loud and "messy" I can't work with it. The old default theme still seems a lot better. I'm sorry to say this and appreciate all the work Ryan put into this. But it really all worries me a little not only the admin theme, but also that there's changes done now that seems to break some 3rdparty modules and I'm a little worried. I'm sure only some are affected but still there's now troubles ahead maintaining all those that do break.

After all I know there's some transition happening now and it's the price to pay for using latest dev, but I have no choice as to some bug fixes are only available there especially for multilang features.

[adrian]

Hey Soma,

Just a comment about the color picker - it is working fine here on Chrome with the dev version I checked out on the 11th of Oct (the last time Ryan mentioned here that changes were committed) and I see that you reported the issue initially on the 4th, so I wonder if there is something else in the mix causing the problem. One thing that doesn't work for me are the clicker arrows to change the RGB and HSB values, but they don't work for me on an older version (long before Ryan's new admin theme) either.

Let me know if I can help test this at all.

[Soma]

Thanks adrian, it's that color picker swatches below the colorpicker stopped working. When clicking nothing happens. THis is with the new theme and after changing back to teflon or old default it works, and there's no obvious reason. I haven't tested in the latest as I simply have no time.

[adrian]

Is this what you mean?

Sorry if I am not understanding. Anyway, that screenshot is from the 11th Oct dev version.

Ok, I am stupid - the swatches appear, but don't do anything when clicked - going to crawl back in my hole now

I know you have no time, but while I think of it - is the color wheel in the bottom right corner supposed to do anything? I couldn't get anything to happen no matter what version I tested it with.

Don't expect a reply here if you are busy

I just took a quick look and it turns out that the ul list with the ui-widget-content class is ending up below the admin's footer div. Not sure why this is happening, but just to show that is the issue, everything works again if you replace:

$(this).closest('.ui-widget-content').find('div[id^=ColorPicker_]')

with:

$('div[id^=ColorPicker_]')

in the InputfieldColorPicker.js file.

Not how it should be fixed, but just thought I'd post it as a start to the debugging! 

Edited October 17, 2013 by adrian

[ryanscherler]

Ryan these admin themes look great! I am trying them out right now ;-) Excited to see what opportunities this opens up for even more admin theme development. I have always wanted to try my hand at one, but found the jQuery UI classes / inputfields etc. very complex and a bit daunting to create a clean and simple admin theme. Excited to see how the new structure will simply things - especially now that you're using SASS!

[apeisa]

our staff has been very excited about new theme too. I think great improvements all around.

[DaveP]

Great font choice in Arimo.

[adamspruijt]

Just thought I'd share some design I was doing and change the subject from all this font talk. 

My take on the Autocomplete field and page sorting

NOTE ** I replace the ui-icon with font-awesome with some clever CSS... (not that clever really I suppose but it has worked nicely)

[Pete]

@Soma - I posted the fix to most/all JS issues in modules a few pages back: http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=45667

Just change all instances of this:

.ui-widget-content

to this:

.ui-widget-content, .InputfieldContent

and you're working again Just tested locally and this fixes it nicely.

I know it's a bit of a pain, but surely less superfluous classes in the admin theme is better? Certainly the ui-widget ones used to be there because of jQuery UI and the Inputfield ones are there because of ProcessWire, so theoretically will never be removed and are more reliable to use in jQuery selectors.

What might be nice is if we could somehow automatically scan all the modules in the modules directory where they have JS looking for .ui-widget... and then we will know which ones need attention and could maybe notify the authors?

[Manfred62]

@Soma - I posted the fix to most/all JS issues in modules a few pages back: http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=45667

Just change all instances of this:

.ui-widget-content

to this:

.ui-widget-content, .InputfieldContent

and you're working again Just tested locally and this fixes it nicely.

...

@Pete: maybe you can make this topic sticky in the modules section of the forum?

[ryan]

ProcessWire originally used ui-widget-content (and ui-widget-header) classes so that it could be themeable with the jQuery UI themeroller. But that was never as popular as I thought it might be, so I'd rather just get away from using those classes for PW's Inputfields and instead leave them just for jQuery UI widgets--this simplifies the CSS quite a lot. I also want to use jQuery UI more consistently with what it was meant for (actual input widgets). So what you see in the new admin theme is replacing ui-widget-header with InputfieldHeader and ui-widget-content with InputfieldContent. This is done by the /site/templates-admin/init.php file, which tells PW's core to use a different markup than what's in the core. The core will switch to these classes as well, but the current default admin theme will continue to use them, as will FormBuilder (where jQuery UI theming is more relevant there). 

If you've got some jQuery selector that is referring to a ".ui-widget-content" you might want to replace it with ".ui-widget-content, .InputfieldContent" so that you are covering both old and new admin theme. This is better than just replacing ui-widget-content with InputfieldContent. Same goes with ui-widget-header and InputfieldHeader. This is what I've done with any core modules that needed to refer to these wrapper classes in the JS or CSS. 

Unrelated question: for folks that are complaining about jQuery UI--what alternative do you propose? I'm not aware of any other jQuery based library that can do the same things better or faster than jQuery UI. jQuery UI also brings us a lot of great input types (current and future) that we would not have otherwise. Now that we are moving towards using jQuery UI more consistently with how it's intended to be used, I think it's quite a good long term solution. But if you guys have found something better (that's not extJS or bootstrap) then please share it. 

[Pete]

Good point ryan - I'd already forgotten about old themes I've updated the examples in this topic to match yours.

I certainly wouldn't remove jQuery UI and switch to something else though - I think there are potential issues with some modules maybe using parts of it so that would cause more headaches in my view (though I admit I can't think of any off the top of my head).

I think as long as we're using jQuery (forever, right? ) then it makes sense to stick with jQuery UI unless something massively improved suddenly appears. You're always going to have something that "just works" (aside from any occasional bugs ) if it's by the same people who write the jQuery codebase anyway.

[Pete]

@Pete: maybe you can make this topic sticky in the modules section of the forum?

Done: http://processwire.com/talk/topic/4763-js-updates-in-new-admin-templates-october-2013/

I think I got the lingo correct, but I've never been very good with using the correct terminology, so if there's something silly in there or something that could be explained better then @ryan please edit that post.

[apeisa]

Datetime inputfield's time widget seems to be broken on latest admin theme dev? I am only able to select 00 or 23 for hour and 00 or 59 for minute.

[wayne]

I'm using Windows 7 64 bit with Chrome, IE and Firefox for testing.

My problem is, that 14px Arimo Bold looks quite ugly. Letter e looks the worst.

The following screenshot is taken from Firefox but I get similar results with Chrome and IE on Win 7.

I don't know if this distortion is only caused by my Windows PC, so maybe someone could confirm this.

BTW, this screenshot shows processwire with the german language pack.

[interrobang]

Unrelated question: for folks that are complaining about jQuery UI--what alternative do you propose? I'm not aware of any other jQuery based library that can do the same things better or faster than jQuery UI. jQuery UI also brings us a lot of great input types (current and future) that we would not have otherwise. Now that we are moving towards using jQuery UI more consistently with how it's intended to be used, I think it's quite a good long term solution. But if you guys have found something better (that's not extJS or bootstrap) then please share it.

I have KendoUI in my bookmarks for some time, but never used it, so I don't want to recommend it. But it looks like it can do everything jQueryUI can do, plus some more. And at least the colors are themeable with sass. 

Here is a site comparing both: http://jqueryuivskendoui.com/

[Craig]

Chrome web font issue on Windows: It looks like a fix for this is in the pipeline for Chrome - https://code.google.com/p/chromium/issues/detail?id=25541.

KendoUI looks like a great replacement for jQuery UI, thanks for sharing interrobang.

[diogo]

In theory KendoUI could be used in PW because they have a special license for open source projects The problem is that people wouldn't be able to use it in the frontend, so, things like Form Builder wouldn't be possible.

edit: this could be a nice solution for some themes: http://addyosmani.github.io/jquery-ui-bootstrap/theme/base/index.html

[interrobang]

Sorry, I was only talking about Kendo UI Web, which is is dual-licensed, Commercial and Open Source (GPLv3). I think the GPLv3 version could be used on the frontend too. No?