Leaderboard

Case Study: SignificatoJournal.com: Migrating from MODX Evolution to ProcessWire Contents: * Useful MODX Fields * Custom Template Files * Template Chunks * Field Chunks * Snippets * The Writer Table * The Migration Script * URL Replacement * Image Migration * TinyMCE Code Breaks * Post Migration Data Checks * Link to Script Content I just finished migrating the magazine site that my wife and I run (http://significatojournal.com) from MODX Evolution to ProcessWire. How I did it may be of interest to other MODX users that wish to migrate their sites to ProcessWire. I liked MODX because it was so flexible. My experience with ProcessWire has been that PW is even more flexible than MODX, and it breaks the 5,000 page MODX Evo barrier that was the great bugaboo in Evo. I attempted to use MODX Revolution multiple times but was very unsatisfied with the slowness of the editorial interface. There were also other reasons that I left MODX for PW, that have been addressed by other writers. After using PW’s API to build a large web app in 2013 (which will be a different case study), and now, after having migrated my magazine site to PW, I’m absolutely thrilled with ProcessWire. I could go on and on... There were many things that I liked about MODX Evo, that provided functionality that I wanted to continue to use in ProcessWire. They included: Chunks, snippets, and a combination of built in MODX fields and custom template var “fields” that I created for my former website, including: Useful MODX Fields MODX Fields: longtitle (headline) pub_date introtext (summary) template (id of custom template) menuindex menutitle hidemenu (show in menu) * In PW, I use the three menu fields to create the menu of the site, using Soma’s excellent module “MarkupSimpleNavigation”, with code like this: 'selector' => 'show_in_menu=1' * I use the publish_date field to block display of pages with future publish_dates, as well as to show the actual date of publication set by the editor (not just the date of the saved record). Custom Template Var Fields: subtitle writer_id static_author static_author_attribution newsletter_volume_number headline_thumbnail article_type sitemap_exclude code_blocks1-7 Custom Template Files MODX Evo allows one to assign a custom template file to each article, which I found very useful. Unlike PW, MODX Evo uses a primary static data field set for each article, with custom fields added on as “template vars.” The advantage of the custom template files is that it allows one to use different display templates for different types of articles or section pages. I generally use a four level method of: - home page - multi-section page - section page - article page Given PW’s method of creating virtual data tables, aka template “field sets”, with display template files assigned to each template field set, I had to work out a method to have the same type of flexibility of assigning display template files to each page. For example, an article page might be a regular article page, with writer information, or an “article_plain” page, like a Contact Us page. A section page could be a multi-section page, with a list of sections, or a paginated section page that lists articles. I also had a need for custom section pages, to display articles based on “content_tags”. My solution was to create generic PW template data field sets, that all ran one php template file called “custom_template_controller.php.” The two main PW template field sets are: * article_page_structure_permanent * list_page_structure_permanent Using this method, when a new page is created, I select the PW data template first: and then, once I’m in the main set of fields, I select the custom template file for that page: The custom_template_controller.php is very simple, and simply pulls up the custom template file assigned to the page, and runs it: <?php ################################################################################################### # custom_template_controller.php ################################################################################################### include("./inc_vars.php"); include("./inc_functions.php"); #.................................................................... # block future publish dates; don't block home page (id 1) if ( ( $page->id == '1' ) || ( ! empty( $publish_date ) and $publish_date <= $now ) ) { # page can be displayed } else { wire(session)->redirect("/http404", false); } #.................................................................... include("./$custom_template_file"); ################################################################################################### The "./inc_vars.php" file gets the value of the field: $custom_template_file = $page->custom_template_file->select_value; and also initiates a variety of variables and template “chunks”. Template Chunks MODX Evo allows one to define “chunks” of text that can be replaced in the templates or in data fields, using {{tags}} that are replaced at run time. In PW, I divided the chunks into sets of templates chunks, and a smaller set of field chunks. Because of the way PW uses PHP as its “templating” language (which I REALLY like), I decided to simply place the template “chunks” in a file called "./inc_vars.php", and define them as normal PHP variables. Since that file is loaded before every page, the variables are available to use in the custom template files. Field Chunks For field chunks, I created a PHP function that loops through a set of “chunk” data pages and looks for corresponding tags in the body field, and then replaces them. I placed the “field chunks” branch of data pages under a hidden master page called “elements”, which I also used for custom selects like the custom_template_files. The field chunks use the MODX delimiters of curly brackets {{chunk_name}} and the contents of the chunks are replaced. For example, “{{email.pfb}} is replaced with an image of the email address as the title of a clickable, Javascript encoded mailto: link. In MODX, the field chunk system also allowed one to replace tags in text fields of data coming from template vars (custom fields). I found that my primary need for that was with code that TinyMCE didn’t like, such as data entry forms or special Javascript, so I created seven “code_block” fields, e.g. “code_block1” … “code_block7”. Seven is a bit much, but at the time I created the fields in MODX, I was using many Amazon affiliate tags for books and CDs, in various articles. Snippets MODX Evo also has handy-dandy snippet tags that get replaced at run time. For my purposes, I only need to replace snippets in the code block fields, prior to replacing the code block tags in the body text. For example, I have a form that needs to display a dynamically generated captcha image that gets created by a Perl script. So, in the code_block1 field of the article, which contains the form, I place a snippet tag: [!s_form_get_captcha!] which then gets replaced by the same function that parses the chunk tags. I used the syntax [!...!] from MODX Evo mainly for convenience. Unlike MODX, the ! exclamation marks don’t affect caching of the snippet. To work with the snippet tags, I created an array in the chunk parsing function that attaches the snippet tag to the name of a PHP include file: $snippet_array = array( '[!s_form_get_captcha!]' => '/home/sigj/s_form_get_captcha.php', ); In this case, the PHP file “s_form_get_captcha.php” contains a backtick call to a Perl script which returns the dynamically generated captcha image. But, the PHP file could contain any normal PHP code that has to be generated at run time. Here are the contents of the function that parses chunks and snippets: ################################################################################################### function parse_field_chunks($page_id) { $body = wire(pages)->get("$page_id")->body; $snippet_array = array( '[!s_form_get_captcha!]' => '/home/sigj/s_form_get_captcha.php', ); #.............................................................................. $field_chunk_id_array = wire(pages)->find("parent=1052, include=all"); foreach( $field_chunk_id_array as $chunk_id ) { $chunk_name = '{{' . wire(pages)->get("id=$chunk_id")->name . '}}'; $chunk_value = wire(pages)->get("id=$chunk_id")->chunk; $body = str_replace($chunk_name, $chunk_value, $body); } #.............................................................................. # replace code_block tags with field values for ( $count=1; $count<=7; $count++ ) { $code_block_field = 'code_block' . $count; $code_block_tag = '{{' . $code_block_field . '}}'; $code_block_value = wire(pages)->get("$page_id")->$code_block_field; # now parse code block value for snippet tags # [!snippet_name!] # [!s_form_get_captcha!] foreach ( $snippet_array as $snippet_tag => $snippet_include_file ) { if ( strpos($code_block_value, $snippet_tag) !== false ) { $snippet_value = include("$snippet_include_file"); $code_block_value = str_replace($snippet_tag, $snippet_value, $code_block_value); } } $body = str_replace($code_block_tag, $code_block_value, $body); } return($body); } ################################################################################################### The Writer Table I use the writer_id field as a popup, to pull in an id from a data table of long term writers. When an article page is displayed, code grabs the id and pulls in the writer info, including a photo, attribution and Javascript encoded email address. In MODX, I had to use a custom table. In PW, I simply created a template field set called ‘writer_page_structure_permanent.’ I use a ‘static_author” and “static_author_attribution” field for those times when an author is a one-off writer. My code tests for a writer dropdown ID for ‘Non-Registered’ writer, and if the static fields have something, then that data is displayed. Template Structure Here are some screen shots of my PW template structure, which essentially replicated my previous MODX structure: Templates: List Page Structure Permanent: Article Page Structure Permanent: The Migration Script One of the challenges I faced with my script to migrate the data was the assignment of the correct parent of each article. Luckily, I wanted to keep the exact structure of the section and article tree and the urls. Since I didn’t have tens of thousands of articles, I decided to create an associate array of the sections and articles under the first level of the home page (i.e. starting at level 2), and then use that sorted list to create the ProcessWire parents before each lower level of section or article. I built the script dynamically, testing as I went, so I wouldn’t say that the script is fit for any and all MODX situations. It’s heavily tailored to my installation, and is missing a few elements that I missed until after I had finished with it (thus causing me to fix some things by hand). URL Replacement I had to parse through each article, in both the body, summary and subtitle, to make sure that any internally pointing MODX urls were replaced with the full url. MODX Evo uses the syntax [~ID~] in the “<a href...” tag to dynamically create the full page url at run time. I had to create a routine to replace the ID tags with page urls, e.g. “/columns/some_article_name”. Image Migration I first took the lazy way out and thought that I could simply move the “/assets/” folder from the MODX installation over to the new account. However, when I opened a PW page in edit mode, the links to the /assets/... images were there, but the images weren’t attached to the page, and thus, in edit mode, the image didn’t now show up in the edit box. I therefore added a routine to copy the images to each page. TinyMCE Code Breaks I found that TinyMCE kept trashing my various CSS codes that came over from MODX. I tried adding various tags to the body field’s “valid_elements” field under Input / TinyMCE, but finally just changed valid_elements to: +*[*] It’s a bit radical, I suppose, but my editors are fully trusted. After that, my migrated data was fine. Post Migration Data Checks After I migrated the data for the umpteenth time, in order to get it right, I still needed to do a variety of clean up tasks. I found the Selector Test module by Niklas Lakanen very useful (Thanks, Niklas!), and used it to run checks like: body*=src\=\"{~root_url}assets (which looked for left over links to /assets/ which came from MODX) I also queried the MODX and PW tables directly, using SQLYog, a Windows MySQL client. I ran a script that compared the results of a find command (find . -type f -printf "%f\n") under the MODX assets folder to the files under the PW site/assets/files folder. I found about 70 files that were not copied, some because they were in template files, which my script didn’t parse, and some because the filenames were problematic, like files with spaces, etc. The script took into account the PW code that changes uploaded file names. To do that, I copied the PW “validate_filename” function into my script. For all my checking, I still forgot things, like parsing the subtitle or summary fields for hrefs, which I then had to go and do by hand (since there were very few records like that). I also created a few redirect aliases by hand, instead of trying to handle them via the script. All in all, this migration confirmed once again that website migrations are a Bear. Ugh. I’d rather not do them. Link to Script Content Here’s the link to the script. Note that it didn’t catch everything, and it was heavily tailored to my design. Also note that I’ve removed some of the private data, like writer’s names, etc. sj_modx_pw_migrate_script.php That’s my case study. I hope it may be useful to another “MODX Refugee”. Peter Falkenberg Brown

Basically, since Processwire does not have any theming engine, the trick is to just do what you like and add the ProcessWire API to output your data ... pages, that is. So, as Martijn says, just install PW, chuck out all the bits you don't need (fields, templates and so on), and then just think about it like writing a bit of HTML. In fact, just write some HTML. You can use any framework you like - Bootstrap, Foundation, Adobe Edge, Frontpage 97 ...... You can use any Javascript/Jquery functionality you like. You can use any anything you like. Since PW does not have anything in the front end, you cannot conflict with anything unless you create the conflict yourself True freedom! That would be "Free as in ProcessWire"

What's wrong with Processwire + Foxycart? Working fine really well for one client of mine and soon to be integrated into another site. from the foxycart site: Use the CMS you already love. FoxyCart is built to complement your own preferred tools, and as such can be integrated into anything, whether it’s hardcoded HTML, a dynamic CMS, or a custom framework. Use the best tools for each specific job, not a one-size-fits-all system.

In this tutorial we make a simple function that becomes part of every PageArray. Once hooked to the PageArray class, you can call this function from anything returned from $pages->find(), $page->children(), or your own page references like $page->categories from the blog profile, etc. It essentially becomes a new function available to you from any PageArray anywhere in your site. First, lets look at what convenience the hook function adds and how we might use it. We'll call the hook function "renderLinks", but you could of course call it whatever you wanted. We call that renderLinks() function from any PageArray, and it returns a string representing that PageArray as a list of links. By default, this renderLinks() functions separates each page with a comma, and outputs the page's title as the anchor text. We can change that to be anything by specifying arguments to the call. The first argument is the delimiter, which defaults to a comma ", " if not specified. The second argument is the name of the field to output, which defaults to "title" if not specified. Next are 3 examples of how this renderLinks hook function could be used. Usage Examples: Example 1: render a comma-separated list of links: echo $pages->find("parent=/")->renderLinks(); Output: <a href='/about/'>About Us</a>, <a href='/contact/'>Contact Us</a>, <a href='/site-map/'>Site Map</a> Example 2: render a <ul> of $categories links: <ul> <li> <?php echo $page->categories->renderLinks('</li><li>', 'title'); ?> </li> </ul> Output: <ul> <li><a href='/categories/category1/'>Category 1</a></li> <li><a href='/categories/category2/'>Category 2</a></li> <li><a href='/categories/category3/'>Category 3</a></li> </ul> Example 3: render a breadcrumb trail: <p class='breadcrumbs'> <?= $page->parents->renderLinks(' / ') ?> </p> Output: <p class='breadcrumbs'> <a href='/parent1/'>Parent 1</a> / <a href='/parent1/parent2/'>Parent 2</a> / <a href='/parent1/parent2/parent3/'>Parent 3</a> </p> Those examples above show some of the potential of how you might use such a function. Next is the hook function itself. In order to be available to all templates in your site, it needs to be defined somewhere consistent that is always loaded... Where to put the hook function: If using the basic profile (that comes with ProcessWire) you could put the hook function at the top of your /site/templates/head.inc file. If using the Foundation or Skyscrapers profile, you could put the hook function in your /site/templates/_init.php file. This is the method that I use. If using something else, you could create a /site/templates/_init.php file with your hook function(s) in it, and then edit your /site/config.php to point to it with the $config->prependTemplateFile = '_init.php'; so that it is automatically loaded on every request. Note that the name "_init.php" is not required, you can name it whatever you want. You could put it in an autoload module... but that might be overkill here. The actual hook function: wire()->addHook("PageArray::renderLinks", function(HookEvent $event) { // first argument is the delimiter - what separates each link (default=comma) $delimiter = $event->arguments(0); if(empty($delimiter)) $delimiter = ", "; // second argument is the property to render from each $page (default=title) $property = $event->arguments(1); if(empty($property)) $property = "title"; // $out contains the output this function returns $out = ''; // loop through each item in the PageArray and render the links foreach($event->object as $page) { $value = $page->get($property); if(!strlen($value)) continue; // skip empty values if(strlen($out)) $out .= $delimiter; if($page->viewable()) { // if page is viewable, make it a link $out .= "<a href='$page->url'>$value</a>"; } else { // if page is not viewable, just display the value $out .= $value; } } // populate the return value $event->return = $out; }); If using PHP before 5.3, or using an older version of ProcessWire, you'll need to change the first line to this (below). This syntax also works with newer versions as well, but it's not as pretty as the new syntax. wire()->addHook("PageArray::renderLinks", null, 'hookRenderLinks'); function hookRenderLinks(HookEvent $event) {

Hi Ryan, thanks for the reply. PW reads them in by the filesystem and that seams to use the created or lastmodified timestamp. When I start uploading 5 images with names 001.jpg - 005.jpg together per AJAX (or a ZIP with the same 5 images) as the result the sort order is uncontrolled. Some small images first and all together very un-ordered. Both upload variations, AJAX and ZIP, are actually not very customer friendly if she has the need to use the images name as sort order. If the PHP-UNZIP will be implemented that it allows a controlled unzip and pw-import file by file, it would be helpfull for that. Alternative: a (optionally) configurable sortorder (by name or unsorted/by time) for imagefields would be nice.

@Joe: good to hear that you got it working @ryan: in order to be even remotely consistent, I'm posting here to say that I just suggested a small change in the Hanna Code thread regarding the default config.js of CKEditor shipped with this module.

I agree, sounds very interesting. I'd be interested to know if anyone gets the chance to try this. You are right that if it runs WordPress, it should also be able to run ProcessWire... assuming they haven't built it around WordPress or something.

Congratulations, you found a diamond in a cms heap. You will find that out your self the more you work with it. You can modify it in any way you want with the API of processwire. You can use any css framework to make responsive websites, like cube, foundation, etc. PW comes with tinymce. You can already do all the things you need with that. You can activate extra functions in tinymce inside the PW configuration like: fontsize, fonttype, fontcolor, background color, charmap, etc. etc But using css for that is preferred to keep your design clean and portable. Study the API of processwire, you are going to need that first. Then learn basic php things like foreach, do-while that you are going to need together with the API. The learning curve is only to become familiar with how pw works. PW works different from other cms'es because pw has no cms rules, no cms walls. PW adapts to the designer and coder, not the other way around like almost all other cms'es out there. Go through the PW tutorials until you get that "aha that's how pw works" moment and then you can go on for your self, you don't want to stop anymore also because pw is that addictive http://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/

(Note: Teppo typed faster than me, so I am repeating some bits here) HI Adonis And Happy New Year back at you! Okay, let me answer the bits I can. First, template. Basically, ProcessWire does not have a templating system of any sort, so you do not have to learn anything. In the /site/templates/ directory, anything with a php extension is regarded as a template. So, if you create a file called myfile.php in that directory, you can then go to Setup > Templates in the admin and add it as a template. (Click New Template and you will see it listed.) You can then create a new page using that template. Obviously, as it is has no mark up in it, nothing will actually get displayed, but it is a start. To use it more fully, you just need to write HTML in it (as you would a stand alone html page) and then add a bit of processwire php markup to output the fields. For instance, the Title field would have automatically been added when you added the new template in the admin so to out put it you could put in your html, for instance: <h1><?php echo $page->title; ?></h1> The main thing is to understand the difference between a template and a template file Template: A processwire object that associates a group of fields together Template File: The file where you put any markup and/or logic for outputting those same fields. You should go and do this over the top tutorial and it will all become clear! http://wiki.processwire.com/index.php/Basic_Website_Tutorial CK Editor Since this is an add-on module, you can do pretty much as you like with it. However, there are a couple of plugins added to it (for images and links) that are customised for processwire that need to be left intact. PHP Knowledge I have very little php knowledge, but PW has proved a really good way of learning the basics! So my knowledge has increased using it. Make sure you learn about the basics of using echo and how to do a foreach loop. (plenty of examples in this very forum) And then read the API, especially the cheat sheet. That will do you for now - go play!

Hello there and welcome to the forum! A few quick answers and/or comments: 1. Awesome. Feel free to contribute any time you want 2. ProcessWire doesn't produce markup per se, so you can create whatever markup you wish and, for an example, use any layout / CSS framework you prefer. You simply create your templates as pure HTML (though within PHP files) and then ask ProcessWire to pull in content from current page to whatever location you want, with simple PHP syntax like <?php echo $page->body ?>. 3. CKEditor module is very configurable. Install it, see field settings and you'll find out just how far it can go. If you need any help, don't hesitate to ask. Personally I prefer to control stuff like font colors via style sheets so the site doesn't end up looking like something a drunken unicorn left behind, but I get that this might in some instances be necessary. 4. Sounds reasonable. No need to start from the deep end. 5. Most likely no. Again, you won't need to start with complex stuff, simply echoing out content takes you long way already. I wrote a blog post some time ago comparing PHP templating to Twig (and explaining the basics), so you might want to check that one out here if you're more familiar with other templating engines. 6. Some people prefer tutorials, others start with the documentation, personally I started learning with a real project (by the end of which I had pretty much grasped all the basic concepts of PW.) It's your choice really, but whatever route you take there's a lot of material available already. Again; ask and you shall receive (pointers for where to look, that is)

Yes this is what I was trying to say (and I guess have said in other threads)

@bfd - the page path history was developed to solve that problem, and you should enable it on your site once you go live; http://modules.processwire.com/modules/page-path-history/ prior to going live, when you migrate to the new location you can do a search/replace in the SQL file to fix the paths. you might also look at this: http://modules.processwire.com/modules/page-link-abstractor/

Hello All, After spending most of my free time this year building a large web application with ProcessWire, I've finally found the time to migrate my magazine site from MODX Evolution to PW. http://significatojournal.com I'm very, very pleased with ProcessWire, and will no longer be using MODX. In a separate post, I'll write up a case study of how I did the migration. But for now, I really thank Ryan and all the extremely supportive gurus in this very fine PW community. Peter Brown

And what is wrong with your code, why must there be a better way? I just think you may not do it in template but after saving the page, it's also not kind of validation but a cleaning. So you wouldn't end with selectors being "false" saved to DB. ProcessWire hasn't some other way to do what you want/doing here, possibly also because of performance - it doesn't attempt to check for each selector if it's really valid/field exists. Technically there's also a way to add a runtime value to a pages that is used in selector on page arrays.

OK, so finished my marathon forum catch-up...14 pages of threads! Here's signs you've been away too long..... 1. You get this message when trying to like a post... 2. Soma has (finally) updated his personal web site! 3. Pete trimmed his "facial" hair (ahem, fur) 4. Arimo is the new Arial, no Arial is the new Arimo, no actually Arial is still...uh, Arial..... 5. Willy C is designing a new top secret Admin theme. ;-) 6. You are no longer sure what this means.. 7. It's Christmas eve and you are starting a lousy thread... 8..........?

I took the liberty of merging your two forum accounts - the details from your newer one should work fine. I very much doubt a full-blown forum solution in ProcessWire will appear any time soon - the general suggestion is to use another piece of software. This is because forum software is usually really complex, taking teams of developers at least a year to create and years after that to perfect. I know this is why ryan at least suggests using other software for this side of things - see here: http://processwire.com/talk/topic/572-release-discussions/?p=48129 If you've ever looked at forum admins for the likes of Invision Power Board you'll see that there are dozens of pages just for managing them as well so it's not as straightforward as it might seem at first. That said, it is possible to build modules that bridge the membership between forum software and ProcessWire. I've done it myself (and will one day get around to polishing and releasing the module): http://www.strategycore.co.uk - note that you would still manage the forum in the forum admin but you then have available the membership functionality and members and their groups exist in ProcessWire as well. As kongondo says, Moodle is an entirely separate piece of software. I have, in the past, shoehorned several different applications to work together and the results are always painful when you have to update one of them (not usually ProcessWire as the API functions stay the same) but even something like the forum bridge mentioned above could rbeak on a newer release of the forum software as other developers just will not design a good API and stick to it. That's one of the things that makes ProcessWire exceptionally different - ryan has gone for as close to human readable code as possible and it doesn't matter so much how the code works behind the scenes - it could all change behind the scenes (but it won't) and the functions available to you in the templates to pull out the data would still be the same. I think you may need to step back and take a look at what you want to achieve in terms of functionality as Moodle for example already has its own forum module. No offense intended, but you appear to be looking at different solutions, liking the idea of some of them and then deciding you want them all, rather than explaining what features you need. I would suggest that it is actually possible (with enough time and money) that you could recreate what you want from Moodle in ProcessWire and do away with one of the three software packages entirely, then hook it up to something like IP.Board if you didn't like Moodle's forums, but depending on your requirements from Moodle you could be talking about a year's work easily. That said, you can have forums, course modules and site pages all just in Moodle, so if time and budget are your constraints then you could already do it all in one package. There are also dozens of categorised plugin modules for Moodle on this page: https://moodle.org/plugins/

Fieldtype File from folder I “needed” a module to select a file from a folder, using an <select> and store the filename. There's only 1 setting: The path to the folder to list. The Path is relative to the templates directory. So if your files are located in /site/templates/scripts/, type scripts/ in the `path to files` setting. here's the gist, enjoy. This module is released because it was useful for me in several projects.

Hi Uniweb. Welcome to ProcessWire and the forums *Bilingual:: Yes, right out of the box. There are various implementations explained here in the forums. Have a look at the docs for starters. http://processwire.com/api/multi-language-support/ *Membership:: there are 5 different types of users: teachers, research workers, administrative staff members, students and anonymous. Yes, again, there's various implementations. This is about users and access. See this thread for pointers and other links. http://processwire.com/talk/topic/3946-membership-module/ *Moodle integration:: teachers should be able to use Moodle from our domain I am not sure exactly what you mean by integration. Moodle is an application in its own right. Did you mean shared users, for instance? Others will be chime in about this am sure. *Blog. Not sure if I can integrate a built-in Blogger blog into Processwire. Or is there a blog feature already in Processwire? Yes, PW already has a blog profile....it is also easy to roll out your own (this depends on your dev skills though) http://processwire.com/talk/tags/forums/blog/ http://modules.processwire.com/modules/blog-profile/ *Forum would be a nice addition although I'm not sure if it's possible with Processwire? There's no native PW forum. There has been talk though about developing one. You will be better of (I think) for now using a solution such as IP Board. Sorry for the quick answers. I hope they get you going... ..others will chime in with better responses...

What a coincidence that this thread turns up now. I've just finished a system for managing users and was wondering how best to share it. It consists of five template files, one stylesheet and a slightly modified InputfieldPassword module (I changed the validation and some text). You setup a page for each template, all of them children of a hidden /access/ page. The various forms are made with InputfieldForm. Each template sets $page->body and then includes a basic-page.php template file, like we see in many of the processwire profiles. /access/login/ /access/profile/ (for changing your password, username or email address) /access/logout/ /access/register/ (for creating a new user account) /access/reset/ (for when you've forgotten your password) Each user acount must have a unique username. An email address is collected for each user but does not need to be unique (it's okay for someone to have more than one account). When setting an email address we verify it by emailing a message to that address. Confirm by clicking a link or pasting a code into a form (an 'email-confirmed' role is added). Requests to reset a forgotten password are verified by emailing a message to the account's email address. Confirm by clicking a link or pasting a code into a form. To close the registration process set the /access/register/ page status to Hidden. For my own purposes, this is a convenient parts kit I can quickly add to a project. Seems like the easiest way to share it is as a profile. I suppose I could bundle up the files and create a module which installs everything for you but doesn't that seem just a bit overdone? Any suggestions? Good points were made above about coding standards, translatable text strings, etc. I'd have to do some work on that. I value the multi-language capabilities in PW but hardly ever need them in my work so if the community insisted on it being standard would that encourage me to get over my aversion to the syntactic baggage it requires or would it discourage me from sharing? For modules the Proof of Concept category works pretty well. It's nice to share unfinished work. Often the author's intent is easier to grasp in these less filled out implementations. Often there will never be a final version because every project is different. Framework add-ons can actually suffer from too much completeness. Do you want to transplant a seedling or a mature plant? Perhaps coding standards for modules could be expressed as a checklist and implemented as tags in the Modules section of this site. Likewise for profiles and any other kind of package we may come up with. Thanks to the many generous and thoughtful coders here.

I just went ahead and did what I wanted to do since a long time. Yesterday at this time there was nothing. Now there's this: http://soma.urlich.ch/ My old portfolio, taking dust, is gone for good! Now I have new shiny blog. Starting with zero, this took a couple hours to setup a complete custom blog. I'm still working out details here and there and adding new stuff I still want to. But what I need and wanted is there now roughly. Some things used in this ProcessWire site: - ModulesManager (of course) - Hanna Code - Repeaters (for the inline code snippets added to content by some Hanna code) - Rainbow JS for the highlighting (http://craig.is/making/rainbows/) - PW Comments Core module - RSS Feed Core module - Markup Twitter Feed (http://modules.processwire.com/modules/markup-twitter-feed/) - Pocketgrid (there's no good grid system other than this http://arnaudleray.github.io/pocketgrid/) - FontAwesome Icon Font No frameworks used except PW. I hope I'll find time to write some things about web dev in general and ProcessWire. Hope you step by now and then.

Absolutely love your technical drawing skills.

In some projects I use a mix of the $config->scripts and $config->styles FilenameArray to add scripts in templates. And one similar to the one Ryan, where I can create js and css files with the name of the template and they'll get loaded if existing. In a recent project I use a custom $config->siteScripts = new FilenameArray(); $config->siteStyles = new FilenameArray(); I set in a autoload module. Then I add the script in a template: $config->siteScripts->add($config->urls->templates . "js/yx.js"); This also allows for modules I create, for example widgets (that are not autoload), that need scripts/styles to add them with simply adding the method above in the init(). So as soon as I load the module in the front-end they'll get added to the array. To output, I use the same method as found in default.php from the admin template. <?php foreach($config->siteScripts->unique() as $file) echo "\n\t<script src='$file'></script>"; ?> You could also just use the $config->scripts used in the backend, but if you use form (InputfieldForm) API in the front-end, loading inputfields modules will also load scripts and styles from those in the filename array. This may not desired, that's why I use a custom filename array. For anything basic and global, I add scripts and styles hardcoded in the main template.

Today I have added a hook to the module that add pim_* variations to pageimage-variation-collection. This is usefull to not have mass orphaned (pim_)images on the disk when original images got deleted. I have had this code ready for many weeks and would have done some more (workaround for GDlibs buggy sharpening on pngs with alpha-transparency) before update the module. But I haven't had time for this. So, there are no other changes in module version 0.1.1 what is available now at github and in the modules section. Cheers!

One interesting thing about working with ProcessWire is that since you have to program in your own bells and whistles, rather than just installing some extension, it makes you pause and think whether you actually need them or not. The trouble with Drumlapress is that it is easy to just hit buttons and add things - so you do** Web design, like any sort of creative discipline, should be about the minimal. Even Van Gogh with his layers of oil was minimal - we don't know what he MIGHT have added to his pictures, but we do know that what he did put in he meant to put in. Oil painting is slower than sketching (especially for a lazy bugger like Van Gogh) and there was no way he was going to shove in anything that didn't work for its living. And so it is with ProcessWire. PW is not hard, but it requires you to actually do some work rather than hit buttons like most CMSs, and that makes the lazy ones of us take our time, keep it simple, and make sure we only put in things that actually need to be there. --------------------------------- EDIT I added two asterisks above and forgot to put why! So .... ** The situation has been slightly alleviated since, in Joomla at least, so many of the extension updates are now commercial (even some of the ones that really shouldn't be!)

it is true that the more sites you build with PW the better you get at using it and thinking in terms of a collaboration between yourself and the api, and the more you read the forum, view the source code of the profiles, modules etc, you are constantly improving and becoming less of a 'beginner', but that term also implies that PW is comparable to the big 3 (and that eventually when you are no longer a beginner you'll be able to achieve those things in the same time as you would in W/J/D), and as Ryan recently pointed out, it's really not, and probably will never be something that can be compared 1-to-1 with those fully interfaced options. The more you know about and work with PW, the more you come to realize that there really couldn't be a generic frontend user management 'module' since the needs of any such system would be unique to the business/application logic of that project. The productivity and simplicity that the clients get through having their site be 100% custom in terms of both the front and backend is really priceless, and that extra time it might take to build something custom as opposed to using a pre-built component/module/plugin pays off over and over again for years to come. I have built a lot of sites with Joomla and a few sites with Wordpress. In 90% of those sites (that are stuck on those CMS) the clients still regularly contact me to perform content management work, because as simple as they might seem to techies, they are incredibly confusing and complex for the average user especially those people who update their site only once in a long while. When i compare that to the processwire sites built for clients, the result is that none of them ever contact me for content management, they can do it themselves, none of them break their sites, or destroy the formatting or look of the pages through gross violations of the wysiwyg... so my response to your post would be of course, it would be great if someone could write those modules, but I think they would need to be subsidized... maybe start a kickstarter campaign for whichever one you think is most helpful?

Update: Pushed new version to GitHub just moments ago. This fixes some minor glitches and adds new "quick diff" feature. See attached screenshot for more details. It's very primitive at the moment, but I'm hoping to improve it (and some other parts of this module) soon. This is first actual "feature update" for this module, so I'm a bit nervous and would very much like to hear how it works for you. Tested it here with multiple browsers and fields etc. but I've probably again overlooked some issues. Regarding the diff feature, Google did most of the heavy lifting there; all I did was integrate their Diff Match and Patch library (JavaScript version) to my code. For the record I was going to use jQuery PrettyTextDiff, but that really didn't feel necessary considering that it's just an attempt to simplify the (already simple) DMP API.

There is also handy Process modules, that admin uses. See this as a starting point when building your own: https://github.com/ryancramerdesign/ProcessHello

After Ryan's latest incarnation of Blog Profile I wanted to see if I could learn something from there to my own workflow. It turned out very nicely and this seems like a perfect template approach for me. Wanted to share it with you guys. Folder structure under templates folder: templates/markup/ templates/markup/helpers/ templates/markup/layouts/ templates/scripts/ templates/styles/ And it all begins from here: templates/markup/index.php -this is the "complete" html file, it has doctype, head and starting and ending body. There is very little "logic" here, it's more like a container. There is one very important code snippet there though: <?php if ($page->layout) { include("./markup/layouts/{$page->layout}.php"); } else { include("./markup/layouts/default.php"); } ?> Code above goes between header and footer of your site, that will be the main content. I call it layout, but the better name would be "content layout" or "inner layout" or something like that. Then the templates/markup/layouts/ folder will keep at least default.php file, but probably few others, like "threeColumns.php", "frontpage.php", "gallery.php" etc.. you got the idea. Each of the actual pw template files are then purely "controllers" - no actual markup generated there. All markup are done in files inside templates/markup/ folder and it's subfolders. This is how template file templates/home.php on one site I am building right now looks like: <?php // Carousel items $t = new TemplateFile(wire('config')->paths->templates . 'markup/helpers/carousel.php'); $t->set('carouselPages', $page->carousel); $page->masthead = $t->render(); // Tour themes $t = new TemplateFile(wire('config')->paths->templates . 'markup/helpers/items.php'); $t->set('title', "Get inspired from our <strong>tour themes</strong>"); $t->set('items', $page->featured_themes); $t->set('description', $page->themes_description); $t->set('url', $config->urls->root . "themes/"); $t->set('linkTitle', "All themes"); $page->main .= $t->render(); // National parks $t = new TemplateFile(wire('config')->paths->templates . 'markup/helpers/items.php'); $t->set('title', "Seven beautiful <strong>national parks</strong>"); $t->set('items', $page->featured_parks); $t->set('description', $page->parks_description); $t->set('url', $config->urls->root . "national-parks/"); $t->set('linkTitle', "All national parks"); $page->main .= $t->render(); $page->layout = "frontpage"; include("./markup/index.php"); This uses few "helper" markup files from templates/markup/helpers/ folder (namely carousel.php and items.php). Here is the carousel.php for your reference: <?php /* Generates the markup for the frontpage carousel */ if (count($carouselPages) < 1) return; $styles = ''; echo "<div id='carousel'><ul class='rslides'>"; foreach($carouselPages as $key => $p) { echo "<li class='c-item c-item-$key'>"; echo "<img src='".$p->image->getThumb('carousel') ."' alt='' />"; echo "<p>$p->summary</p>"; echo "<a class='button' href='{$p->link->url}'>$p->headline</a>"; echo "</li>"; } echo "</ul></div>"; Then populates the $page->masthead and $page->main properties and then set's the inner layout to "frontpage". That templates/markup/layouts/frontpage.php file is very simple on this site, but could be much more complicated if needed: <div id="masthead"> <?= $page->masthead; ?> </div> <div id="main" class="wrap"> <?= $page->main; ?> </div> Frontpage is rather unique and I could have done all the markup on the frontpage.php file also. But I do want to re-use those "carousel" and "items" components on other places as well. But if I do have totally unique stuff, where I do want to get "quick and dirty" this approach allows it. Then my template file would be something like this: $page->layout = "campaign2012"; include("./markup/index.php"); And then all the markup would be in that templates/markup/layouts/campaign2012.php Blog profile really gave me a good ideas (cleaner folder structure etc) and using TemplateFile class adds nice possibilities. This is of course just a one way to manage your templates, but hopefully someone of you finds this helpful when thinking about how you like to structure this stuff. PS: If you are just getting started with PW, then I recommend using the head and foot includes method from demo install. There is nothing wrong with that method and only more complicated sites starts to benefit from these methods introduces in this topic.

Here is the first release version of the Blog Profile! http://modules.proce...s/blog-profile/ It is now up on GitHub as well: https://github.com/r...ign/BlogProfile Below is a lot more talk about this blog profile and how it works, but if you just want to install the profile and test it, it's not necessary to read anything further unless you want to. I've simplified this a lot from where it's been. It does all the same stuff on the front-end, but the code behind the site is no longer a huge departure from the basic profile. I've rebuilt this profile 3 times trying to find the right balance between making it as flexible as possible and making it as easy to understand as possible. I think it's got a better balance now than before. It's now at a point where it does everything it always has, but the template code behind it should be a lot more accessible and easy to understand. There is no longer a separate module or API variable. Everything here just happens in /site/templates/ files. Consistent with making it simpler, I've also removed the drag-n-drop theme support. While it was cool to have, it always felt a little dirty introducing some kind of proprietary theme support that was so different from the way I'd build any other site. This thing is pretty darn simple to theme as it is (just edit a CSS file). Maybe we'll take it further in the future, but we don't have many PW site profiles out there right now (1 or 2?) and so I decided this profile needed to stay more accessible on the back-end. How the template files work In ProcessWire there are any number of ways you can use your template files. In this case, we are using our template files (in /site/templates/) to populate 3 variables ($content, $headline and $subnav) and then including an HTML file (main.inc) to output them in the right places. The $content variable represents the center (body) column, the $headline variable represents the text headline of the page, and the $subnav variable represents the navigation that appears in the left sidebar. Once one or more of these variables is populated, the template file includes the /site/templates/main.inc file. That main.inc file is just a big HTML file that outputs the $content, $headline and $subnav variables in the right places. We've made an attempt here to separate most of the logic used in the template files from the output. Most of the markup is generated from files in /site/templates/markup/. These files are included from the template files to output specific things like a blog post, comment, etc. Because a lot of output needs are similar among the various template files, we've created a file called /site/templates/blog.inc that has a few shared functions in it. If you look in any of the template files, you'll see that most of them include blog.inc as the first thing. This blog.inc file also initializes our $content, $headline and $subnav variables, mentioned earlier. Outline of /site/templates/ with this profile /site/templates/blog.inc Shared blog-specific functions included by most site templates. /site/templates/main.inc The main HTML markup file through which everything is output. /site/templates/markup/ Contains PHP files that generate markup for specific things like posts, comments, etc. This is separated from the site templates to make it simpler for you to modify the markup if you want to. This is primarily used by the blog.inc functions, but also included by a couple templates as well. /site/templates/skeleton/ This is the Skeleton CSS framework. It is identical to the one they distribute except we added a wider viewport to it. You probably wouldn't have much need to edit anything in here. /site/templates/styles/ Stylesheets used by the blog profile. The most useful one in here would probably be theme.css, which contains all the color definitions for the profile. /site/templates/scripts/ Javascript files used by the blog profile. Not much is happening in here at present.

Nice Job Pete. Before GitHub for Windows i was using SmartGit, which has more features and power but also can be quite confusing at times. So for my basic needs GitHub for Windows works fine. I would recommend adding a small section about contributing to existing projects. It's not that hard an can be useful, even if all you did was correct some typos or indenting in the PW codebase, like i've done in the past being the coding lightweight that i am. All little things count. In a nutshell: Fork - Go to https://github.com/r...ign/ProcessWire - Click the "Fork" button in the top-right corner - Visit your own PW fork page if your not already taken there automatically (https://github.com/MY_USERNAME/ProcessWire) Clone - Click "Clone in Windows" in the top-left corner. - This will open up "GitHub for Windows" and after a short wait you will see a local repo of your fork.Configure remotes Configure remotes This allows you keep in sync with changes made to the original codebase (e.g. Ryan's repo) - In "GitHub for Windows" local repositories view, right-click and choose "open a shell here" - This will open a shell already in the right directory. Type the following commands: git remote add upstream https://github.com/ryancramerdesign/ProcessWire.git # Assigns the original repo to a remote called "upstream" git fetch upstream # Pulls in changes from the original repo not present in your local repository, without modifying your files. Allows you to review first. git merge upstream/master # merge fetched changes into your working files. Syncing and pull request If you've merged upstream changes you can then sync them with your GitHub fork via the 'sync' button. The same goes for changes you made yourself. If you think PW would benefit from these changes you can send a pull request. Go to your fork on GitHub and click the button "Pull Request". - out of time - Anyways, you've put it in pdf but is it an idea to put it on wiki.processwire.com as well?