Leaderboard

Fredi is friendly frontend editor for ProcessWire. Code and documentation: https://github.com/apeisa/Fredi Module page: http://modules.processwire.com/modules/fredi/

You can enable advanced mode in config.php and then create a new template for childs. Under the fieldgroup list you see now a fieldgroup select from another template. Chose basic-page and youll have a reference. Set family settings how you need and unde advanced tab look for alternative template setting and enter basic-page. Now it uses same template file.

This module -- actually pair of modules -- keeps track of login attempts to your site, both successful and unsuccessful. The point of this is to give you better understanding about users' activity and environments they use and favor; browsers, browser features such as Flash and Javascript, devices, screen and window sizes. Based on my experience it could also prove out to be rather helpful when debugging error reports by users. Since most of this module was written during one weekend (short time for someone like me who way too often gets stuck trying to make meaningless little details "perfect") I'm very much aware that there are still quirks and even missing features I'd consider "very important." If anyone finds this module interesting enough to give it a try, any and all ideas, comments and problem reports would be very much appreciated! http://modules.proce...-login-history/ https://github.com/t...essLoginHistory How does it work? Process Login History itself is pretty simple and focuses on showing logged data. Probably only thing worth mentioning is that user agent strings are saved to database in their original format and converted here run-time into human readable values. Currently this is done with a private function that tries to identify most common platforms, device types and browsers, but I've planned to add support to either phpbrowscap and/or PHP's native get_browser(). Login tracking is achieved by hooking after Session::login and ProcessLogin::buildLoginForm, though latter is only used to add some extra fields to login form in order to collect slightly more information about user agent. Hooks are added by separate autoload module Process Login History Hooks to avoid loading unnecessary stuff all the time. I'm not sure if this naming convention is correct though.. it's not a process module but still very much related to one -- ideas, anyone? How do you use it? When installed this module adds new database table (process_login_history) for storing data and new page called Login History under Admin > Setup. What this page should look after couple of logins / login attempts is visible in the screenshot below. For more information and some ideas I've planned for later revisions, see README.md.

This module creates a page in the ProcessWire admin where you can test selectors and browse page data and properties without editing a template file or a bootstrapped script. Given selector string is used as is to find pages - only limit is added, if given. Errors are catched and displayed so anything can be tested. Pages found with a valid selector are listed (id, title) with links to the page. I was thinking this would be useful for someone new to ProcessWire, but it turns out I'm using it myself all the time. Maybe someone else finds it useful as well. Module can be downloaded here: https://github.com/n...essSelectorTest Modules directory: http://modules.processwire.com/modules/process-selector-test/ Features Edit selector string and display results (and possible errors as reported by ProcessWire) Explore properties and data of matching pages in a tree viewLanguage aware: multi-language and language-alternate fields supported Repeater fields and values Images and their variations on disk More data is loaded on-demand as the tree is traversed deeper Quick links to edit/view pages, edit templates and run new selectors (select pages with the same template or children of a page) Page statuses visualized like in default admin theme Add pagination Screenshots

Gretings everyone, I am working on a site for an arts organization, and they are looking for imaginative interactivity... I did some searching to see what various organizations and museums are doing, and discovered the Whitney Museum's "For Kids" site. I think the site has a lot of impressive elements. But the reason I'm sharing it here is because everything in there feels like a great example of what can be done with ProcessWire. Check it out here: http://whitney.org/ForKids Just a bit of inspiration. Thanks, Matthew

Hi all, I am creating a site that will have multiple users in ProcessWire and I want to be able to limit the ability to edit pages so users can only edit the pages that they themselves created. I noticed the default functionality allows you to assign roles yet anyone with this role appears to be able to edit whatever pages and templates have access to that role. Thank you for your help!

Problem here is that in order to add pages, user needs to be able to edit them too. One way to circumvent this would be a module that hooks to page::editable, checks if user has some predefined role you want to limit edit access for and (if that role is found) only grants edit access if this page was created by current user. There are other ways too, but this is probably the one I'd suggest looking into. A very similar solution is described (in more detail) by Ryan here. Hope this helps a bit.

depends on the structure of the site, but couldn't this also be done with a setting in MarkupSimpleNavigation? 'max_levels' => 1, // set the max level rendered

Well, the process module doesn't have diabled install button so something is wrong.. ProcessFredi and FrediProcess are different modules, so it can't work

You could use getItemKey() like this: if($a->getItemKey($i) % 2 != 0) But thinking better, this does the same and it's simpler: foreach ($productList as $key => $product){ if($key % 2 != 0) { // echo } ...

Good call - I have corrected the typo.

Great module, I started using it and found a little bug in pagination, see the attachment

Uh nice, a lot of little cupcakes inside your code to pick and learn from.

Ok, just pushed nice little update. It should support pretty much all inputfields now (uses their native input processing). Only thing where I am having problems is ajaxfiles inside repeater (gives me response text: "page not saved (no changes)" after upload has been done). Repeaters without images works just fine. It should be pretty trivial to build some kind of JS-switch to "show / hide" edit buttons. There is also $fredi->enabled = false that you can set if you want to disable edit links for some reason.

Permissions should be fine. I check them on field level. Marty: feel free to try. I think it might work with thumbnails already. If not, it shouldn't be a big tweak.

I'm not 100 % sure right now, but I think if you don't set a name, Pw takes already care of this problem. Edit: Yep it does, found the code in Pages::___setupNew() protected function ___setupNew(Page $page) { if(!$page->name && $page->title) { $n = 0; $pageName = $this->fuel('sanitizer')->pageName($page->title, Sanitizer::translate); do { $name = $pageName . ($n ? "-$n" : ''); $child = $page->parent->child("name=$name"); // see if another page already has the same name $n++; } while($child->id); $page->name = $name; } //... So just set the title. If the same title appears multiple times, the API generates a name with -1,-2,-3...

Big thanks to Mats for the alltpaoland.com example and his clustering updates to my RCDMap class. With these available, I was able to learn enough (and admittedly copy enough!) to make the map project come together: http://www.synbioproject.org/library/inventories/map/ ... my code is a little messy, but it all works for the deadline, and I can go clean it up later. Beyond Google Maps, tools used here are jQuery Mobile, ProcessWire 2.3, ImportPagesCSV module, and ProcessWire Form Builder (for the add/edit map submissions). Thanks again Mats! I don't think I could have made much progress without your alltpaoland site as an example/guide.

A couple of tips when moving from Joomla. 1. Forget the idea of Categories and Articles. To be honest, Joomla is more of an Article Management System than a CMS (until you add tons of components) and so it has a very restricted way of looking at things. 2. ProcessWire uses pages as data containers - exactly what data is up to you. It could be a page made out of lots of fields, or pages could be lots of alternatives for a select field (pages field in PW), they are also users and all kinds of other things. So, try not to think of them like pages in a book or even web pages - though they can be both of those if you wish. 3. When you design a site with Joomla, the easiest way is to change your site to work how Joomla wants you to work. But, the best way to start with ProcessWire is to not think about PW at all, but just think of your website. Try and ignore how PW works and just work out how YOU want YOUR website to work. Once you have done that, you can work out how PW will help you achieve what you want. It really is that flexible. You can create anything that is familiar in Joomla in PW. For instance, Once you do the Basic Website Tutorial that Kongondo mentioned, there is a link at the bottom to the Simple News System. This shows how you can do Joomla type articles with categories. But you will quickly realise that this is only one way you can achieve that, and because you are doing it yourself, you can make it work anyway you wish. So, Welcome, and have fun!

You can' specify multiple roots, but you can exclude children. $options = array("selector"=>"id!=1003|1004"); echo $navTree->render($options); So the pages with those id's wont be rendered. Or you could add a checkbox custom field to the templates to only include them if checked from the navigation. $options = array("selector"=>"show_in_menu=1"); echo $navTree->render($options);

You can set your own hotkey is the modules settings. I know windows uses ctrl+s is, so you have to use something else. It's not easy to decide easy hotkeys that work on all platforms and browsers so it is configurable, backdraw is ideally it would also need to be configured per user and not as simple to do as it is now. It's appreciated if someone likes to take the challenge, I'm happy to collaborate.

WillyC's solution is a good way to go if you have this need. But want to mention that the whole idea of multiple routes to a page kind of goes against the grain of the ProcessWire philosophy. By design, there is only one URL to any given page. This is different from systems that disconnect their data from URLs (Drupal, EE, etc.). ProcessWire considers pages like files on a file system. We are trying to embrace the way that the web is addressed rather than counter it. I understand the desire to make a shorter URL for a given page, and that's a fine reason to implement a solution like this (and I've done it myself too). But the reason you don't see things like this outlined in the documentation is because I don't think it's a best practice, whether in ProcessWire or on the web in general. So if someone uses multiple routes, I would suggest it only to solve a specific need after a site is produced… not as something to build around from the start.

Another way you can go is to use page reference fields. Add two new 'Page' reference fields: topnav and footnav. Make them support multiple pages. Don't restrict it to a parent or template. Select 'PageListSelectMultiple' as the Inputfield for them. Save, and add them to your Homepage template. Now edit your homepage. For the 'topnav' field, select all the pages you want as part of your top navigation, and for the 'footnav' field select all the pages that should appear in your footer navigation. Drag to sort them in the order you want. Edit your main markup file (or head/foot includes) and use the following code to output that navigation: <?php foreach($pages->get("/")->topnav as $item) { echo "<li><a href='{$item->url}'>{$item->title}</a></li>"; } …repeat the same for the footer nav, except iterate the footnav (rather than topnav) field. In the sites that I develop, I almost always have the footer nav hard coded in the main markup file (I don't usually need it to be dynamic). For when I need the topnav dynamic, I'm usually sticking to the site's root level structure for the navigation (iterating the non-hidden children of the homepage). You may need all this stuff to be dynamic, in which case there are a lot of options. But I just wanted to mention that you should only make stuff dynamic that needs to be. When stuff can be hard coded in a template file, it consumes fewer resources. So if you stick to a policy of hard coding stuff that changes rarely and doesn't need to be dynamic, then you'll benefit from better performance, use less energy, save more trees, etc.