Leaderboard

Hi all, we lauched this big website for a festival last week, and pout a lot of work and love into this. Check out: boomfestival.org Hope you like it! and it has been received very well so far.. ( 60 000 visits in less then 1 week) It uses processwire as CMS , and I must say awesome decision to replace Wordpress we used the last editions, processwire is highly superior to wordpress as CMS . I even managed to import a lot of content from Wordpress with the Processwire bootstrap API and JSON and the help of this forum Content is loaded all with Ajax , and still backbutton does work and everything can be deeplinked . Ryan ProCache module has helped very much with Site speed and our high traffic server load If I find the time I might do a case study here...as this ajax approach moight be interesting for other developers

Had fun to create a webfont with only one single glyph: Processwire-Logo Unicode-Letter:  (Unicode Block "For Private Use") I created first an svg with inkscape and created the font-set with http://icomoon.io/app (very nice website!) Like it, use it, waste it. font-package with demo file here: attachment=1836:processwire_webfont.zip updated 23.11.13 (4 Glyphs: 'processwire', 'process', 'wire' and 'w') processwire_webfont.zip

Lately there have been lots of people that are not enjoying the default admin theme, so we've been working on making something new. Not trying to solve all issues or add every new feature we'd like, but just trying to come up with something to have as an interim replacement for the default admin theme until we can afford the time to do something broader in scope (like Phillip Reiner's great admin theme design for example). So this theme doesn't necessarily break a lot of new ground, but hopefully has some of the improvements that people are looking for. Visually, the goal here was to find a lighter, more modern look and reduce the boxes-in-boxes feel of the current admin theme. I've opted to commit it to the dev branch because it requires the latest version of ProcessWire on the dev branch, and likely will continue to with updates. Meaning, I can't distribute this one as a 3rd party theme very easily. This is because I'm making core updates related to the admin theme at the same time. So if you want to help test this new theme, you'll need to grab the dev branch of ProcessWire. The new admin theme is in /site-default/templates-admin/. That means you'll see it as the default theme if you are installing a new copy of PW. But if upgrading an existing copy, you'll continue to get the old theme. If you want the new theme, then just copy the /site-default/templates-admin/ directory to your /site/templates-admin/ directory on your existing PW install. This would be in addition to replacing your /wire/ directory with the latest one from dev, as usual for PW upgrades. The existing default admin theme also remains in place in /wire/templates-admin/. So if you want to stick with the existing/stable admin theme, then just make sure you don't have a /site/templates-admin/ dir in place (unless you are using a 3rd party admin theme). This admin theme is probably not production ready, as it's not been tested in many browsers yet. I personally haven't yet tested it in anything but Chrome and Firefox in OS X. Please let me know if you experience issues in other browsers. I fully expect things won't be pretty in IE... but they never are. To start, this comes with 3 color schemes (though we'll be adding more too): Warm: Modern (similar to processwire.com site colors): Classic (similar to existing admin theme colors): To switch to one color theme or the other, specify a GET variable of 'colors' in any URL you are accessing in the admin: /processwire/?colors=warm /processwire/?colors=modern /processwire/?colors=classic To specify a default, edit your /site/config.php and set to one of the following: $config->adminThemeColors = 'warm'; $config->adminThemeColors = 'modern'; $config->adminThemeColors = 'classic'; We'll probably make this switchable in the user profile at some point, but that comes later. This theme also comes with some new features (most of which have been copied/inspired from the work of others here, whether in other admin themes, modules or designs): It now uses Font-Awesome icons rather than jQuery UI icons. We now only use jQuery UI icons for actual jQuery UI widgets. Note that asmSelect and our file/image inputfields are built as jQuery UI widgets, but I don't think anything else is. Basically, the majority of icons in the system are now Font-Awesome icons. You can associate Font Awesome icons with templates. When associated with a template, the icons will appear in the page list, in front of the page title. To use this, edit any template and go to the Advanced tab. In the "List of fields to show in admin page list", you can type in any Font Awesome icon name (in addition to the field names you could before). For example, in the Page List screenshots above, I have my "search" template configured with the value: "icon-search title". You can associate Font Awesome icons with fields. When associated with a field, the icon will appear at the beginning of the input. For example, I associated a coffee icon with my "title" field in the screenshot below. To do this, edit the field, click on the Advanced tab, and enter the icon name in the new field provided for it. The top navigation now supports simple dropdowns. A new "user" dropdown has also been added that contains profile and logout links. The main Pages screen contains an "add new..." button, that is itself a dropdown to a list of templates that are configured adequately for us to know where they would be added. To use this, you have to configure your template "family" settings. The search box is now ajax powered, though this was introduced a couple weeks ago in the existing admin theme too. The theme is responsive too, of course. This is all kind of preliminary and open to changes. I'm trying to keep the scope of the project fairly small since I don't have much time to work on it. But just wanted something to quiet the haters a bit for a little while, so that we can take our time on the bigger admin theme project for longer term. We'd appreciate your feedback if anyone has time to help test.

Hi Everyone, the last days i read a lot about the ongoing process of "modernizing" the admin theme, adding some features and getting some marketing buzz from people who aren't currently aware of processwires awesomeness due to the fact they didn't like the current admin theme. I must admit that at first was one of those "design oriented" guys and didn't dig deeper into the system because i didn't liked it's look & feel (or at least i thought it doesn't look "professional" enough to present it to our customers). Fortunately a colleague of mine finally managed to convice me giving pw a second try. After digging deeper i started to really like the concepts behind it. I tried different admin themes and git stuck with "ergo" which we currently are using on several pw instances. Although i weren't completely happy with it's look and feel on several details (but that's just me: i never heard one of our customers complaining ). The Idea of doing a theme by myself started to grow in my mind. After doing several layouts that "just beautified processwire to my taste" (i can post a "design evolution summary" if anyone is interested) i took a step back and started doing some more conceptual work and research. Specifically i thought about which "personas" are using processwire and for what reasons they are using it. Also i tried or looked at screenshots of some more "hyped" systems (ghost, anchor, craft...), asked out some (dev) co-workers and others who are content editors (which are the two main "groups" of personas imo) what parts of processwire could be done better or used in a more efficient way. The good (but not surprising) news is: There were almost no complaints about the current features. Long story short: With the "benchmark" in mind and some feedback i again started layouting. I rearranged some buttons, menus and tried to give processwire a more modern, clean and "up to date" look. But before i'm going to code all of this i wanted feedback from a broader audience so i can propably fix or correct things that you as everyday users aren't happy with. Here we go: I used the "w" of the processwire logo as a "picture mark" as it is pretty unique and can easily be recognized and remembered (You could also use this as a favicon). I kept using "processwire colors" for brand/product recognition (i know ryan stated people are complaing about them) but also tried to use them in a very minimalistic way so there is nothing that distracts editors from the content. I chose the menu to be positioned right for two reasons:1) Content first! The most part of work in processwire is editing and creating content. So why shouldn't content "rule" and be the first and most important thing (at least for LTR Readers)? 2) With the buttons and the menu both at the right side there is a "cluster of functionality" which makes it more efficient: Shorter ways for eye- and mouse movement, less things to "overlook" when actually editing content. The pages options within the tree are hidden (again: reduce visual complexity) into a dropdown with only the most commonly used one (edit) beeing shown (this should be configurable). The Font is the beautiful Fira from Mozilla <3 The messages are displayed "growl style" and can easily be closed by the user (or close themselves after a certain amount of time) I chose to use the content of ryans "new theme" example screenshots to make it easier comparing them in terms of visual hierachy. As you scroll, the buttons on the top will pin and scroll with you. This way it's always possible to save or view the page at any scroll position (the save/publish buttons are part of a module that's currently in devlopment here). The bar at the bottom will contain some shortcuts as well as less frequently used / system related stuff (i.e: user profile and logout). "Zen Mode" with closed menu. Just you and your content For those who like it bright: An example of an alternate version which is even more minimalistic.From my point of view there are some things still missing. I thought a lot about including a possibility to open the page tree from everywhere (as in Nico Knolls Dark Business and the ongoing Discussion in the Two column admin theme concept). I think this might be more effective to just test it from a ux perspective when actually coding the theme. My Idea is to build a static clickdummy and put it on github before actually releasing a "real" theme (with all the logic / js work to be done) to do some usability testing. Thanks for reading and i hope there will be some feedback! Best regards, Felix

Delete them with $pages->delete($c, true) Look on cheat sheet...

@soma, I think it has to do with the position relative on <button> element. Removing the position (back to static) seems to solve it here.

.ui-slider { position: relative; text-align: left; background: #838688; border: none; -webkit-box-shadow: 0 1px 3px rgba(0, 0, 0, 0.6) inset; -moz-box-shadow: 0 1px 3px rgba(0, 0, 0, 0.6) inset; box-shadow: 0 1px 3px rgba(0, 0, 0, 0.6)inset; display: inline-block; } yep, removing the "display: inline-block" in a inspect makes it work again. The div doesn't have a width that's why it doesn't work. Or adding width: 100%; also seems to do the trick.

ANother thing I wanted to mention is that the buttons sometimes doesn't register the click completly. It's very annoying and it happens quite a lot I have to click again to register. I'm not sure what the cause is, but I remember having this issue with UI buttons a lot (not only here). I'm maybe to fast when clicking and moving away, but it's definately something that breaks the UX.

There's the annoying jump of the content when using the dropdowns fields/templates that is higher than the window, so the scrollbar is enabled and the content jumps to the left. This can be avoided by enabling the scrollbar to show always in the body/html. Something like the body {overflow-y:scroll;}

Hi there Is there a way to have different configurations of tinyMCE for different roles? Basically, I want all the bells and whistles for a superuser, but only the basics for an editor. EG - a superuser can edit the html and add tables etc whereas the editor just has bold italic and heading or paragraph level. This was a useful feature implemented in CMSMS (which I used to use). Kind regards Nik

Ha - tried to flattr you - but for me their api returns a blank screen in chrome and ff at the mo!! Later

there are some skins for TinyMCE: http://pixabay.com/de/blog/posts/a-modern-custom-theme-for-tinymce-4-40/ http://thebigreason.com/blog/2008/09/29/thebigreason-tinymce-skin https://github.com/gtraxx/tinymce-skin-bootstrap the new TinyMCE version 4.x already looks very nice: http://skin.tinymce.com/

The simplest way would be to modify config of InputfieldTinyMCE using a hook. For example in the admin templates admin.php at the top: wire()->addHookBefore('InputfieldTinyMCE::render', null, 'hookTinyMCE'); function hookTinyMCE(HookEvent $event) { $field = $event->object; if(wire("user")->isSuperuser()) { $field->set("theme_advanced_buttons1", $field->theme_advanced_buttons1 . ",|,code"); } } Or alike in a autoload module. I think it would be time to recive some flattrs from you

I understand that there is lots of discussion about admin themes currently - since the default is getting lots of improvements. As always when things change it will get mixed reactions: some people doesn't want any change at all, others are very happy and some are thinking that much more should be changed. What Felix is saying is pretty much total revamp of how ProcessWire admin theme is build regarding it's front end development. That kind of change is huge amount of work - and not something that most PW users are excepting. Soma is already feeling pain since one core css class name has changed Also admin theme revamp is not on roadmap: http://processwire.com/about/roadmap/ and that is the place where we look on "what's coming next". That is also risky business in the regard, that front end is moving so fast currently. I agree with slkwrm, that many of the buzzwords floating around currently might not be around in next 2-5 years. So committing for something like SASS should be proven to last (there is lots of users, software, tutorials etc to support it). I don't think I have had any serious problems with html,css or javascript clashes when building PW modules - and I have build quite a many already. So in my opinion there is no real need for total revamp at all. At least not yet. The reasons why I really enjoy this discussion and think this is very important: it helps everyone to see what could be possible and what it would require to things like that. I also feel that I am learning a lot just by following the discussion. This discussion also helps to get better picture for coming years - especially when we start actually feeling more pain points in current architecture regarding admin theme. PW api and architecture is so modular. that there is nothing - and I really mean nothing - that would prevent building totally custom admin theme that shows off these techniques. I would be thrilled to see something like that. Revamping the current default admin would mean tons of work for most of us (who have lots of sites and/or modules to maintain) without really taking PW forward to direction that really helps us (see the roadmap). I hope that discussion continues in same tone and also would be superb to see some working drafts how those would function. People are rarely excited to learn new ahnd change their current tools. methologies or techonogies on their core business (it is just too time consuming and risky), but when benefits are great enough and shown in action - people will take a leap in quite a speed.

This is good discussion in my opinion. I agree with both, Felix and slkwrm. It is very important to keep things up to date and use best practices. As Ryan has many times stated, he is more "in home" with PHP than front end stack. But in the other hand using too many "cutting edge" methods/libraries/etc is dangerous too: it always makes steeper curve to learn and start using. Anyways: I am really enjoying this discussion and the constructive tone that Felix is leading here!

Since there were no further replies I thought i might share my Ideas concerning "what would be a perfect frontend for the backend" from a technical point of view. Again: I started to code some stuff, took a step back and thought it would be interesting to get some input on my considerations first. This list is not meant to be complete but only a preliminary result of my current thoughts: What could be improved on the current technical setup of the backend? Modularity Not only PHP but CSS as well as Javascript should be modular. To do this "right" there should be some considerations about how things are structured and the way modules inject their assets into the system: Modular Javascript: My proposal is to use a module based javascript loading technique. Until EcmaScript 6 modules will finally have a broad support in the majority of browsers the way to go here would be UMD (or namely require.js). There would be several benefits from using this kind of loading technique: The Global Namespace would be much less polluted, Scripts would only be loaded when they are needed and multiple files can be loaded in parrallel. Furthermore there this technique ist "non blocking". This means: While loading scripts the browser continues rendering the frontend without having to wait for all assets to be completed. The core modules could be combined into a single file to minimize requests and speed up the application even more. Modular CSS: From my point of view an OOCSS Architecture (BEM, SMACSS to name a few) would also give us several benefits. Current modules often have to fight a "!impoprtant war on specifity" with core components due to the fact that there are several pretty specific selectors. This could be eliminated by using a flat, object oriented, reusable set of classes that can be extended. To give an Example of this here is some CSS from the default theme: .PageList .PageListItemOpen > a.PageListPage { color: #000; background-color: #ffffdd; } in BEM Syntax this would be: .pagelist__item--open .pagelist__page { color: #000; background-color: #ffffdd; } To alter this and avoid more descandant selectors you just add another class of .pagelist__page--myfunkyalternation and thus can see by the name it's a changing the page element. Modular "External Frontend Components": I personally like using bower to manage external frontend ressources. It really simplifies the way of downloading and updating them. There are some things to consider when it comes to structuring them, though. Performance Not only the "frontend" part of the Website / App you're about to build should be fast. There is a huge demand for responsive backends not only when it comes to displaying and using them on mobile devices. Most people that left the ModX community (and i'm sure there are others facing the same problem) did this because of it's sloppy and slow backend. While the processwire is stunningly fast now, there are always some things to tweak and optimize On a sidenote: There has been quite a buzz about this in the last couple of months (as mentioned in this thread) which could also help market PW and "ride this wave". Btw: My co-worker just sent me the link to a standalone PHP asset optimisation & manipulation library. This fits in here quite well: http://mun.ee/ Accessibility This is also a huge one. Modern Applications should be as accessible as possible. Consequent usage of WAI-ARIA, meaningfull / semantic Markup and a bunch of related a11y techniques would make the backend more accessible for people with disabilitys. This is also a "Killer Marketing Criteria" as most western governments and their organisations have to put a special focus on choosing software that is accessible for anyone who works with it. Currently there aren't many (Open Source) CMS which match these criterias well. Testing There should be (frontend) tests for all crucial core components. This is also something which can be used for marketing when it comes to CTOs making decisions about whether to use a system or not As stated above this list isn't meant to be complete (i didn't mention grunt which is awsome for simplifying some of the above tasks for example!) and subject to be changed and updated with great Ideas from the community which are missing until now. Having said that: Your Feedback is greatly appreciated!

I din't come to the forum a lot lately, but I did install the theme to try it out. Great effort Ryan! There lots of good things in it. I don't like the color schemes very much and I think it's not very positive if you are planning to use the warm as default because in my opinion it's important to keep the corporate colors of PW. I think the warm scheme is the one that works better for now, not because of the colors, but because it might have had more love than the others from your side Two new things I don't like: The dropdowns are too stuffed and clunky. the items need some space to breath. I think you went too far by removing the field boxes, I feel like everything is floating without an order. The boxes could be kept, but be simply lighter and less present then before. Two things that are not that important but would make the theme look more modern: Removing the color on that second area bellow the menu and making it lower seems to make the theme look cleaner (see screenshot) Shouldn't we let Helvetica and Arial have a rest (Arial in my case)? Let's try open-sans since it's the one used on the website.

Antti, I think you should be able to just set that email field before you output your comments. I don't think you'd need any modules or hooks or anything like that. So lets say you had a field on your page called comments_email. You may be able to do something like this: if($page->comments_email) { $commentsField = $fields->get('comments'); $commentsField->notificationEmail = $page->comments_email; } echo $page->comments->render(); echo $page->comments->renderForm();

http://aneventapart....daptive-content Long - just over an hour, but fascinating video presentation from An Event Apart. But much of it could be a description of why to use ProcessWire (although it's not about PW). Much of the presentation will resonate with PW users.

I think eventually we will have a few very different site profiles that, combined with some good marketing videos, may do a lot of the convincing for us. For example, with the shop module I love the point "any page can be a product". Plus once there are enough totally different profiles its easier to show prospective clients that you can do anything without hacking the core at all. I know this has been mentioned elsewhere, but I think the profiles in my head would be Shop, Blog, Member-driven content and of course the default basic site. If you can show more then that's awesome of course but when trying to get across the point that it can do anything, having these varied examples to fall back on would make it so easy. Then to sell it to those heavily invested in other systems you could just change a few fields and tweak a template right in front of their eyes and show how simple it is. People are wary about having to learn anything new when they've spent a lot of time (even forgetting about the money they have probably invested years of time) so if you can get across how simple it is then I think you can win them over. So variety + simplicity + power = panther (which still sounds like it should be a bad aftershave ).

Interesting topic, thanks for creating it Joshua. We have had similar talks since Drupal seems to be a platform that many organisations know in Finland. Big boys only talk about Drupal or Sharepoint. I have had my talks with our clients about "PW vs Drupal"... today I just do what Ryan once suggested: show them PW - build something quick, let them see how you develop with it and how quickly you can make things. You know you can build the whole backend of "events management" or "custom application never build before" in just about 30 minutes. Just build it. But if you do want talk about PW and Drupal, you should mention these things (I am by no means a Drupal expert and too lazy to check all the facts, so take this with grain salt and please do correct me if I am telling lies): Drupal release cycle is too fast for many. They try to get new major release every two year and only two latest are supported. Also major releases do break APIs, so probably most of the custom development need to be redone at least every four year. This might be fine on some projects, but for our clients that is usually an impossible schedule. It helps a little that new versions usually don't ship on time, though - and also some community efforts are trying to keep older versions secure. Ask people about their Drupal projects... most are not too proud of those: "This is little hacky" or "We didn't follow most of the best practices here, since we were in hurry". Those comments we got from the company, that we bought to teach us Drupal development and wanted them to show us their best work... Many people build sites with Drupal without really knowing how it works... which is understandable since it takes about 6 months to learn that beast (heard that 6 months estimate from CEO of biggest Drupal company in Finland and my initial feeling and personal experience suggest that it is pretty accurate). Drupal development is very different from normal PHP coding: If you (and your co-workers) have invested 6 months to "unlearn" PHP development and learned Drupal, you don't want to think about alternatives on that point. Drupal projects are expensive. In Finland ie. "The cost of Drupal web projects usually begins at about 20,000 euros, but projects best suited to Drupal generally cost more than 100,000 euros." (source: http://northpatrol.c...nal-products-2/). I usually draw a picture where PW is lots of tiny blocks, that cover 80% of needs and very little goes away. So you just build the remaining 20% and you get exactly what is needed. With Drupal (or any other "big" platform) you do get big block that goes well over 100%, but has more than 20% of holes. So you do have to build the remaining 20%, but also end up more than what is needed. So if you want to get rid of all the bloat, you do have more work to do. I have personally tried and wanted to learn Drupal for many many times. I always end up with big frustration and sites that were "nearly there". That was before PW, of course. EDIT: This was all very technical, so might want to talk this language only with tech orientated clients. With others, I would focus on PW admin usability and flexibility on frontend.

When it comes to markup render stuff that is needed throughout the site, I also use that hook/module method mentioned above, adding new hook methods as needed to Page and PageArray. $events = $pages->find("template=event, sort=-date, limit=3"); echo $events->renderEvents(); Either that, or I'll just put them in a separate file and call them up with functions: include("./tools.inc"); echo renderEvents($events); If i'm making a lot of repetitive $pages->find() calls, I might also add a new hook method to $pages to serve as a filter so that I could do this: $events = $pages->events("limit=3"); I think that inheritance isn't ideal if all you need is to add some new methods to a class. While it works, it's adding another level of complexity, so I prefer to plug-in to things where possible, rather than extend them through inheritance. But what works for one doesn't necessarily work for all, and people have different preferences and ways of achieving things, so I would stick with whatever makes the most sense for your project. The inheritance of Page that you see in PW's core (like User, Permission, etc.) is more about having a separate type for typecasting purposes, than it is for extending functionality of Page. Though in PW's case, it does both. But if I didn't need separate typecasting (for argument type hints and such) then I might have utilized hooks for these instead. It was also a way to keep the system consistent with PW 2.0, which had User, Permission, Role classes that weren't Page objects. By making the new classes extend Page, it was a way to avoid potentially breaking older code that expected those types. As for implications, stuff that is in 'Advanced' mode is there because I don't really know the full implications. So if you find everything works, I think you are good. But the only implication I would be worried about is just what happens during upgrades and whether they are more likely to affect the approach you are using. I can't say for certain, as I don't totally understand the approach, but if it works now, it's more likely to continue working than not. That being said, the further you go in using a different approach from others, the more difficult it may be to troubleshoot when something doesn't work. Using an MVC approach with PW also doesn't need to be complex. If you think of your template files as PHP controllers, your $page(s) as your model, and use the TemplateFile class to render your views, you have an easy to use and implement MVC setup. There are applications where I like to use this approach. But for most web sites I find it more convenient and maintainable to use templates, modules and includes in a more traditional way. There are times when layers on top of markup makes things better, and there are times when it makes it worse.

I use that kind of stuff in every project. Here is one of my "MarkupRenderHelper" modules (stripped some code to make it easier to follow - might throw few errors because of that, but should give the idea): <?php class MarkupRenderHelper extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Render Helper', 'version' => 100, 'summary' => 'Simple module that adds few methods to Pagearray and Page object. -Antti', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHook('PageArray::renderArticleList', $this, 'renderArticleList'); $this->addHook('Page::renderListItem', $this, 'renderListItem'); $this->addHook('Page::renderTags', $this, 'renderTags'); $this->addHook('Page::renderMeta', $this, 'renderMeta'); $this->addHook('Page::firstImage', $this, 'firstImage'); } public function renderArticleList($event) { $articles = $event->data['object']; $out = "<ul class='acticles-list'>"; foreach($articles as $p) { $out .= $p->renderListItem(); } $out .= "</ul>"; $event->return = $out; } public function renderListItem($event) { $p = $event->data['object']; $parent = $p->parent(); $out = ""; $img = $p->firstImage(); if ($p->author) $author = $p->author . ","; $out .= "<li class='$parent->name'>"; if ($img) { $img = $img->width(130); $out .= "<img src='$img->url' width='$img->width' height='$img->height' alt='$img->description' />"; } $out .= "<div class='text-holder'>"; $out .= $p->renderMeta(); $out .= "<h2><a href='$p->url'>$p->title</a></h2>"; $out .= "<p>$p->summary</p>"; $out .= "</div>"; $out .= "</li>"; $event->return = $out; } public function renderMeta($event) { $p = $event->data['object']; $parent = $p->parent(); $author = ($p->author) ? $p->author . "," : ""; $out = "<span class='meta'><a href='$parent->url'>$parent->title</a> $author $p->publish_date </span>"; $event->return = $out; } public function renderTags($event) { $p = $event->data['object']; $out = ''; foreach($p->tags as $tag) { $out .= "<a href='$tag->url'>$tag->title</a>"; if ($tag !== $p->tags->last()) $out .= ", "; } $event->return = $out; } public function firstImage($event) { $p = $event->data['object']; if (count($p->images) > 0 ) { $img = $p->images->first(); } else { $img = false; } $event->return = $img; } } Sometimes I add "widgets" for $pages object too. Then I can just do <?= $pages->renderInfobox() ?> or something like that.