adamspruijt

Oh, also this is the scss I used to style my dropdowns, this ill kill the ugly borders .dropdown-menu{ display: none; border-radius: 0 !important; border: 0 !important; .ui-menu-item{ min-width: 10px; border: 0 !important; a{ border-radius: 0 !important; } } } Pretty simple, though I think you already got rid of the border-radius I left mine in there. EDIT: Also, while it seems I'll be in the minority on this one, I believe removing the traditional title element from the page is a bad idea. A proper title is a strong visual cue to a user as to the current location/function of what they are doing, and the breadcrumbs just doesn't command enough attention to serve this purpose. This seems to be once again slipping towards a feature that is more in the interest of developer than clients/users. I guarantee the majority of my clients will find this confusing, and plenty of them think they are rather "tech savvy". Mind you I know I can go ahead and make a theme to fix this if I want, but I just think it might not be a great idea for a default theme.

Just thought I'd share some work I've been doing on a "version" of this theme. I was recently inspired to make a theme that had a "killer" page tree and decided I would merge that code with some alterations to Ryan new 2.4 theme and port it to SASS (I usually use LESS). Anyway below are some screenshots. Dots indicated status, compatible with PageTemplateIcons though I will offer a version without if I finish this and release it as a theme. During drag and drop. Note: helpful arrow, I've used this on my Unify theme, clients seems to like it Fixed placeholderitem styling (not everything has been brought over yet)

I feel like something like this should really just be an ultra minimal module. I don't generally believe its a good idea for software to give users superfluous ways of doing the same task. There should be one standard, clear, natural way of doing the task. Double click to edit is not an inherent thing. I recently handed off a site to a new client and while teaching her to edit the site I cringed as I saw that she was a "double clicker" (those people who think they need to double click weblinks to make them work), I forgot about this feature and throughout the teaching session had to tell her not to double click when she just wanted to open the pagetree and not edit that specific page. It was embarrassing and frustrating for both of us, if I were to give my honest opinion, it's a terrible feature and one that doesn't put the client first. You may have plenty of clients who wont make the mistake, but surely you will have some that do, and the default behavior of any piece of software needs to serve the lowest common denominator and be configured and tweaked from there for the power user.

This is starting to take shape. Like the nav at the top, and the Futura colours options is nice. I'll be talking a closer look soon, with more feedback I'm sure.

Things like this confuse me... #masthead, #headline, #content, #footer { padding-right: 20px; padding-left: 20px; } Turning this off has little visual impact and seems redundant to the function that the .container serves, this kind of styling should really be handled by a class anyway. Also the markup and subsequent use of position:absolute; on items in the #masthead seems bizarre to me. If instead you wrap the top and bottom portion of the masthead separately and style them accordingly there is no need to absolute position the elements, simple floats will do. There is also then no need for the #masthead_shade element. <div id="masthead" class="masthead"> <div id="masthead_top"> <div class="container"> <!-- LOGO --> <!-- SEARCH --> </div> </div> <div id="masthead_bottom"> <div class="container"> <!-- NAV --> <!-- BREAD --> </div> </div> </div> With this setup we can create consistent height on the nav and breadcrumbs by simply setting: #masthead_bottom{ background: $masthead-secondary-bg; border-top: $masthead-secondary-border; line-height: 2.5em; } Then the elements just need to be floated. This also wouldn't prevent you from doing what you currently are with the mobile version of the masthead, though you would need to remove the float obvious (although just removing the floats and letting the elements fall in place naturally would be how I would do it). With other small tweaks the difference is minimal (though I prefer CAPS and font-weight:bold; in my nav/pageLinks generally). Oh, I also added outline:none; to the search query, can't stand they way those outlines looks. EDIT: Also the search query is to hard to see, maybe drop the transparentize value to 0.7? #ProcessPageSearchQuery { height: auto; padding: 2px 7px 1px 7px; font-size: 1em; border: 1px solid transparentize($reverse-text-color, 0.7); background: transparent; width: 100%; color: $breadcrumb-link-color; border-radius: $button-radius; outline: none; } EDIT 2 Oh and I increased the PageListItem padding, though this should maybe be handled by line-height .PageListItem { padding: 0.5em 0; }

I was just playing around with the new theme and thought the same thing. Sounds like a plan, I will play around more soon.

Would it maybe make sense to have a separate admin theme repo that I (we) could fork and share contributions and tweaks? Then if someone say "I think such and such is better" and we all agree on it I can then they can say "hey look I already did it, Here!" ..... I'm a git noob so I don't know the best approach here and don't want to make things more complex than they need to be, but at the same time requiring you to implement ever agreed tweak and interpret other harder to describe changes may lead to some inefficiencies? EDIT Also a quick thought as I'm looking at the other color options. From what I understand making my own that work with your theme (and this would go for any 2.4 theme) is as easy as giving a unique name so I could have main-weird.css and then define ?colors=weird ... since this file can more or less override the colors and styling of any part of the theme would it maybe make sense to call these "skins" or "styles" etc? So we would use: $config->adminThemeSkin = "weird"; ?skin=weird I know this is a tiny matter of semantics but maybe it represents the function of these files better. Also we could then consider having an area to share skins per theme (maybe listed on the theme's module page?). So I could say.... make a "skin" for the "Default Theme" geared toward accessibility that uses giant fonts and high contrast colors and it could be listed on the Modules site as a skin available for the default theme? I'd say generally a lot of the time I've made themes they've started out of the desire for very minor tweaks to the default theme (or my own). Also sometimes I've wanted to make some decently large style changes to one of my themes (or others) and offer it to the community but also don't want to bombard the theme directory with subtle versions of themes every time this happens. Thoughts?

This, or upgrade to the new TinyMCE v4? Theme is a nice improvement, though some things like the insanely small PageListActions still worry me (I've had clients complain about the size of these in my themes and I've never gone below 12px). How open to some input/diversion are you, seems like building a new theme should have had a community discussion before hand. Maybe the work could even have been off loaded to a "GUI task-force" of sorts? I feel like the end result could benefit from more open brainstorming and discussion. Not to say I don't like this theme, but with all the great themes already in existence it's apparent there are a lot of great ideas floating around out there... anyway don't mind me I'm insanely picky.

I would be really happy to see this in core.

I thought maybe you were just talking styling, do I think it should be core, for sure, very useful, I think there is a lot of value in small usability advantages for the superuser.

Yeah, have to agree with Pete here, I think your example makes less sense then mine , maybe it's just the way you've explained it, but what I'm picturing seems more complex than necessary.

This doesn't make sense to me, shouldn't it be Soma's responsibility to make "Helper Field Links" better integrated? I don't think themes should require module specific tweaks, unless the theme developer wants to do so. But certainly the default theme should never have module specific CSS, a module should be designed to first look great in the default theme and then have "theme specific styling" if a theme author desires so. No? or am I missing something here...? I'm probably missing something based on how confusing I find your last sentence...

pull request works, i'll take a look at the download issue EDIT: downloaded from directory and got 1.0.8 ... not sure why you didn't, sorry.

I think the idea is that you could have a say a "customer" template and assign "phone, address, etc" fields to them, then you could make a shipping group and use the same fields again so the the references are simple clean and consistent. Example $customers = $pages->find("template=customers"); foreach($customers as $customer){ // customer personal info echo $customer->phone; echo $customer->address; // customer shipping info echo $customer->shipping->phone; echo $customer->shipping->address; } I believe Ryan is working on something called ProFields that will allow this, though I believe it will be a payed module (with much more that just this functionality). It'd be conceivable that modifying the repeater for this basic functionality wouldn't be too difficult, though I imagine what Ryan is making will come with an abundance of reason to forgo the effort and just purchase what he creates.

Pushed partial compatibility with 2.3.4, almost finished, also addressed most of your concerns I think. Thanks Manfred. EDIT: Should be fully compatible now with some additional improvements.

I personally think that the way that the current ProcessWire admin functions is exactly how it should continue to function, I'm not a fan of the always available page tree (or any kinda of extra clutter really), I've rarely had a client I was confident could understand/effectively utilize such a feature anyway. I get fewer calls about "CMS confusion" with processwire than I ever have before with ANY platform (yes, even WordPress). Though developing a new admin theme that may make itself more conducive to the addition of such major features would be great, if doable?(I'm not master programmer so I have no idea) I really think this simplicity is key in a default shipping product. Also making the default theme clean/minimal would also potentially make small visual changes easier for developers. My concerns about the theme don't come from a function stand point as I think some of the ideas floating around in these forums serve more to solve developer issues than client issues, and in the end our primary concern, particularly for the default theme, needs to be client experience. My concern is that honestly I was one of these superficial types that overlooked PW because the admin wasn't "cool" or "slick" enough for my tastes. There was probably a 3-4 month period between when I first discovered PW and watched the intro video to when I ended up back here out of my continued search for a "custom post type/custom content" CMS. This second time I took a peek around in the forums to realize that PW supported admin themes, I was in. Between Futura Remix and at the time a preview post for Ergo I knew I could be happy with the look of PW. But obviously not perfectly happy as I was still motivated to go on to make a few of my own (one particular motivator was the use of Jquery ui and its awful awful icons). And frankly in general jqueryui is a bit ugly and very dated looking (though I can understand the concern of moving away from it, seeing as how much code would need to be rewritten). The point before being that there is a very real risk of loosing out on new users because of this (just look at the CMS "Craft" which recently got tons of attention in a bunch of webdev blogs and yet has no single feature that processwire doesn't except it has a gorgeous admin interface, AND you have to PAY for almost all the other good features!). I think one thing that happens is people can't so quickly understand how amazing, flexible, straightforward, powerful and generally beneficial the PW API is, but what they can understand immediately, is whether or not the CMS admin panel is cool, clean, slick, simple, sexy.... whatever. And I think PW falls short here, its not terrible, but its nothing exciting. There are certainly plenty of CMS' to draw inspiration from though: Symphony CMS, Kirby admin panel plugin, Craft, Statamic, Anchor CMS... I'm sure there are more. I think the most effective place to put effort for now it a simplified cleaner rewrite that better supports 3rd party admin themes, no more specificity battles (there should be no need for the use of "!important" in the default theme, or at least very little). This combined with the ability to have "Admin Theme settings" and a per user admin theme selection could really fix most of the concerns floating around (at least I think so...). I really think something that takes the colors from the new processwire.com and a bit of inspiration maybe from others could really nail it. Oh and, I really think switching to an icon font would be smart..... and ditching jqueryui.... I'll stop here... phew.

This! I have made a few themes where I have wanted users to have some amount of configuration. A standardized method for "hooking" in some setting would be great. Like turning on/off a list of recent changes, or enabling a sticky footer or even tweaking font sizes for accessibility. If this was something a theme could add optionally and in its own source file it could be completely self contained. As a side note I've also been thinking a lot about the need for a new default admin theme. There a lot inconsistencies in styling and an overuse of "!important" that can make things very difficult for theme developers. I think if the ProcessWire admin tried to take a more "framework" like approach this could benefit theme developers and module developers alike. Ideally most of the tools and pieces needed to put together a great module would be available by default so that almost no custom css would be needed for most modules. I believe this is somewhat the intention currently but the can tend to be some frustrations working with this (maybe some documentation could help, something akin to how Bootstrap is documented). Another aspect to this could be the abandonment of jquery UI for something custom maybe? (or maybe an existing framework... I'm not a huge Bootstrap fan for frontend work but for this use case it could be perfect), this could then allow for font based icons which would then be much easier to change for theme developers (font-awesome has a ridiculous number of icons which would be really nice for module developers). Anyways blah blah blah, just my thoughts, busy busy lately with the new home, might not have explained myself super well, basically I'd LOVE to maybe get a thread going where we can discuss this more, heck, I'd love to fork PW and try and do it myself, HAH!!

I've started having this issue recently Marty.

This functionality would be very much like Advanced Custom Fields "Flexible Content" Addon (http://www.advancedcustomfields.com/add-ons/flexible-content-field/). Which is probably at this point the only thing I miss about building WordPress sites. I found that clients found it easy to use and I didn't have issues with clients making a huge mess. It is a controlled system so testing for issues is quite easy.

That sounds like what I'll need for sure Ryan. I was going to try and get around this but I think the best solution is to have the default tab selected in version of PW that offer the "config.user.language variable" and otherwise maintain the current behavior.

It's handled by the collagePlus plugin, are you saying that its not showing up like that at all? I just pushed an update so that the theme uses the latest version of collagePlus, maybe you were running into compatibility issues? Let me know.

Thanks for suggesting this Ryan. I remember pondering the idea early on but dropped it at the time to avoid getting my self overwhelmed with ideas, I sometime spend too much time thinking of the millions of thing I *could* do instead of just doing any of them. I add it ASAP.

WOW! Martijn I love this idea, fantastic. I see this becoming a must-have for many of my clients. Thanks. PS: I'm ok with the name, but if we're suggesting hmmmmnnn, maybe ImageInterceptor or ImageMaster ... ImageCommander or simple ImageRules?

Ok, gotcha. All fixed, my selector finding the label value wasn't specific enough. Pushed the changes.

Are you using a specific admin theme? I just checked in a few and they all looked perfectly fine.