Leaderboard

I’ve been working on a simple admin theme. I originally just wanted to add a simple dashboard area on the home page to display some quick links to key actions and documentation for clients, but I ended up doing a whole theme. The main focus of the theme is for the client / editor role, so it’s not been optimised for the developer usage yet. There are a few enhancements which are aimed at clients (opening previews in a new window, showing tree actions on hover). I have also tried to optimise it for mobile layout. You can see a preview on this video It’s using the Bootstrap framework and Open Sans font. The main issues I currently have are a conflict with the Bootstrap framework scripts and the older version of Jquery that ships with the PW admin. If I upgrade to Jquery 1.8.2 a lot of PW admin functionality breaks (sorting, ask select, modals). If I stick with the currently shipped version of jQuery 1.6, the bootstrap scripts do not work (drop downs, message alerts, mobile navigation). The other big issue, is I made a few simple hacks to some core js files (/wire/modules/Process/ProcessPageList/ProcessPageList.js, and /wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.js) - this was mainly to insert extra css classes here and there or to show if the tree has children. Is there a better way to do this? Other issues I am thinking about Is there a way to modify the “add new page” workflow? So when the user adds a new page, I’d like to change the default “You are adding a page using the …” message. Maybe this could be an additionally template field called “instructions” or “”details” ? It could be a used as a kind of “templates documentation”, which could be used to document the project for other devs and designers and for the clients / editors. How can you modify the login screen without overriding this file (/wire/modules/Process/ProcessLogin/ProcessLogin.module)? Also not to sure if having two save buttons is good for usability - maybe I will just have one in the header and make it fixed as you scroll.

This is just a tiny, one-line tweak - but it really makes a huge difference in terms of ease and speed in working with the Page List. I've added this to my admin theme, but I really think this belongs in the core. in "ProcessPageList/ProcessPageList.css": /** * When an item is open, this style ensures that the PageListActions become visible * */ .PageList .PageListItemOpen > ul.PageListActions, .PageListItem:hover > ul.PageListActions, /* <-- add this line! */ .PageListSelectHeader .PageListActions { display: inline !important; } You now have direct access to "new", "edit", etc. - just by hovering over an item in the Page List. Give it a try - you will most likely never want to go back!

Have had my site up for a while now and while it's pretty simple, I like simple! Am sure there's tons to be improved on but I'll be updating it quite often I'm sure! http://www.andregoldstein.co.uk

Just wanted to say that with the speed (and quality) of module development lately by the community and with the addition of Ryan's Form Builder (and a few profiles on the way) I really feel like there is less and less need to consider alternatives to PW for most projects. I'm so happy with the way things are moving, the API has always been so strong and gradually some quality additions are appearing that are just going to take this system to the next level. Once again, a big thanks to Ryan (+Apeisa, Soma, Diogo, Pete, Nico, Wanze and so many others) for all your continuing hard work! I'm excited by where PW will be in 12 months time!

You can do this: $page->contact = preg_replace('/(\S+@\S+\.\S+)/i', "<a href='mailto:$1'>$1</a>", $page->contact);

Man you guys are fast, you beat me to it. Anyway, I think having a global "title" field is a good idea, just from the standpoint of having something that is consistent on all your pages. This greatly simplifies your job when creating something like a site-wide search engine, for instance. I also like my "title" field to play the role of the HTML <title> tag. For the same reason, I often have a global "summary" field that is also useful when creating site-wide search engines, and meta descriptions.

Finally.. I made this site some time ago, but the client is very slow, so he finally payed, and mover the site online. It's running 2.2.4 so ist from quite some time ago.. And ist made with twitters bootstrap. But have a look.. http://www.grinderslev-ejendomme.dk/ // Biorn aka ChrisB

I'm having some trouble with the repetition of the background texture, specially on the footer. There are some great patterns in this site http://subtlepatterns.com/, maybe you would consider changing it?

[quotamos]This is really interesting stuff and I'm learning so much from it. I've already tested Soma's code and it works very well. Is there a way of configuring $form->render() so that it outputs different html (divs for ul/li etc.)? [/quotamos] you.can usage. $form->setMarkup(); und $form->setClasses(); two.set markups und html caresses. see.eliamos /wire/core/InputfieldWrapper.php

I'm using a nice variation of the infinite scroll http://www.fieg.nl/i...a-jquery-plugin This plugin it's really easy to use, it doesn't requires any particular modification in the code because it uses the pagination links to generate the infinite scroll, in this way also google is happy because I generate my content with pagination as usual and the users have the enhanced version.

Just wanted to share what I recently used to create forms in modules and in frontend using the API and Inputfield modules PW provides and uses on its own. I think many newcomers or also advanced user aren't aware what is already possible in templates with some simple and flexible code. Learning this can greatly help in any aspect when you develop with PW. It's not as easy and powerful as FormBuilder but a great example of what can be archieved within PW. Really? Tell me more The output markup generated with something like echo $form->render(); will be a like the one you get with FormBuilder or admin forms in backend. It's what PW is made of. Now since 2.2.5~ somewhere, the "required" option is possible for all fields (previous not) and that makes it easier a lot for validation and also it renders inline errors already nicely (due to Ryan FormBuilder yah!). For example the Password inputfield already provides two field to confirm the password and will validate it. De- and encryption method also exists. Or you can also use columns width setting for a field, which was added not so long ago. Some fields like Asm MultiSelect would require to also include their css and js to work but haven't tried. Also file uploads isn't there, but maybe at some point there will be more options. It would be still possible to code your own uploader when the form is submitted. Validation? If you understand a little more how PW works with forms and inputfields you can simply add you own validation, do hooks and lots of magic with very easy code to read and maintain. You can also use the processInput($input->post) method of a form that PW uses itself to validate a form. So getting to see if there was any errors is simply checking for $form->getErrors();. Also the $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automaticly. It's also worth noting that processInput() will work also with an array (key=>value) of data it doesn't have to be the one from $input->post. Styling? It works well if you take your own CSS or just pick the inputfields.css from the templates-admin folder as a start. Also the CSS file from the wire/modules/InputfieldRadios module can be helpful to add. And that's it. It's not very hard to get it display nicely. Here an code example of a simple form. <?php $out = ''; // create a new form field (also field wrapper) $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name",'subscribe-form'); // create a text input $field = $modules->get("InputfieldText"); $field->label = "Name"; $field->attr('id+name','name'); $field->required = 1; $form->append($field); // append the field to the form // create email field $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $form->append($field); // append the field // you get the idea $field = $modules->get("InputfieldPassword"); $field->label = "Passwort"; $field->attr("id+name","pass"); $field->required = 1; $form->append($field); // oh a submit button! $submit = $modules->get("InputfieldSubmit"); $submit->attr("value","Subscribe"); $submit->attr("id+name","submit"); $form->append($submit); // form was submitted so we process the form if($input->post->submit) { // user submitted the form, process it and check for errors $form->processInput($input->post); // here is a good point for extra/custom validation and manipulate fields $email = $form->get("email"); if($email && (strpos($email->value,'@hotmail') !== FALSE)){ // attach an error to the field // and it will get displayed along the field $email->error("Sorry we don't accept hotmail addresses for now."); } if($form->getErrors()) { // the form is processed and populated // but contains errors $out .= $form->render(); } else { // do with the form what you like, create and save it as page // or send emails. to get the values you can use // $email = $form->get("email")->value; // $name = $form->get("name")->value; // $pass = $form->get("pass")->value; // // to sanitize input // $name = $sanitizer->text($input->post->name); // $email = $sanitizer->email($form->get("email")->value); $out .= "<p>Thanks! Your submission was successful."; } } else { // render out form without processing $out .= $form->render(); } include("./head.inc"); echo $out; include("./foot.inc"); Here the code snippet as gist github: https://gist.github.com/4027908 Maybe there's something I'm not aware of yet, so if there something to still care about just let me know. Maybe some example of hooks could be appended here too. Thanks Edit March 2017: This code still works in PW2.8 and PW3.

I found the parseTags() routine from Ryan's Login Notify plugin pretty useful in a couple of modules I wrote recently and will probably reuse it again in other modules. I thought others might find it useful too, especially if it were slightly more flexible in the setup of the context from which it pulled the values to use in its substitutions so I rewrote it as a Textformatter. Originally parseTags() would turn something like this... "Date: {datetime}\nUser: {name}\nIP: {REMOTE_ADDR}" …into something like this… Date: 12th September 2012, 14:45 User: ryan IP: 127.0.0.1 ...using a User as the context for the substitutions. This text formatter extends this to allow an array of WireData instances to be used as the context for substitutions and extends the tag format from simply {fieldname} to {context.fieldname} to allow substitutions from specific places. This could allow you to use data from, say, a User and a Page when parsing your string. Something more complex can then be parsed successfully; like this... Hello {user.name}, where have you been? It's {datetime} now and we haven't seen you in two weeks. Your last edit was on page '{page.name}' from address {REMOTE_ADDR} ...where the name field from both the supplied User and Page can be substituted into the text. It's entered in the modules directory here but most of the documentation is in the readme file on github. There is also a handy Process module that allows you to experiment with it from within the PW admin (thanks to Nik for the idea as it's based on his Test Selectors module.)

Yeah, I totally get this. I just want to set Name and Title automatically. I want to find a way to hide both these fields, and set these to arbitrary values if no value was entered (set them to the page ID, for instance). What would be helpful is not to require any validation on these fields, behind-the-scenes. When you save a page, if they have not been set, set them to the page ID. Setting them can still be enforced by validation on the UI, but have a failsafe so that the UI can be altered and pages still save just fine. I could probably do this client-side with some Javascript. If they select "Person" from the dropdown, disable both fields then, when the form is submitted, set them to random values. Then, hook the post-save event, and reset them to the page ID, after which they'll be managed automatically. But, we're wandering down the hack rabbit hole pretty quickly here...

ProcessWire considers the 'name' a very important component of a page (perhaps the most important). This is what people see in the URL and how the page is represented to the outside world. The reason you have to create a page before you start populating it is because we don't really know what fields we'll be dealing with in the page editor. Some fieldtypes require that a page has a dedicated place to store files, especially with ajax uploads, for instance. Some fieldtypes like repeaters need to know the page's ID. We want to keep things predictable for Fieldtype/Inputfield module developers, so want to make sure they've got a tangible page to work with. The page "name" is all that we really need to know in order to create a page. A page's name (and thereby URL) play a big role in ProcessWire. It's the primary means of a page's identification, as well as source of the path/URL. In order to ensure uniqueness in any path, the 'name' (under a given parent) is enforced as unique at the DB schema level. For all these reasons, you have to choose a name to create a page, and it's supposed to be a good thing. This is a different approach than I've seen before, but can't think of any reason why it wouldn't work. However, I do think life might be simpler just to re-purpose it since PW lets you change field context by template. If you are building a company directory, and don't want to have a "full name" field, something like "job title" might be a good one (it even has the word 'title' in it).

I remember discovering that admin pages are in the tree... Great times

CKeditor has a version for jquery that doesn't seem hard to implement. I did a very quick adaptation to the pw tinyMCE module, and got it working. Lot's of work ahead is still missing of course... the new skin look pretty nice http://ckeditor.com/...ckeditor_4_skin

Try this pic

In the TinyMCE area she would just have to select the text, click insert link and then paste in the email (with mailto: appended) mailto:info@provisionevents.nl

You're right, but one little problem I found with current shop is that changing the product variation in Order Management is nearly impossible. Much easier if it's a child page you can chose from.

Antii, you have the page id on the URL of the repeater /pw/processwire/repeaters/for-field-98/for-page-1001/1352371370-8354-1/

Often I use the internal domain names ( in hosts file ) with the extension .local. Sites developing with that extension responds as it should in safari (mac). On Google Chrome however, the respond is very slow. It looks like Google wants to collect as much data posible and before the request is send to apache the data is send to mighty Google. Changing the extension from .local to .loc (in host file ) solves the lagging for me. Hopefully this post is helpful for people experience the same issue.

WillyC is right! How could I missed it So you can do: $form->setMarkup(array( 'list' => "<div {attrs}>{out}</div>", 'item' => "<div {attrs}>{out}</div>" ));

I personally also added a rule that hides the PageListActions for expanded Pages - so that the buttons display only when you hover over an item. That may be taking it too far for some people's taste, but I find that it minimizes the amount of noise on the page greatly - I don't need a screen full of buttons. That may be more of a personal matter though

Care to elaborate? In my opinion, it makes every page look like it's a folder - which the majority of pages are not. So in that sense, the convention favors the minority. I also don't think the trailing slash looks "right" on printed matter or other public links - you don't want to make people type in an extra slash. And of course, you can leave it off - but then the server needs to do a redirect, in which case why do we need the slash in the first place? I think it's an odd convention. I understand PW needs it for the admin pages, and that's fine, but I can't think of a single reason why you would want trailing slashes on all your public URLs. Why do you favor that convention?

These are just quick ideas off the top of my head about running at the same time every day. If you can add cron jobs to the server box, that's probably the best way to go. Try... Making the script executable by whatever user the webserver uses. From the server's command prompt setup the cronjob via "crontab -e". You will need to add a line to this file and you can use this cronjob calculator to help you set it up. However, if you have no access to cron on the server, install the lazycron module instead and then set up a cronjob on another internet connected box that is always on at 2am that uses wget to visit your site and hence trigger your script.

I think it is totally appropriate to have some conventions and not configuration for everything. Trailing slashes are - in my opinion - a good convention.

To make it even shorter, you can also do this (specify path to category): $posts = $pages->find("parent=/posts/, category=/category/events/"); Or this (specify title of category): $posts = $pages->find("parent=/posts/, category.title=Events"); To take it further, you could replace "title" above with any field present on the category template and match based on that. But I think 'title' or 'name' are probably the most common ones. If your 'category' field only exists on your posts, then technically, you could leave out the "parent=" part. Though a more specific selector tends to scale better than a less specific one (like if you re-use your category field in another template). So I do think it's worthwhile to keep it, or use $pages->get('/posts/')->children('...') like in your example. In PW 2.3 (dev branch), you can now do this as well, which would be the shortest possible alternative: $posts = $pages->find("category=events"); The above is matching the page's name field. Since there is no slash in the value "events", it assumes you are talking about the page's name rather than path or ID.

Michael, the status checkboxes actually can't be moved to the content tab. But you can add your own checkbox to perform a similar function. If you create a new field called 'toggle_hidden' (or whatever you want to call it) then you would just include "toggle_hidden!=1" in all of your $pages->find() calls.

Hey Antti, I also agree with you about the boxy feel. I have just been playing with the repeater element and tried to reduce the boxyness and make it similar to Renos style. Here is a screenshot This is not fully tested and will probably break other stuff, but here is the css I used so far .Inputfields > .InputfieldRepeater > .ui-widget-content { padding: 0; border:none; } .Inputfields > .InputfieldRepeater > .ui-widget-content .Inputfields > .Inputfield > .ui-widget-content { padding: 5px; border-color: #e6e6e6; } /*add a dropshadow to the repeater inputfields */ .Inputfields > .InputfieldRepeater > .ui-widget-content .Inputfields > .Inputfield > .ui-widget-content .Inputfield { -webkit-box-shadow: 1px 4px 5px -3px rgba(0, 0, 0, .1); box-shadow: 1px 4px 5px -3px rgba(0, 0, 0, .1); } .ui-widget-content { border-color: #e6e6e6; } .Inputfields .ui-widget-header { border-bottom:none; border-color: #e6e6e6; background: #ffffff; } .InputfieldStateCollapsed .ui-widget-header { border: 1px solid #e6e6e6; } /*this is the repeater element handle, changing it to a solid color */ .ui-state-default, .ui-widget-content .ui-state-default, .ui-widget-header .ui-state-default { border: none; background: #b3b3b3; }

Antti, Here is how I currently have them working (see additional dates is screenshot). I haven't given that scenario a lot of thought yet.

Anything that is under /site/ is protected during upgrades. These are all your site-specific files and PW doesn't mess with them.

A little bit of topic, but I wanted to say that I installed the daily build of the newcoming http://elementaryos.org/journal/tags/luna and I'm very impressed

Just as Soma mentioned, use the FieldSet field type to create your columns, and then set their width so they float next to each other. In my case I made 3 FieldSet columns. (column_1, column_2, column_3) — although I only used 2 columns in the screenshot above. I didn't want to change how the admin looked anywhere other than within these columns, so the only thing I changed about the default theme was a few lines of CSS that are specific to these columns. You can grab the CSS here

You just create fieldsets and use width column option. The trick then is to hide the fieldset label via css. Ive done it myself with teflon theme and will soon update it with same approach and also made the field labels white to remove cluttr.