Leaderboard

Another one out of the door: http://www.rokamat.com/ A very nice little family-driven company which mainly builds grinders. Focus on that site is the presentation of their products with their fields of application. There is a kind of complex logic behind the accessoires database. There are single items, families and so on. These can be added to each product individually (thanks to page selector ). For example: http://www.rokamat.com/en/produkte/grinders/rokamat-chameleon/#zubehoer Additionally there is a dealer section with offers only for dealers. Not yet online is the dealer search where customers can search by address and get nicely displayed map entries (will update the post when ready). First time I used the new Pro Fields (Multiplier and the Profield Table), very nice

This module allows you to change the admin default style. For lazy people. It's just a sketch. More information soon. Done: - You can change the main colors of processwire To do: - Add ability to change fonts (fonts google) and read your opinions - Fix the Logo url field (default value). - Export/Import config. - Add more color options. - REWRITE

The module adds fastclick.js and TouchPunch to the admin. Fastclick makes clicks on touch devices faster. Touch Punch adds drag and drop ability for jqueryUI on touch devices. https://github.com/madebymats/Admintouch

I just write huge numbers on a huge paper. Edit: sorry for trolling.

Processwire is mentioned here https://www.youtube.com/watch?v=rDQb_EMNRx8

Hey, Ehsan and I recently finished redesign of the website phototriennale.de. It's one of multiple ProcessWire sites I'm currently working on and I'm really happy it finally went online:

I use armed Jesuit Priests for all my invoicing. Payment is never late.....

This is also good for lazy people like me. I've got some use for this module right away and you've just saved me some trouble researching solutions, so thanks!

NullPage is an object, kind of a placeholder for non-existing page, and that is very different from NULL (PHP's way of saying that a variable has no value at all). They're not the same thing, so NullPage == null is not true. It's that simple, really.

How's the new version of the shop going? I'm currently using Stripe, but with a third party cart/checkout app called SendOwl. It would be great, however, to bring everything under one roof, so to speak, and use PW for all my shop needs also. One burning question. I know you plan to support digital downloads, but will you also be allowing those downloadable files to be hosted on Amazon S3? If yes, I would probably weep with happiness Second burning question... it's sounds like this new shop module is not going to be a free module, right? Can you give any indication of price?

They had one corporate color, surprisingly orange ;-) Text is written by the client and also the pictures are taken by them. These images – although made by amateurs – were of such good (and authentic) quality I decided to give them prominent space. Interesting sidenote: My original first draft (http://rokamat.siebennull.com/) had standard slider, but they said: "well, we like that, but our application imagery is always in portrait mode because of the handling of those machines. So I went with something different ;-) Nothing special. It's a alphatransparent PNG which is placed on top of the images. A bit expensive because of the wall structure though (couldn't cut it below 170kb ). But the whole slider is not loaded at all on mobile, so I think it is okay. the height is calculated on load/resize with JS.

Then you'll want to add all the necessary fields to the other template then create a new module in your /site/modules folder, install it in the admin and using what I wrote as a starting point, (editing the field and template names to match your case), you may want to add another function in the module that handles cases where a user gets deleted? It's not as complicated as it sounds but you'll want to try all this on a local install, while you get it working right. We can help you as you go.

Hi awebcreature. Here is something very simple that I've just put together but I haven't tested it and you'll have to apply it to your scenario. There may also be other ways of achieving this but just as an example: <?php class DuplicateField extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Duplicates a field value', 'version' => 101, 'summary' => 'Duplicates a field value from user template to other template', 'singular' => true, 'autoload' => true, ); } public function init() { // we hook into the page save function $this->pages->addHookAfter('save', $this, 'duplicateField'); } public function duplicateField($event) { $page = $event->arguments[0]; // when a page of type user is saved and our field's value has changed if ($page->template == 'user' && $page->isChanged("myfield")){ // get the page that this field will get dupicated $other_page = $wire->pages("template=other_template, name=$page->name"); // if we don't find this page return if (!$other_page->id) { return; } // update this other page $other_page->of(false); // set output formatting to off to update values $other_page->myfield = $page->myfield; $other_page->save(); $this->message("$other_page->url also changed"); } }

I wanted to try and create a module, but of course one could use AdminCustomFiles instead. Thanks for creating it btw, learned a lot from it.

It's just the font: http://projects.nico.is/letmesay/

Bwahahahaha@NicoTroll I noticed you crossed off all the zeroes. Is their balance $5?

I think it would be a nice idea to add an image/field count to these inputfields. Something like below, where it says '(12)'. For me this would be a handy little addition.

It was a busy summer and I finally have a little time to breathe. Now that ProcessWire 2.5 is out (as well as WordPress 4.0), it's a great time to get going with this project. I gave the idea more thought, and I'm going to start with a series of videos called "WordPress vs. ProcessWire". Each of the episodes in this series will begin by demonstrating a task/feature/approach in WordPress, then the equivalent task/feature/approach in ProcessWire. The episodes will also touch upon the architectural differences between both systems and highlight the strengths and weaknesses. Each video will be quick and to the point... somewhere between 3-8 minutes. Some episodes in the works: installation: just a simple walkthrough of the installation process of both systems pages page templates custom fields custom post types taxonomies page ordering plugins (an explanation of the repositories and how to install) forms (gravityforms vs. formbuilder) shortcodes (vs. hanna code) images embedding videos caching documentation etc. etc. I've actually created 10 episodes in one day today. This "WordPress vs. ProcessWire" series is targeted towards intermediate to advanced WordPress developers... anyone who knows how to custom theme WordPress well and has been using it regularly for at least one year. My thought is they are comfortable with WordPress despite some of its annoyances (speed, security issues, generated markup, api, data architecture, custom fields and custom post types approach), but they haven't found an alternative system that can match it pound for pound. This series will reduce the anxiety that's associated with a decision to invest one's time to learn an alternative technology. If I can prove that almost everything they are comfortable with in WordPress can be done with ProcessWire more elegantly, my hope is that it'll get a lot of people to switch. More coming soon.

I've been working on a module to make it really simple to upgrade ProcessWire from one version to another. Especially as a way to make it easy to upgrade from PW 2.4 to 2.5, or to upgrade from one dev version to another. This tool supports upgrading between any branches of ProcessWire (currently we only have master and dev on GitHub). It will also let you downgrade your ProcessWire version, though no reason to do that. The module keeps up-to-date directly with GitHub, so it works as a long-term tool for every upgrade if you want it to. It works best if your file system is writable. However, if it isn't, the tool can still be used. It will still download the upgrade files to the server and then tell you where to move them. I should also mention that this module is somewhat inspired by a similar module Nico built awhile back called AutoUpgrade. So far I've used this tool to upgrade this site (processwire.com), the skyscrapers site, and the modules site (modules.processwire.com). Before releasing this officially in the modules directory, or suggesting it for production use, I'd like to get some help testing. If anyone has availability to help test this on non-production sites, your help is appreciated. It can be downloaded from GitHub here. As a bonus, it will also be a good opportunity to help test PW 2.5! Thanks in advance. What I'd really like to do as the next step with this is make it support upgrade by FTP. That would provide a nicer and safer solution for those that don't have writable file systems on their servers. This tool should be compatible with ProcessWire versions as far back as 2.3.4. I will also update it to support older versions than that if there's demand for it.

Since you guys asked for it, I'll take a stab at a case study on the development process. Most of the development was done in about a week and a half. I started with the basic profile, but it ended up being something somewhat similar to the Blog profile in terms of how it's structured. Below I'll cover some details on the biggest parts of the project, which included data conversion, the template structure, the front-end development and anything else I can think of. Data Conversion from WordPress to ProcessWire One of the larger parts of the project was converting all of the data over from WordPress to ProcessWire. I wrote a conversion script so that we could re-import as many times as needed since new stories get added to cmscritic.com almost daily. In order to get the data out of WordPress, I queried the WordPress database directly (my local copy of it anyway) to extract what we needed from the tables wp_posts for the blog posts and pages, and then wp_terms, wp_term_relationships, and wp_term_taxonomy for the topics and tags. WordPress stores its TinyMCE text in a state that is something in between text and HTML, with the most obvious thing being that there are no <p> tags present in the wp_posts database. Rather than trying to figure out the full methodology behind that, I just included WP's wp-formatting.php file and ran the wpautop() function on the body text before inserting into ProcessWire. I know a lot of people have bad things to say about WordPress's architecture, but I must admit that the fact that I can just include a single file from WordPress's core without worrying about any other dependencies was a nice situation, at least in this case. In order to keep track of the WordPress pages imported into ProcessWire through repeat imports, I kept a "wpid" field in ProcessWire. That just held the WordPress post ID from the wp_posts table. That way, when importing, I could very easily tell if we needed to create a new page or modify an existing one. Another factor that had to be considered during import was that the site used a lot of "Hana code", which looked like [hana-code-insert name="something" /]. I solved this by making our own version of the Hanna code module, which was posted earlier this week. Here's an abbreviated look at how to import posts from WordPress to ProcessWire: $wpdb = new PDO("mysql:dbname=wp_cmscritic;host=localhost", "root", "root", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $posts = wire('pages')->get('/posts/'); $sql = " SELECT * FROM wp_posts WHERE post_type='post' AND post_status='publish' ORDER BY post_date "; $query = $wpdb->prepare($sql); $query->execute(); while($row = $query->fetch(PDO::FETCH_ASSOC)) { $post = $posts->child("wpid=$row[ID]"); // do we already have this post? if(!$post->id) { // create a new post $post = new Page(); $post->template = 'post'; $post->parent = $posts; echo "Creating new post...\n"; } $post->of(false); $post->name = wire('sanitizer')->pageName($row['post_name']); $post->title = $row['post_title']; $post->date = $row['post_date']; $post->summary = $row['post_excerpt']; $post->wpid = $row['ID']; // assign the bodycopy after adding <p> tags // the wpautop() function is from WordPress /wp-includes/wp-formatting.php $post->body = wpautop($row['post_content']); $post->save(); echo "Saved post: $post->path\n"; } What I've left out here is the importing of images, topics, tags, and setting the correct authors for each post. If anyone is interested, I'll be happy to go more in depth on that, but didn't want to overwhelm this message with code. Template File Structure This site makes use of the $config->prependTemplateFile to automatically include the file _init.php before rendering a template file, and $config->appendTemplateFile to automatically include the file _main.php after. So the /site/config.php has this: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; You may recognize this as being the same setup from the Skyscrapers profile. The _init.php includes files containing functions we want to be available to all of our templates, and set default values for the regions we populate: /site/templates/_init.php /** * Include function and hook definition files * */ require_once("./includes/render.php"); require_once("./includes/hooks.php"); /** * Initialize variables populated by templates that get output in _main.php * */ $browserTitle = $page->get('browser_title|title'); $body = "<h1>" . $page->get('headline|title') . "</h1>" . $page->body; $side = ''; $renderMain = true; // whether to include the _main.php file The includes/render.php file that is included above includes several functions for generating markup of navigation and post summaries, or any other shared markup generation functions. Examples are renderPost(), renderNav(), renderTags(). This is similar to the blog.inc file from the Blog profile except that I'm letting these functions generate and return their own markup rather than splitting them into separate view files. I personally find this easier to maintain even if it's not as MVC. The includes/hooks.php sets up any hooks I want to be present for all of my templates. I could have also done this with an autoload module, but found this to just be a little simpler since my hooks were only needed on the front-end. The main hook of interest is one that makes all posts look like they live off the root "/" level rather than "/posts/" (where they actually live). This was in order to keep consistency with the URLs as they were in WordPress, so that the new site would have all the same URL as the old site, without the need for 301 redirects. /site/templates/includes/hooks.php /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } }); Our /site/templates/_main.php contains the entire markup for the overall template used site wide, from <html> to </html>. It outputs those variables we defined in _init.php in the right places. For example, $body gets output in the <div id='bodycopy'>, $side gets output in the right <aside>, and $browserTitle gets output in the <title> tag. /site/templates/_main.php <?php if($renderMain): ?> <html> <head> <title><?=$browserTitle?></title> </head> <body> <div id='masthead'> // ... </div> <div id='content'> <div id='bodycopy'><?=$body?></div> <aside id='sidebar'><?=$side?></aside> </div> <footer> // ... </footer> </body> </html> <?php endif; ?> We use the rest of the site's template files to simply populate those $body, $side and $browserTitle variables with the contents of the page. As an example, this is an abbreviated version of the /site/templates/post.php template: /site/templates/post.php // functions from /site/templates/includes/render.php $meta = renderMeta($page); $tags = renderTags($page); $authorBox = renderAuthor($page->createdUser); $comments = renderComments($page); $body = " <article class='post post-full'> <header> <h1>$page->title</h1> $meta </header> $page->body $tags $authorBox $comments </article> "; if(count($page->related)) { $side = "<h4>Related Stories</h4>" . renderNav($page->related); } What might also be of interest is the homepage template, as it handles the other part of routing of post URLs since they are living off the root rather than in /posts/. That means the homepage is what is triggering the render of each post: /site/templates/home.php if(strlen($input->urlSegment2)) { // we only accept 1 URL segment here, so 404 if there are any more throw new Wire404Exception(); } else if(strlen($input->urlSegment1)) { // render the blog post named in urlSegment1 $name = $sanitizer->pageName($input->urlSegment1); $post = $pages->get("/posts/")->child("name=$name"); if($post->id) echo $post->render(); else throw new Wire404Exception(); // tell _main.php not to include itself after this $renderMain = false; } else { // regular homepage output $limit = 7; // number of posts to render per page $posts = $pages->find("parent=/posts/, limit=$limit, sort=-date"); $body = renderPosts($posts); } The rest of the site's template files were handled in the same way. Though most were a little simpler than this. Several were simply blank, since the default values populated in _init.php were all that some needed. Front-end development using Foundation 4 The front-end was developed with the Foundation 4 CSS framework. I started with the Foundation blog template and then tweaked the markup and css till I had something that I thought was workable. Then Mike and I sent the _main.php template file back and forth a few times, tweaking and changing it further. There was no formal design process here. It was kind of a photoshop tennis (but in markup and CSS) where we collaborated on it equally, but all under Mike's direction. After a day or two of collaboration, I think we both felt like we had something that was very good for the reader, even if it didn't originate from a design in Photoshop or some other tool like that. I think it helps a lot that Foundation provides a great starting point and lends itself well to fine tuning it the way you want it. I also felt that the mobile-first methodology worked particularly well here. Comments System using Disqus We converted the comments system over to Disqus while the site was still running WordPress. This was done for a few reasons: Disqus comments provide one of the best experiences for the user, in my opinion. They also are platform agnostic, in that we could convert the whole site from WP to PW and not have to change a thing about the comments… no data conversion or importing necessary. Lastly, ProcessWire's built-in comments system is not quite as powerful as WordPress's yet, so I wanted cmscritic.com to get an upgrade in that area rather than anything else, and Disqus is definitely an upgrade from WP's comments. In order to ensure that Disqus could recognize the relations of comment threads to posts, we again made use of that $page->wpid variable that keeps the original WordPress ID, and also relates to the ID used by the Disqus comments. This is only for posts that originated in WordPress, as new posts use a ProcessWire-specific ID.

ElasticSearch does a lot, but the part that is most interesting to me is that it does an amazing job of fulltext search. It's also crazy fast. It can be a bit scary at first so hopefully this module will make it more accessible. I threw together this module pretty quickly, it's more of a proof of concept than anything else at this point. I tried it out on a site with 400 bilingual pages and the search results are much improved over the normal search you would get doing like queries or fulltext queries in mysql. Github page: https://github.com/jdart/ElasticSearchProcessWire I'd love to hear some feedback on how it works for you. It's very new so expect bugs, in particular the mechanism that turns pages into data to be indexed by ES might have some surprises.

@clsource, other interested parties I've been busy and haven't got this totally finished yet -- I still need to work on a decent method of getting these counters into a page in PW which probably means a fieldtype/inputfield. The actual counter code is, however, all done for both files and redis. Here's part of the documentation which covers more of what I posted above (essentially an escrow problem.) Any feedback would be appreciated.

I get what you say - building blocks. It's also easy and the reason I use it. Basic and to be changed when we need. I have not really changed that much, just changed some things for small mobile sizes and don't use what takes to long. Had trouble with sized PW images shrinked by foundation... I really liked the off canvas - especially the concept Facebook (among others) is using. It's apealling to the eye. Was reading on the off canvas concept and I found out, that content is loaded lazy and placed into focus when needed. It's actually a litle faster then requesting single pages because it is not nescesarry to download header and footer again. Downside is that one has to load yet another jquery for that. Now I try to focus on tabs were tab content slide in with css only (works about the same as off canvas) but is so much more fast. Just have not found a good tutorial on that. codrops has some nice examples...

, if it has chars in it! An empty string equals false.

@bwakad Essentially, if you work with pages, there are two options. Either you expect one page or a failure or secondly one or more pages or failure. $single_page = $pages->get("something"); if($single_page->id) echo "Page found"; $multiple = $pages->find("something"); if(count($multiple)) echo "at least one page found"; The first check works, because get() returns a NullPage on failure, which has an id of 0. The second one counts the found PageArray elements. If there are none it's also 0. The difficulty is not to confuse those (as I did), as NullPage is something completely different as a PageArray / WireArray.

Ugh, yes sorry. I should have actually tried it before posting. Sorry, new to PW and still wrapping my head around how everything works. I'm amazed at the functionality of the page field. I'm so used to other CMS variables that are basic and need all sorts of functionality built on top to do simple things like allow multiple selection, etc. PW is amazing.

I think it still might be a nice option, just better to check first

Blog version 2 Introducing Blog version 2! There are lots of changes so this will be a long read. For upgrading from version 1 to this version, please read the next post. I’ll appreciate beta testers. As you’ll see below, there’s lots of new things (and combination of things!) to test. Many thanks! TL:DR: Blog version 2 is available for beta testing. It comes with a two-step installer that allows you to structure where your Blog lives in your page tree just the way you want and cleans-up after itself in case it isn’t your cup of tea. Please see next post about updating version 1 to 2. Main Changes 1. Configurable Blog 2 is a now configurable module (i.e. ProcessBlog). On a fresh install, you will first have to set a couple of settings before you can run the module. More on this below. 2. Installer Blog 2 comes with a two-step installer. No more installing things you don’t want. In the first step, you set the module configurations in the module settings page as mentioned in #1. The configurable settings are outlined later below. In the second step, via the Blog dashboard, you will see an overview of the settings you selected in the first step above. Here you finalise Blog’s installation. Before you click the button to run the install wizard, nothing will happen yet. You can still go back and change the module configuration settings. Until you run the install wizard in this second step, you will have no Blog pages, fields, templates, etc. On this page, you will also be able to rename your Blog’s main pages before they are created. Yes! If you don’t do it at this stage, you can also rename them post-install in the ProcessWire tree! If you are happy with your settings, click the install wizard to proceed. Blog will be fully installed with your settings before you can dash out to make a coffee . You will then see the familiar Blog dashboard Please note: If you need to change some configurations, you can go back to the module settings and do it BEFORE you finalise step two of the installation. It is important that once the installation is finalised, in case you had left the ProcessBlog's module configuration's browser window open, NOT to press submit again. Otherwise, MarkupBlog may not like it . However, if you reload the module configurations screen once the second-part of the installer has finished, you will not be able to change the configuration settings. Instead, you will be presented with an overview of your installed settings. 3. Blog styles Blog now allows you to install your Blog pages from a choice of 4 different URL structures, aka Blog styles! These should cover most (all?) needs. This means that your Blog pages will live exactly where you want them in the tree, hence give you the URL you want. You select the style you want in ProcessBlog’s module configuration screen (first step of the installer). A visual of the 4 styles is presented on that screen. Example paths for the 4 styles are: Blog style 1: /mysite/blog/posts/example-post/ (similar to Blog version 1) Blog style 2: /mysite/blog/example-post/ (as requested by FuturShoc) Blog style 3: /mysite/posts/example-post/ (same as Ryan’s Blog profile) Blog style 4: /mysite/example-post/ (as requested by PWired) 4. Commenting feature In the first step of the installer (module's configuration's screen), you can choose to install commenting feature or not. The default is to install commenting feature. If you elect not to install this feature, Blog will not install any comments-related components – so no comment fields, associated pages, templates and template files! Note, you CANNOT add this setting once Blog install has been finalised. 5. Auto-publish/unpublish This much requested feature has now arrived! You choose whether to install this feature or not via ProcessBlog’s module configuration screen. The default is auto-publish/unpublish is not enabled. If you want to use this feature, you will FIRST have to install the great SchedulePages module. If you have the module installed, this will be specified in Blog’s module configuration screen. Again you will not be able to proceed with installing this feature unless SchedulePages is installed. If you install this feature, you will see two date fields when editing a blog post, i.e. ‘Auto-publish from’ and ‘Auto-unpublish on’. You will also see these two date fields in Blog’s Quick post’s dashboard. Note, you CANNOT add this setting once Blog install has been finalised. 6. Templates Blog will install templates according to the Blog style you have selected. So, if you went with style #4, you will not have a template called ‘blog’ nor one called ‘blog-posts’. 7. Template files In the first step of the installer (module configurations screen – I know, I am repeating myself!), you have three options when it comes to template files when installing Blog. The default is to install blank template files (with nothing but php tags – a little something to help you get started quickly). The second option is to install demo blog template files (more on this later) and the third is not to install any template files. 8. Demo template files These files have now been streamlined. No more verbose code! A blog-main.inc contains most of the markup and the other template files contain most of the code. The demo will work with any of the 4 Blog styles. 9. Cleanup One of the annoying things with Blog version 1 was not only that it installed things you probably did not need, it also left behind, uh, leftovers (templates, role, pages, fields, template files). Well, no more! Uninstalling Blog is now a two-step process. If you are logged in as a superuser, you will see a Blog menu item called ‘Cleanup’. It will lead to a screen with info about all the fields, templates, pages and role you are about to delete. It will also list the Blog template files that, if you wish, you can also delete. This utility is also useful when you want to try out the different Blog styles without uninstalling the whole Blog module. It returns Blog to the state similar to when you first installed the module. Of course, in case you want to remove Blog as well, just go ahead and uninstall in the normal way but AFTER you have cleaned-up . 10. Renaming Blog pages As mentioned previously, you can rename any of your Blog pages pre- or post-install. Want Diary or Journal instead of Blog? Sure, go ahead. Want Writers instead of Authors? What about Chronicles in lieu of Archives? You can have those too. The only things you should NOT do are to delete the main Blog pages (i.e. anything other than Example Tag, Example Category and Example Post) OR (however remote the chance of this is) CHANGE the IDs of these pages (in the database). In order to allow for flexibility, Blog stores and tracks its main pages using their IDs. 11. Fields and templates admin tag In step 1 of the installer you can choose to change the default name of the tag used to group Blog fields and templates in the admin. You can as well choose not to have any tag and let anarchy reign in your admin pages! 12. Context aware Most of the Blog dashboard is now context aware. It will only display info about Blog components that are installed. No comments? Fine, no comments in Posts dashboard, etc. Apart from ‘Posts’ dashboard, the other Blog dashboards will be labelled according to the titles of your main Blog pages. For instance, if you called ‘Categories’ ‘Classifications’, that is the name you will see in the ‘Categories’ dashboard label. Same for Authors, Tags, etc. Even Cleanup is context aware and will only list components related to the Blog style you installed. OK, so how do I get Blog 2? You can install via ProcessWire modules screen. get it on the dev branch of Blog in GitHub. It is also attached below (please use Github - it is the latest version). I thoroughly tested this but I probably missed something or mixed up my code somewhere so there could be bugs . Please help me find and swat them, thanks! Next post, updating Blog 1 to 2.

Very nice site! I want one of those tools.

what about: if ($page->parent->next->id){ // next } if ($page->parent->prev->id){ //prev }

http://www.tinyprocesshouse.com/posts/why-processhouse/

I do love to see you're busy with modules

I've created as a tool to test colors for lazy people like me, with some good changes may be helpful. Thanks adrian always motivating I've fixed it and deleted the image to avoid confusion, the code is fine.

I love this - I have been wanting easy skinning (rather than theming) for PW for a long time. One thing missing is the ability to color the entire title bar in AdminThemeReno - the menu icon and search box is a different class. Also I don't think it is currently possible to edit the sidebar colors? Only other thing is a typo - you have breadcrumbs spelled wrong. And, there are two entries for 6. Color Set 2 Awesome!!! PS You need to add a way to export/import settings so we can easily share

Sure, you can do something like this in your selector for date/time, which would return all results after the current time. find("your_date_time_field>".time()); For repeaters you want something like: find("title|my_repeater.my_field~=$q"); Hope the helps get you going.

Have a look here: https://processwire.com/talk/topic/7588-admin-custom-files/

Reno if by far my favorite admin theme. Many kudos for Tom and Ryan! The only thing I miss is a dark skin, so I'm creating one. It is in alpha state, there is a lot of details to do. I'm planning to share it here when finished if anyone is interested.

No one noticed that I forgot to save the field in my code Added it already

Use pagefield->removeAll() first then add them back.

@Diogo - cool idea using lightning.pw...I always forget that. But where is your demo?

Of course Diogo forgot to mention you sanitize the user input first .... $pid = (int) $g $p = $pages->get($pid) Seen this? http://processwire.com/api/arrays/

See the PHP code

changing the order of a page field is as easy as pushing the elements one at a time: I prepared an example on codepen using jqueryUI "sortable widget" with the "serialize" option and get http://codepen.io/diogo-ed/pen/fgazd On the pen I followed the instructions from the serialize method and used the ids of the pages after the underscore on the ID "page_123" http://api.jqueryui.com/sortable/#method-serialize The code in PW is really simple: foreach($input->get->page as $g){ //iterate all the page[] array from GET $p = $pages->get($g); // look for the page with this ID echo "<li>".$p->id."</li>"; $page->of(false); // set output formatting of $page->page_field->push($p); // push it to the end of the field $page->save("page_field"); // save page } EDIT: I'm using lightning.pw for the ajax call in the demo EDIT2: Like kongondo says, you need to sanitize the get calls. Take this only as a prof of concept. EDIT3: Added the output formatting of and save the field (forgot before)

A few updates in response to the PDF that was posted earlier. More to come, but this is a start. Currently these are just on dev, but will be merged to master soon. The main README file has been updated with a link to the HTML version at the very top. I honestly think including a README.html file in the core itself is bad form because it reveals exactly what software is running the site. Some might have noticed our README files are generally blocked from http access (by the .htaccess file) for this very reason. So I think putting a link to the HTML version of the document at the top of the Markdown file is a good compromise. The default site profile has been updated with its own README file and separately hosted HTML version: Introduction to the default site profile, which goes in depth in explaining exactly how the site profile works. The template files have also been updated, telling the user to see README.txt for more information (though not sure that's really necessary).

Have you checked the permission on the templates that are allowed as children of the template assigned to the page that you are expecting a new button on? So the parent template must have Add Children and the child template must have Edit Pages and Create Pages for the author role.

Yeah, I appreciate Ryan's feedback, as well as the others. Although I may sound a bit locked in my own vision to some people, it all actually makes me rethink me own expectations about this system, and more important: my current and future situation and livelyhood. So thanks for making me have a small existential crisis, LOL BTW Personally I don't like Wordpress at all, so I don't hope anyone suspects me of being a Wordpress fan, heaven forbid. @Nico: Did your father use the default or the Argos backend?

Code before talk. With 2.5.0 released Friday, and 2.5.1 dev released today, there's been a lot of code.

This module may get put into the core. Not sure yet. But it does seem like something that may be useful to most PW installs, so seriously considering it once it's fully refined and has a few miles on it, etc. No need to worry – if you click it, the next screen tells you that it is a downgrade. Though it's perfectly fine to downgrade or upgrade between master and dev, unless using something that's only in dev. I've been doing it all week. This is consistent with how PW currently renders all system notices: at superuser login. If it's an error, it shows up red. Otherwise it shows up green. Upgrades to core or modules in PW aren't particularly important most of the time (since it isn't WordPress). It's more just an "FYI", "if you are looking for it" kind of thing. The info is always available in Setup > Upgrades. But I hear what you are saying and you aren't the first to say they tune out PW's green messages. Antti and I are working on a new notifications system and I expect we're going to do some great things there. This module will be one of a few we use to test the new notifications system. But until then I thought it best to keep consistent with the way PW currently does things with regard to system notices. So just wanted to mention there are some nice new things coming here, but for the overall system rather than just 1 module.

Some upgrades to the upgrade module. It now scans for module upgrades too, and provides notifications of upgrades that show up when superuser logs in: Main screen: Login notifications: Note that you have to have the latest PW (2.4.19 or hopefully 2.5 later today) in order to use the modules upgrades or login notifications. The core upgrades portion will work with old PW versions. Also the screenshot says it's called "Core Upgrade", but that's because I already had it installed. If you install it anew now, it's simply called "Upgrades".

As for feature set: my aim is not to solve each and every e-commerce situation there is. I would consider this more for "small shops" at this point, haven't tought about scalability for hundreds thousands orders for example. Here is short feature lists what I have so far and what I am planning for release: E-Commerce modules: Shopping cart Support for different delivery modules (these changes whole checkout process, what fields to ask from customer, what to show after payment success / fails etc. Currently I have done "DeliveryEmail" which only asks email address from customer and then sends email confirmation with possible download links. I will implement more general "DeliveryPostage", where we ask postal addresses also) Support for different payment methods (currently stripe implemented, looking for paypal too for the release - payment methods are independent, so they can be used in other projects too than only this shop) Admin page to manage downloads Fieldtype to attach downloads to products (products are always pages) Since products are pages, support for variations etc are easy: just use repeaters or PageTable. Admin page to manage orders: printing packing slip, mark them as delivered etc... (50% done) Admin page for simple monthly reports (todo) Multiple taxes and taxes for products (todo) These E-Commerce modules are planned in a way that first you build your product catalog (just using ProcessWire) and then install these modules (only those modules you need). So in a way these are quite a "transparent" glue there. Shop profile (might implement this after the beta period): Starter profile for "full featured" shop: product template, categories, tags, product search, related products etc... Can be used as a standalone shop or just for educational purposes (look how certain features are implemented and add them in own store).