Leaderboard

Just today I relaunched http://barefigur.es/ It’s now powered by ProcessWire. A bit of history: I launched Bare Figures in January 2012. Originally it’s a site for visualizing Apple’s quarterly results. Charts are being rendered by Highcharts JS. In the first few months after the original release I did all manually (actually also creating the JSON file by hand). After that I used a bare-bones SQL database for inputting the data and a PHP script generated the JSON file to feed Highcharts. Now Bare Figures is powered by ProcessWire (and it feels just absolutely right, I love it). I created a module that generates the JSON files and now the site is, of course, also scalable, which means I can add more companies to the site (the first one besides Apple is Google). I plan to add many more in the future. What do you think?

The beauty of it is when you realize that you can do absolutely anything with PW if you keep only these two concepts in mind: everything is a page the cheatsheet is your friend not a lot to learn, hein?

Greetings, I will agree that WordPress comes up a lot with clients. Probably every week I talk with a potential client with a WordPress site he or she wants to re-do. Because WordPress is so ubiquitous, many clients don't seem aware of other options. Of course, these days, I make my best pitch for remaking the site in ProcessWire. And the pitch works often enough! For those who refuse to budge from WordPress, I increasingly suggest they go to someone else. The only other major tool in my design/develop arsenal these days is a PHP framework (shift between Laravel and CodeIgniter), but ProcessWire is rapidly replacing that as well! My experience and interpretation of the situation: 1. If you're an independent developer, how popular WordPress is shouldn't matter too much. There is enough work outside WordPress. 2. It's up to each of us -- and the ProcessWire community -- to develop statements we can use to show clients the advantages of ProcessWire over WordPress (for example, explaining that ProcessWire is a CMS but built to be as flexible as PHP itself, and PHP is the language that WordPress is built with). 3. Clients often don't actually "choose" WordPress the way a designer/developer chooses a CMS. It's just that WordPress was the first and biggest thing they saw when they typed "blogging software" into Google. 4. There are a good number of clients out there who started using WordPress because they just wanted a blog, and now that they want more than that they are aware -- even as non-techies -- that WordPress is still meant mostly for blogging. 5. You can have a good life as a designer/developer without WordPress. Even if the stats trickle down, 81% of the time the situation does NOT include WordPress! Thanks, Matthew

@Zahari: you're not alone with these problems -- just take a look at this thread if you haven't already. I have to agree that PW can be a bit intimidating, especially if you're coming from a system with very different concepts in play For me two main reasons PW made sense right away were that it was all PHP and the API really feels a lot like jQuery, my go-to JS library for doing.. well, anything. At the moment I'm learning AngularJS, which is totally different from jQuery and I'm having similar issues: even as it sometimes feels really awesome ("what the.. I just changed this model here and that UI element there updated by itself.. way cool!") other times it just frustrates the heck out of me, especially when trying to stick with the "AngularJS way" ("where's that bloody .on() when I need it?") I used WP for a long time for building blogs and very simple websites. For that it was awesome, but had I ever been asked to do something more complex with it I'd have been really worried. What I like about PW is that it is much more like a framework that can be used to do anything than out-of-the-box super-polished CMS that does X very well. If you just want to do one specific thing, such as build a blog, consider starting with a specific site profile instead. One thing that always makes me flinch when I hear people talking about WP is it's notorious reputation when it comes to security. Being popular and having WP's feature set (registration, commenting etc.) doesn't really help, but excuses like that only go so far. I've seen whole servers compromised simply because someone forgot to upgrade an old WP installation or to follow those mile-long guides on how to make your default installation secure. Security should be built-in, not something optional or -- even worse -- something that users are tasked to implement themselves. That's just bad design no matter how you look at it. Edit: @Zahari, you mentioned seeing some "missing blocks" you'd find useful in the docs. Care to elaborate that a bit further -- what are these missing things? Is it something we could possibly add there?

Just found this thread and my name mentioned in a few places Thank you. I still use MODX among a bunch of other platforms, and I'm getting more and more into Processwire I don't have much to add to this thread except that I do worry. One of the main reasons given for SiphonLabs was to help the core devs make money to support MODX, and one of the things mentioned most frequently was that MODX had only two core developers, Jason and Shaun. Now that Shaun has left (I think he mentioned on Twitter that he's working for BigCommerce now), that means only one developer left working on the core. Yes there are other devs working on addons, but Shaun was one of the major architects. Anyhow, that's neither here nor there and is a topic for the MODX forums. Just thought I'd drop my 2c and say thanks for the few random mentions

The PagefilesManager::url() method is now hookable on dev. For high volume functions like this, I go a little further than just prepending 3 underscores and instead implement both a hooked and non-hooked version, just to reduce any potential overhead. Meaning, PW's hook system doesn't get called upon unless/until the function is hooked. Not sure it really matters, but it's just a minor optimization.

PAGES: Yes, everything is a page. There's a topic that explains this approach but I can't find it atm. A page is an abstract term; it doesn't always map 1:1 with a web (or book) page. Being abstract, it can be used for various tasks including storing data, displaying content, etc. Have a read here too. CRUD: There's Batcher (check in modules) and this current discussion GLOBAL HEADER/FOOTER: There are various approaches. One is create pages to hold the information (respectively) and call those pages in your templates. See also the PW default install template files and this topic plus this in the docs. FIELDS: Templates help group your fields together. This is a big topic. Have a read here. Note that fields are reusable and are all custom; there is no required field in ProcessWire (although each page must have a name but that is not a field you create; it comes with the system). Templates can share template files, can have their own template files or can have NO template files Confused? It all depends on what you want to achieve. See this topic and this in the docs. Bottom line; if you want a page's content to be visible in the front-end, that page must either use a template that has a template file or that page must have its content pulled into and displayed by another template file. Gotta go. Meanwhile, you could search the forums for more info as others chip in. You might want to search this forums using Google; it is better than the forum board's search

In some previous posts, I demonstrated a simple proof-of-concept CRUD “application” for PW using jTable. I really wanted to use DataTables since it is older, wiser and with a huge fan base. One thing I wanted was for the CRUD system to be as simple as possible and possibly be Excel-like (more below). With DataTables plugins, you can perform stuff like inline-editing and Auto-fill. The latter works just like in Excel and allows you to quickly populate cells (quick copy). But that’s as far as it goes. Google led me to other Table management systems. Some of the front runners include jqGrid and SlickGrid. SlickGrid is nice and using virtual rendering can display millions of rows with ease. Its support for displaying data delivered on demand (Ajax/server) is minimal; it requires you to download all your data before it starts manipulating it. Someone has created an Excel-like extension for it allowing copy-pasting between SlickGrid and Excel. Awesome! But, it still didn't rock my boat completely, especially the Ajax content issue. Then I stumbled upon Handsontable, a new kid on the block that describes itself as “a minimalistic Excel-like data grid editor for HTML, JavaScript & jQuery”. Though relatively new, it is as Excel-like as you can get. You can copy-paste from/to Excel [single to multiple cells and multiple to multiple cells], use the usual shortcuts (Ctrl-A, Ctrl-X, Ctrl-C, Ctrl-V, Ctrl-Y, Ctrl-Z - i.e., undo/redo, etc., and tab navigation, etc.), use Auto-fill (vertically and horizontally), freeze cells/columns, make cells/columns read only, Right-click context menus, insert/delete rows and columns, perform inline-editing, etc. Double awesome! Handsontable (HoT) is minimalistic but comes with a rich API. However, most of the implementation is down to you (sounds familiar?). It will render the Table and provide you with Methods/Events/Options to manipulate it. You just have to provide the data as an Array or JSON defining your columns and containing your data. Soma has a DataTable module that is currently read only; you cannot edit the displayed data directly in the table. It is also in lazy development . So, I started toying with the idea of using HoT as an Excel-like CRUD system (module) for PW. I wanted something that could quickly and easily do mass editing (Batcher-like). Imagine quickly creating basic pages/records by copy-pasting from Excel. Or quickly changing records by dragging (Auto-fill) or pasting new values over old ones. Well, the result can be seen in the screencast below. I’d like to hear your thoughts whether this is something that I should consider developing into a module; something that could be used by Superusers. Depending on implementation, it could be used by other users as well. All HoT needs is data. What you do with that data is up to you (the developer) and your code! This can be very dangerous if not implemented correctly, of course! You could easily delete important records! However, HoT does not touch your database! Deletions, insertions, etc., will not alter your database unless you specifically write the PHP code to do that. All it does is send data to the server via a method your specify (post, get, Ajax, etc.), and even that is your implementation. You do not need to implement deletions or additions. You can use it for updating content only or as read only, but where’s the fun in that ? In the screencast , apart from the table itself, all the other implementations are custom - the buttons, selects, auto-save (can be tricky? can DDOS your server?). The current implementation is not perfect; it is a demo after all. Certain stuff would need to be implemented differently . I didn't want to spend too much time on something that would not be useful in the end. All CRUD operations are via PW API and/or vanilla PHP. Deleted pages are Trashed and not permanently deleted. If there is interest for a module of this kind, I would request all the help I can get to develop it please. I would put it up on Github of course. In the demo, this is running off Diogo’s ACP module. Let me hear your thoughts please. Should a module like this see the light of day? Thanks Wasn't sure in which forum to post this...

I ran my tests attaching them statically too, but it doesn't make a difference. I will try bundling them into a module (rather than anonymous functions from a template file) to see if it makes any difference. But two suggestions I have here are: 1) attach your hooks in an init() method, rather than _construct(). ProcessWire may still be booting when your _construct() is called. Though in this case, I doubt it makes any difference, but I would try that just in case. init() or ready() is typically where hooks are attached (initializing connections with external things), whereas _construct() is for initializing internal things. init() is called before the current $page is known, and ready() is called after it is known and available as an API variable. In your case, init() is the right one to use (though ready() could also be used). 2) after moving them to an init() method, switch to using non-static -- attach directly to $this->fields and $this->templates (the API variables). Static hook attachments are only necessary for objects that might have more than one instance, like Page, User, Field, Template, etc. But there will never be more than one instance of Fields or Templates, so you can benefit from slightly less overhead by attaching them directly to the API variables.

If you want more control over your images trown in with WYSIWYG. And you want captions for landscape or/and portrait or both. Maybe you can take a look at TextformatterImageInterceptor. The text formatter will recognize image orientation. (also recognize image tags if tagged sets are used) If you wish, add a class for the caption div and the caption wil be created underneath the image with the classname you specified. So basicly you have image caption control over different kind of images. There are other settings like cropping, sizing, positioning and wrapping images. Will not cover the details here. And maybe there's to much overhead ( server side ) using my module for just captions. about the textformatter: forum post <blink>advertisement</blink>

Great info and superb presentation! As a number addict myself I really dig this kind of info. Also very nice of you to show ProcessWire in the footer. Would you consider writing up a case study on how you approached this excellent website?

This is really awesome! Never heard of this plugin before. I'm thinking of integrating Handsontable into Batcher, there are some other feature requests pending I wanted to integrate sooner or later. Kongondo, are you already developing a separate module? What do you think? Cheers

i think: wow! (and feel like an idiot because i didn't buy those google shares back in the early 2000 years ...).

I'd be very happy if you could do that -- would love to explore this concept a bit further and method I've posted here is nowhere close to "clean"..

I thought that the MODX move was interesting too (as were the EE changes a few months earlier). I don't think it affects anything about ProcessWire, other than that it seems to drive more users here. We won't be following the path of MODX, in case anyone was worried. We get paid by the sites and apps that we develop with ProcessWire, and by the commercial support of modules like FormBuilder and ProCache. I don't have any inside knowledge on the changes at MODX, and may not understand the full scope of them, but here's my outsider opinion about it… I can understand why it is shocking to folks that use MODX, because it kind of destroys the perception of MODX as being a big and stable player. In my mind, they were a big and successful company, and I think that was a lot of other people's perception too. Why would they ever have to rely on a little hosting company with a toilet name and an HTML5 logo? MODX is way above this, or so I thought. The changes instead reveal reality that's probably always been there… MODX is a labor of love rather than profit, as most open source projects are (including us). But MODX has grown big enough in user base that keeping the whole ship afloat means having a team people that dedicate lots of time to it. These people have to be paid in order to take care of their own families, etc. So it looks to me like they are just making the tough decisions necessary to keep the team together and stable. It's not pretty (especially the Siphon part), but digging up the floor to fix the plumbing never is. WordPress has proven that hosting is a safe and viable business model to sustain a big open source project. Supporting other CMSs on the Siphon platform is probably just about risk reduction (put the eggs in a few different baskets… err, siphons… rather than all in one) and it would probably make a lot more than it would cost. None of us should view CMSs as religions. I'm glad that I can run Windows apps on my Mac now, when I need to; that doesn't make me prefer Windows. I'm not sure that having web hosting that can only run MODX would be worthwhile. The value proposition with WordPress hosting (which can only run WordPress) is entirely different. Most people using MODX (and ProcessWire) are professionals that have multiple tools. Most people using WordPress are consumers that know how to write, but don't know anything about web development. Given the different audience, I don't think MODX could duplicate WordPress's hosting success by only hosting one product. But I do think they can be successful by catering to the needs of the audience, which is rarely glued to a single product. If diversifying the eggs among multiple baskets helps to drive development for MODX, then that can only be a good thing. Hopefully that's their intention. If their reality really is as it sounded, then the changes were probably good, even if shocking. I think the fear that people might have is that this is somehow driven by investors trying to monetize the software for themselves. But that just doesn't seem to add up in this case. Instead it presents a lack of sustainability in their existing system that had to be fixed (which is itself shocking). I'm just surprised that: 1) They aren't as big and successful as I thought; 2) They don't have a stronger source of income; 3) Any of this was necessary; and: 4) They told us. I don't think that folks should abandon MODX because of the changes. Their team has put themselves in a vulnerable spot and we should support them. While I don't totally understand their changes, it seems like they are doing this to find sustainability more than anything else. While I support and wish the best for MODX in their changes, I also want to be clear that we will not be following that path. We're already on a beautifully sustainable path here, thanks to all of you.

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.

erm foreach($pages->find() as $p) { echo "<p>{$p->url}</p>"; } returns nothing... but foreach($pages->find("*") as $p) { echo "<p>{$p->url}</p>"; } returns all. While... foreach($pages->find("has_parent!=2") as $p) { echo "<p>{$p->url}</p>"; } would exclude pages under "/processwire/" admin pages. But maybe something also some restriction to template(s) would be good. foreach($pages->find("template=basic-page|article|news") as $p) { echo "<p>{$p->url}</p>"; }

Interesting topic! I use the following - Dropbox - as you mentioned - I have been using Dropbox since it was in beta and received the invite from the founder. Freshbooks - Tracking expenses, invoices, time tracking - http://www.freshbooks.com Asana - Project management and tasks - http://www.asana.com Evernote - Notes - http://www.evernote.com Google Calendar/Gmail Wunderlist is pretty good on Mac - http://www.wunderlist.com Jason

And if Diogo's solution gives you too much pages (admin pages, users, roles etc), then try these: $pages->find("include=hidden"); // or $pages->find();

I'm in a restaurant now, will come back on this topic tomorrow. I love all the input you give! Lets make an awesome module. Today we go for a few days to bratislava, so I don't know if I have the time to come back on the topic within the next few days. ps, I removed the pattern for the inline style at all & updated the source code on git.

Hmm... well if they share most of the code then this might be a candidate for a module that contains the core functionality for CRUD and PW pages, then an add-on module for external DBs? You wouldn't want to be duplicating too much code - have a look at dependencies if you've not read up on that already: http://processwire.com/talk/topic/778-module-dependencies/ - then you can fire up the main module from the external table version. You might just find though that it is easier to make it as one module (I suspect this might be the case actually given the chance of code duplication).

Ok, I just installed your module but I don't want to use the percent, width etc settings. I really just want the captions option. So, I emptied those dimensions fields, but the width is a required field. Can you have an option to disable this part of interceptor's options? Also, noticed that it resizes images up. I wonder if those dimension settings should be max so that images will only be sized down (or at least make it an option) - sizing up could result in some blurry images. Minor text correction: Append the style attribut to images. should be "attribute"

No worries about using $page as the variable name - I just didn't look back far enough. I see the preg_match_all and the logic you have for getting the id of the page where the image is from. Seems to me you have a great solution in this module - thanks!

Not heard of that one. Is it a comedy? Or perhaps a horror movie?

Most of the tutorials I've read, I've not been able to really understand how they work and end up getting lost trying to get through them. I don't think it's the fault of the tutorial–I've never been able to learn from tutorials of any sort. I learn by reading the docs and then tinkering with a working example... that's the only thing that seems to work for me. But I recognize that people learn in different ways, and many like tutorials. But I can't vouch for any tutorials I've not personally written. If anyone finds that any of the tutorials have errors or something that doesn't work, let me know what to fix. In your case, it sounds like you are now simply trying to manage categories. You don't need a repeater for this unless you need to define other fields together with the category. Chances are you would be better off not using a repeater and instead just using a Page reference field (perhaps with the asmSelect input). I'm also wondering about the naming, with items having "_01" at the end. That seems to imply that there might be a "_02" and a "_03", etc. This would be pretty unusual for field naming. Chances are you instead want a single "categories" multi-page reference field (which is the default behavior of the "Page" reference field).

I just uploaded a new version with logging and a fix for the issue Ryan described. @ceberlin and Pete I hope you can install this version this version with logging enabled (logging can be enabled in the module configuration). Every automatic (un)publication will be logged in the /assets/logs/messages.txt file, with timestamps for the publish_from and publish_until fields and the timestamp of the event itself. If the problem still exists, we can take a look at the logfile. /Jasper

This is the "modx" internal cache. In Pw, this is compareable with the Template Cache. However, if you have no template cached, then there's no cache to clear in Pw. But each browser has its own cache to load pages faster. Sometimes when changing assets like CSS, JS, Images etc. it's good to clear the cache to make sure the changes appear.

If you have another admin theme than the default, then your logo is in /site/templates-admin/ not /wire/templates-admin/. Otherwise clear the cache or realod your page 10 times fast

That would be really great. Seeing how to structure things like this, might be helpfull to others building less sophisticated systems. It also shows why ProcessWire isn't your regular old CMS and how powerful it can be.

Hey arjen, thanks a lot! Jep, I consider doing a detailed case study.

There is already a log module for Processwire in the directory that will help - can't remember the name at the moment (on my mobile) but it logs admin actions or page alterations or something. It created a LOT of logs in conjunction with this module - dozens of pages where it published and unpublished pages. I hope I still have the logs, if not I'll reinstall both modules and let you know as I've been having this issue too.

RE all pages in the tree looking the same, this module Template Decorator might interest you: http://modules.processwire.com/modules/template-decorator/

Hi, I try the move the discussion over to the module's thread and will reply there... http://processwire.com/talk/topic/711-release-schedulepages/page-3

Hm, yeah, just making the tab is dead easy. I just made a new page under the hidden "Admin" page, published it, and I had a new tab. But it is asking for a process to associate with. So what I would recommend next is reading Soma's post, here: http://processwire.com/talk/topic/1272-new-page-nav-in-admin/#entry11276

MODX did teach me a lot too. With PW I have learnt even more and am steadily moving from designer to semi-developer if there's such a thing PW has encouraged (not forced) me to move in this direction and the journey so far has been thoroughly enjoyable. It's so refreshing to type code, throw in some logic here and there and to see the results displayed! Anyway, I digress. You've made the right choice to start using PW. Enjoy!

That should be very possible. First look at the csv file you are throwing at it, then look at any possible formatters you apply to the field in question. It seems like some html entities problem. (tip: for html contents don't apply formatters?)

Problem with deleting all a user's posts & replies is that can break up the conversation flow. Better to leave posts & replies and to mark them as by 'Deleted User'? (Or maybe change username to user id - i.e. anonymise posts, but leave them in place.)

Hi dhruba, Welcome to PW and the forums! There has been talk about a forum module for PW but nothing has materialised so far. There's these topics that could be of interest: http://processwire.com/talk/topic/3536-forum-integration-module/ http://processwire.com/talk/topic/572-release-discussions/ Could be relevant: http://modules.processwire.com/modules/fieldtype-comments/ http://modules.processwire.com/modules/process-latest-comments/

Unless something has changed since then, it would appear that this can't be changed that easily. See this thread for a possible solution and Ryan's explanation.

The name of the default language can't be changed in Pw, but the title. If you have changed 'default' to something else in phpMyAdmin, then maybe that's causing the error? Try to change the value to 'default' again. Check the name fields in your home-page (under the settings tab). I guess that the Dutch name has the value 'start' there.

You're welcome! If you just load the page for editing, then isPost is false. This means that the JqueryWireTabs get loaded. I belive the reason behind the check is that if we're dealing with a save-request, there's no need to load UI stuff like JquerWireTabs, because Pw does a redirect after the save. $this->isPost is used multiple times in the module, so it makes sense to save this long boolean expression in a variable which is easier to read.

there are only two reasons i can think off for this imho: these people don't need what you have to offer. they find it nice-to-have but not necessary. focus on clients who have a benefit for their business from your work and make clear what this benefit is. don't try to sell refrigerators at the north pole. even millionaires don't pay for something they don't benefit from. they have somebody who delivers the same quality for a cheaper rate. make clear what sets you apart or get better in what you do - that's hard but i'm afraid that's the way it is.

Glad to hear this. We have so many here that are part of the MODX community too that it seems like a family, and I really want to see MODX do well.

Too... many... toilet references... ryan But yes, I instantly thought of plumbing too and agree with someone's comment on the MODx forums about the logo being reminiscent of the HTML5 and Magento logos. I think the only logical reason for another name is the fact that the new service will host other products such as WP, but it would have been nice to somehow keep it similar whilst descriptive somehow (xhost.com is for sale by some cyber-squatting domain holding company for example). That aside, the need to raise money through one service or another to keep a team working is just something that happens when many open source projects get to a certain stage from what I can tell. At some point during the lifecycle of a few of the projects I've kept an eye on, someone ends up working on support full-time or on coding full-time, and there needs to be a source of income at that stage. Usually the full-time coding side of things comes when the project attempts to add something massive as part of the core or rewrite all of the code every few years, but we're blessed with ryan developing optional modules to add functionality and having created a wonderfully abstracted API which allows for code changes behind the scenes and a set of API commands that will change very little if ever in most over the years and not break backwards compatibility *finally takes a breath*. Commercial support is a subject that has cropped up elsewhere on the forums in the past so that is about the most corporate thing that I can think of that might be on the horizon for ProcessWire as several devs have enquired about it, but that's a topic for the future, is something that doesn't affect 99% of users and doesn't affect the usual support on the forums anyway as it's all about paying for SLA's by web dev companies and... businessy stuff... (sorry, it's late and my brain is clouding over with a headache ). I've not been keeping up with MODx in recent years, but whilst they have always had a small, core team of devs doing most of the work I think a lot of ryan's impression of them being a big company may come from an active community (we're getting there as well, definitely!) and a smart looking website (nothing wrong with ours, just picking a description for theirs). Their website when I first discovered MODx definitely said "open source" to me: http://web.archive.org/web/20080103101906/http://www.modxcms.com/ whereas the current one is simply more businesslike and makes them look bigger despite it being more or less the same core team as 4 years ago. I wasn't really going anywhere with that last paragraph other than to say that it's difficult to gauge the size of the team or the capital behind a project from looks alone as the two are worlds apart - and there was a friendlier design in between that one and the current one too that reminds me a bit more of the current ProcessWire site and I think they should have kept for longer: http://web.archive.org/web/20110208164501/http://modxcms.com/ Whatever changes are made to any project, if they're big enough then some people won't like it. A lot of people just don't like change, but much of it can be alleviated by releasing a comprehensive FAQ when such changes are made as it prevents much of the speculation that so quickly spirals out of control. Anyway... my train of thought has pulled into the station and I think that's my lot for the night

I have to admit that I like learning from videos and books. They help to get across bigger picture concepts much better than copying and pasting. They build a foundation. So when it does come time to writing code (or copying pasting it), you've got the understanding of it. The problem with copying/pasting is that it's like building without a foundation, which can be dangerous. When you've got the foundation, all the other pieces just kind of fall into place. I think this is especially true of ProcessWire. If you understand the big picture and how simple it is, the rest of it becomes simple as well. And there's no reason not to learn the foundation, because it's so darn simple. It seems like a lot of people start working with ProcessWire while thinking of it in the context of some other CMS. So there is inevitable "un-learning" that has to take place, as people are looking for complexity where there isn't. This is a recurring theme. What I think would do an even better job of establishing the foundation would be two printable PDF documents that are maximum 1-printed page each: ProcessWire in a nutshell, a cheat-sheet – Covers everything you need to know to understand a typical site profile. Pages, Fields, Templates, then $page, $pages, and PageArray. All you need to know about PHP to use ProcessWire – This one would focus on the general PHP concepts necessary to use it like a template engine with ProcessWire. Covers things like PHP tags, double-vs-single quotes, echo, if(), foreach(), and comparison vs. assignment.

Mark, I don't know where you are having trouble, but PW is really easy to grasp. I can tell you that my first step was to print all the docs from the API and read them in one of my favorite places (on a coffee table by the river looking at the ducks). Once you understand the API everything will seem possible to achieve

Hello kongondo & welcome to the PW forum. Whilst I agree that Ryan's produced an amazing product in ProcessWire I think it goes beyond just the software. Of the CMS devs I've been involved with Ryan's the one project lead who has been the most open, from first contact, to meaningful contributions towards the site, docs, forum and code. Some others have been open, most friendly, but none to the same degree. Consequently he's attracted a welcoming, talented & professional group of people to the project and I've learned a lot from being involved here.

Welcome aboard, For your safety, please take a moment to listen to this important message about safety on board. In preparation for departure, fasten your seat belt by placing the metal fitting into the buckle. For your comfort and safety, adjust the strap so it fits low and tight around your hips. To release your seat belt just lift the face plate of the buckle. As you know, turbulence is sometimes unexpected so we advise you to take a look at Somas Cheatsheet, you will find a copy under your seat (http://processwire.com/api/cheatsheet/) On behalf of all of us, we wish you a very pleasant flight. Thank you, for choosing ProcessWire.

Hey rob. What diogo said. You can create a admin page using the "admin" template. It would be placed under the locked "admin" page tree. The admin template has a field "Process". After creating the page you'll see it under tab "content". Now you have to create a process module to serve functionality for the newly created admin page. Once installed it can be selected from the field "Process". I did a quick example that shows such a module, and even how to use the ProcessPageList module of processwire to create a tree. The id set will be the parent page (your Architects) for example. ProcessPageListCustom.module create the module under /site/modules/ and install it. <?php class ProcessPageListCustom extends Process{ public static function getModuleInfo() { return array( 'title' => 'Custom Page List', 'summary' => 'List pages in a hierarchal tree structure', 'version' => 100, 'permission' => 'page-edit' ); } public function execute(){ $pl = $this->modules->get("ProcessPageList"); $pl->set('id',1001); // or any other parent page return $pl->execute(); } } You can, of course, use any code to generate a list of pages.