Leaderboard

Hello all, My name is Jim Jackson (Username: Zislatik) and I am amazed at processwire. I have been a student of MODX and always found my web development endeavors coming up a little short (my failings not MODX). Modx was the first CMS that I installed that made sense to me and I have created several basic site in it. I love the Modx community but in recent years I feel it has gotten pretty "big" as they have grown in a direction I am not sure I want to follow. I still love the community and I am very thankful to have found it. I am extremely please that I have found processwire. Processwire works the way I think when it comes to a CMS. I love that the community is smaller and developing. I feels like I can get in on the ground floor and watch it develop. I loved template variables, snippets and chunks in MODX which is why I gravitated to MODX but I am finding that infinite fields rock! Mind you I am a novice and I am sure I have just scratched the surface of what processwire offers. Anyway, I just wanted to introduce my self and for warn everyone that I will probably have a stream of newbie questions slowing the forums. I do have a couple of quick questions. 1. Are there any other MODX converts here and what would be the advice you would offer to a student of webdev in learning the differences? 2. I have a basic grasp of php, html and CSS, is it really as easy as it seems to build a site with process wire? 3. Any developers out there making money with processwire professionally? I have seen paid modules but I mean building site for customer in process wire? Again, thanks for any information provided. I am happy to have found processwire and I appreciate everything in advance. Thanks, JIm

A temporary fix in response to this request ProcessCommentsManagerEnhanced This is a slightly enhanced version of the current core ProcessCommentsManager. I've tested it in the current dev version of PW and it works fine. I cannot provide any guarantees nor support the module though ....it is a working-nicely-proof-of-concept. Download GitHub Install Just like any other ProcessWire module. It requires FieldtypeComments to be installed. You do not need to install ProcessCommentsManager. Demo Screen

Hi guys, Been "kicking the tyres" on some UI tweaks to the PW image fields and modal windows. Many of these are in-progress designs and to be straight, none of the designs are entirely resolved. At this stage, I thought I'd throw them up (poor choice of words!) and maybe someone can take them further or offer some fresh eyes. I'm not a developer so making these a reality is impossible for me. They're flat designs. Why? PW is an amazing experience for editors. It's just so elegant and beautifully realised (especially with Reno Theme) that often, my training sessions with clients are very brief. One area which does cause friction though has always been concerned images, image fields and image modals. Especially with the latest image modules, I think a lot of inconsistency has crept into the UI. Hopefully these designs can help improve things a bit. A tiny part of the design work is influenced by a similar idea I had for MODX but which never progressed. 1A. Current Image Modal Editor has clicked 'Add image' icon in CK editor. Issues: I believe the Upload Image button can be better placed. It's not clear to users that they have a choice of two actions (Select an Image OR Upload one) To help solve this, I thought we could: Place available images under a Choose tab Create another tab titled Upload Rename modal to just Image (from Select Image) tweak slightly the Images on page path to be less prominent The following image illustrates the result. Clicking the Upload tab would result in: In the above image I've created toggle-able accordians for Drag and Drop and Manual upload. This follows closely the UI an editor is presented with when choosing Insert Link within CK Editor. IE Link to URL, Select Page and Select File and the extra Attributes tab. So overall, it's more consistent. 1B. Alternative to above - combined Select and Drag/Drop I thought it might be worth exploring what modal would look like with no tabs and a single UI for both Selecting an image and Drag/Dropping. 1C. The Image field I then moved onto looking at the Image field in PW. So currently it looks like this (below) for a simple image field called Image Gallery. So although the current Image field works great, I wondered if there was a way to simplify it by Making the drag/drop more visual and obvious Moving the Choose Files button and removing the No file chosen text and the file types allowed Here's the result. Admittedly, this treatment adds more height to the overall field. Here's how it looks when images are uploading (slightly smaller plus icon and "drag and drop..." text. To be honest, I can't recall what other changes I made there! And here's a proposed layout for when there are multiple images. This includes image titles grid layout mouse-over for edit and delete options/buttons 2. Cropping Next thing I looked at was cropping. Native cropping introduced recently is one of my clients favourite features and time-savers and I wondered if things could be improved a little. So heres the current layout (this may have changed further recently) And here's my proposal. Changes are: Width, height and X and Y fields are moved below the image Apply and Cancel placed bottom right of the image Save Crop should be titled Apply. I think that's less confusing as in some instances there are so many Save options Save and Replace should be greyed out further In addition to this, I thought it'd be neat if we had the free-form cropping function introduced by Ryan combined with some kind of list of pre-sets (displayed on right hand side). Forgive the croptions label (Crop + Options pun - I was tired!) The benfit of this I think is that Modules such as CoppableImage and native Crop would be unified in a single UI. Presets (on right) could be a few out-of-the-box presets which come natively. Croptions houses any crop ratios defined in image modules. if CopppableImage isn't installed, they just don't display.. That's it. I wish I'd more time to work on this but it's at the stage where it's ready for some initial thoughts. Hope you guys like.

Start with this link https://processwire.com/talk/topic/3691-tutorial-a-quick-guide-to-processwire-for-those-transitioning-from-modx/

Welcome aboard, 1. We have plenty of converts here. Myself I'm a WordPress convert. However I'm not a convert from MODX so I will not be able to tell you the differences. 2. ProcessWire does not alter any of your markup and only when using ->render() will you find it output markup. With the new front-end editing it does alter your markup but only when logged in with the permission to edit using the front-end. The HTML, CSS and Javascript is completely down to you. By default ProcessWire uses PHP as it's template engine. So the only thing you need to learn is API and that's it Oh yeah, and the API is super easy to learn. Trust me ProcessWire is a front-end developers dream. 3. I work at an agency but also freelance. While I don't charge much at all for freelancing as my job is my hobby. ProcessWire is always my CMS of choice. So I guess you can say I make a living out of ProcessWire.

Here comes a small Christmas Present Go to setup > templates or setup > fields and find 2 important (or exportant) buttons below the list in the right corner to go here:

Hey guys, first, ProcessWire is a great piece of software. Thanks for that and the great community behind that. So, i'm realy new to ProcessWire, but i will present you my first module for SEO- and performance optimizing: AIOM+ (All In One Minify). AIOM+ (All In One Minify) for CSS, LESS, JS and HTML AIOM+ (All In One Minify) is a module to easily improve the performance of your website. By a simple function call Stylesheets, LESS and Javascript files can be parsed, minimized and combined into one single file. This reduces the server requests, loading time and minimizes the traffic. In addition, the generated HTML source code can be minimized and all generated files can be loaded over a cookieless domain (domain sharding). Install AIOM+ Download current release (link below) Extract and copy the files for this module to /site/modules/AllInOneMinify/ Login to PW backend and go to Modules > Check for new modules Install Module > AIOM+ (All In One Minify) for CSS, LESS, JS and HTML Alternative in ProcessWire 2.4 Login to PW backend and go to Modules Click tab "new" and enter Module Class Name: "AllInOneMinify" Click "Download and Install" Features Combining stylesheets / LESS files or JavaScripts Minimize the combined files No change to the .htaccess necessary (except for the domain sharding) Server-side LESS parsing without plugins HTML source code minimization Cookieless domain / domain sharding Automatic cache management (With changes to the source file, the cache is rebuilt) Configurable via the backend Automatic rewriting the paths in the stylesheet and LESS files. No changes are needed Optional developer mode (combining, but no minimize and browser cache prevention) Clear the cache on the backend Conditional loading for CSS, LESS and JS (since Version 3.1.1) How to use Minimize multiple stylesheet or LESS files into one file. You can even mix stylesheet and LESS files in parsing and combining process! <link rel="stylesheet" href="<?php echo AIOM::CSS(array('css/file-1.css', 'css/file-2.less', 'css/file-3.css', 'css/file-4.less')); ?>"> Minimize multiple javascript files into one file. <script src="<?php echo AIOM::JS(array('js/file-1.js', 'js/file-2.js', 'js/file-3.js', 'js/file-4.js')); ?>"></script> Conditional loading (same with Javascripts) <?php $stylesheets = array('css/reset.css', 'css/main.less', array('loadOn' => 'id|template=1002|1004|sitemap', // PW API selector 'files' => array('css/special.css', 'css/special-theme.less'))); ?> <link rel="stylesheet" type="text/css" href="<?php echo AIOM::CSS($stylesheets); ?>" /> More Information, Documentation and Download AIOM+ in ProcessWire repository AIOM+ on GitHub So, I hope you can do something with this module. Dave

Since the days back then of the modx evo course change, many modx refugees here. So welcome to the club You can start off with tutorials or clips: https://processwire.com/docs/tutorials/ https://processwire.com/talk/forum/13-tutorials/ https://processwire.com/videos/ http://processwire.tv/ You can find also some modx/processwire threads in the forum like this one: https://processwire.com/talk/topic/3111-a-modx-refugee-questions-on-features-of-processwire/ When you start with Processwire you have to make your self familiar with the concept that it is "an API-first CMS" a so called decoupled or headless cms. Together with the processwire flexible api makes this a diamond in a pile of cms systems out there. There is no building websites "the cms way" but you build your frontend separately in any way you want. That means, for one example, that you can directly apply any level of html, css and php experience that you already have. Here's another quick walk through https://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/ There are quite a few people here making money with websites using processwire as their tool of choice. https://processwire.com/talk/forum/9-showcase/ Making money with processwire would not be different from any other cms system as it depends on your marketing, contacts, planning, etc. but in any case, processwire is a time saver getting your things done faster.

foreach($users as $u) Worked. I figured that since I was setting content type header as json, that's why HTML was not working. Though I've been using PW for long, there's still a lot to learn. Something new learnt today, thanks a lot mate.

Thank you so much.I finally got this to work. I had to delete some lines from the sql file as it kept forcing an error, such a screat database, as it was already created and something about a module called ProcessRedirests. But it finally worked,thanks.

This is a little out of my technical know-how so I'm completely guessing here, but I would say the reason the html isn't printing is because you have set the content-type of the document to application/javascript or application/json. Also $users is a variable that should only be used in context to the ProcessWire API. http://cheatsheet.processwire.com/ You don't need $users = $pages->find() ... foreach($users as $u) should just work on it's own.

LMAO Apparently I was Ambassador to a latin american country.

Hello, Currently when adding an image field, we can add a min. and max. image dimension for them. We also can overwrite some fields based on the template in which this field is used. Would it be possible to add the min. and max. image dimensions to those template overwrites? Currently when building a website I quite often use the image field to hold different 'types' of images. On e.g. the home page template this could be a hero image, and on the blog template this is a highlight image. In both templates, the images have different image dimensions. To make sure the image always looks crisp and to help the website editor, I always add a min. image width and hight for the image. Currently we need to add different image fields for those use cases, while they basically do the same thing. When we could set a template overwrite for these values, we can simply create 1 'image' field type and use it in multiple templates, with their own min. / max. image dimensions.

Yeah, mine too. I didn't realize that I was a dentist, math professor, and a porn star!

Sadly the name combination I wanted was taken up. So I had to go with XYLastname. I never realized my First + Last was so common!!!

Regarding a person's name, I would spell it out rather than use initials due to possible acronym conflicts. That said, it is more difficult today to find 'your name'.com available than 20 years ago. Also might want to consider whether seo is necessary. For example, whole name search results are far more 'fine' than using initials (again, acronyms). just my $.02

Hi henrik, this problem comes from the fact, that there is no outputformatting when bootstrapping PW. therefore image fields are always arrays even if they are set to max = 1 and all your textformatters won't work. https://processwire.com/talk/topic/5375-image-paths-when-bootstrapping-pw/ regarding your ajax problem: you don't need to create a file outside your site folder! you have two options: 1) create a separate template only for ajax requests and also a page for that (eg hidden page /ajax) - then you can just call this page and return your content 2) return your ajax content from within the same file. if you are using delayed output strategy that's really easy. all you have to do is put something like this on top of your template file: if($config->ajax) { // do your ajax stuff here echo 'i am an ajax response'; die(); } // regular call $headline = '<h1>' . $page->title . '</h1>'; $content = $page->body; and so on... hope that helps! good luck

Some useful API Stuff: $config->superUserPageID // return int (Super User ID) $config->guestUserPageID // return int (Guest User ID) $user->isSuperuser() // return bool $user->hasRole('superuser') // return bool to check for any role $user->isLoggedin() // return bool $user->isGuest() // return bool Normally you cannot delete the superuser. Is there a change of Super User ID in your config file? Check if superuser exists with var_dump($pages->get(41)->name) // should return string like 'admin' or so If there is no page with ID 41 only solution is to manipulate your database and set the superuser page back to ID 41.

Hi, copy and pasting will often try and carry it's formatting. I'm going to assume you are using CKEditor when pasting in? There is an option to remove formatting when pasting it's a clipboard with a [T] next to it. To fix the a tag problem, Ryan fixed this in update 3.0.2 - https://processwire.com/blog/posts/processwire-2.7.2-master-and-3.0.2-devns/ If you find this problem still exists, please report it on github

What I commonly do: You have to import the .sql file data into a new database, you can do this through phpMyAdmin. Copy the Processwire backup files into your public_html (don't forget the sneaky .htaccess in the PW installation root, it is commonly hidden), and edit site/config.php and edit your database data: $config->dbHost = 'localhost'; $config->dbName = 'dbname'; $config->dbUser = 'dbuser'; $config->dbPass = 'verydifficultpassword'; $config->dbPort = '3306'; If everything goes ok, it should work!

Writing some tutorials for Envato Tuts+ anyone have any recommendations of topics to help Processwire beginners? Starting with Installation, admin guide and themeing.

Guys - I feel the same. PW has largely such a consistently brilliant interface that anything even slightly off is amplified. At the same time, the image crop modules are essential. If any core-contributors or module-makers want to team up and move this along, please shout.

I would love to see this As much I like the existing crop modules, I honestly don't like the inconsistencies in the UI/UX between the new core cropping and the 3rd party ones, but I really want predefined cropping.

Thanks for taking the time to explore this stuff Peter. I like what you've done, particularly the tabs in the modal, for consistency with the Link dialog. I prefer icon/text of your drop zone to the one we've got now. Though I'd want the drop zone to be consistent whether in the editor or in the modal. There's also the consideration of what image field you'll be uploading to. If you've got multiple image fields on the page, you are going to have multiple fields to which you can upload to, so a single large dedicated drop zone in the modal would not work. However, I think taking your drop zone that appears in the page editor, and using the same exact thing in the modal would do a nice job of having an improved drop zone, while still allowing for the possibility that there may be multiple drop targets. I like what you've got going on the Image Gallery screenshot in grid mode, but it does blur the line between list mode and grid mode. Not saying that's undesirable, but that it's different from what was intended: for grid mode is to be the opposite of list mode, and keep it as minimal as possible with basically nothing but the images themselves. Whereas list mode is meant to spill all the beans. Behind the scenes, these two modes use the same markup as a matter of efficiency, just styled differently. So there are some limitations in that respect (they have to use the same thumbnails and such). When it comes to any image operation in a modal, the buttons are placed at the top because we don't want them to fall into a scrollable area that's hidden. An important function of the image editor is to allow for the option of working with the image at its actual dimension rather than scaled, which in many cases means part of the image may need to be in a scrollable region. After all, we have no way of knowing what the size of the modal will be as it depends on the client side. If we adopt a standard of having any buttons/inputs, etc. below the image, then in many cases they simply won't be visible. That's why the choice was made to keep those buttons/inputs at the top. However the buttons that affect the modal window itself (like closing it) are able to go outside the modal document and into the window footer. I prefer your use of defined labels for "width", "height", etc., rather than the current arrow icons. I was trying to save the translators some work there, but after using it awhile agree that text labels are better. As for cropping presets, I agree about the usefulness. But I also really didn't want to cancel the purpose of Horst & Apeisa's crop modules, which they've put a lot of work into and already do a great job of this, better than I could do. Maybe someday we can get those preset functions integrated into the core image editor with their help. But the current intention with the image editor is leave that need to dedicated modules, while accommodating the more basic general purpose cropping needs, especially for things like RTE inserted images where a preset isn't necessarily what you want. But if there's sufficient demand for "croptions" (love the label), maybe we can talk Horst and Apeisa into helping us get those in a future PW version. I'm conflicted on the Apply vs. Save Crop labeling. My eyes prefer Apply as you've got it, but that button is actually saving a crop rather than applying the crop to an existing image. I like to leave the option of letting the user determine whether the crop should replace the original, or whether it should become a new image. To me, the term Apply implies replacing the original, though maybe since we give them that choice separately, it's okay to use it here. I'll take it for a test drive.

I just dropped in for a quick minute, but wow! I'll look closer at these later tonight when I have time.

In addition to the Service Pages module mentioned by diogo, there is also a rest helper for processwire made by clsource. I am using it in a new project that implements bidirectional communication between mobile devices and a PW powered site. It is working great so far. I extended clsource's code to support basic HTTP Authentication.

You've been using MODX but now you've found ProcessWire. It’s totally amazed you and you can’t wait to get started. But…you are wondering where everything is. If this is you, read on… This guide is primarily aimed at those who are coming in from MODX and wish to know how to accomplish “MODX things” the “ProcessWire (PW) way”. This is not meant to be a full blown PW tutorial. It will focus on some key MODX concepts/tasks and how to accomplish those in PW. It will cover, whenever possible, both versions of MODX - Evolution and Revolution. The guide assumes that you’ve at least logged into a PW site and/or viewed a demo. The Table of Contents mostly reflects MODX terminology. Table of Contents 1. Manager 2. File System 3. Resources 4. Templates 5. Template Variables (TVs) 6. Template Files 7. Snippets 8. Modules 9. Plugins 10. Chunks 11. Miscellaneous 12. Examples - the PW way… a. Template Variables b. Snippets c. Modules d. Plugins e. Chunks 1. Manager In PW, the “manager” is referred to as the “Admin”. The default location of the Admin is www.yoursite.com/processwire. As of PW 2.3, you can rename the Admin to anything you wish during install. Just be careful to remember the name you use or you will be locked out! (If that happens, there are ways to get around it though). Logging into Admin, you will notice a tree just like in MODX. The Admin runs on jQuery UI and as you’ve seen, it is insanely fast! Don’t be fooled by its simple facade. PW is a really powerful CMS, highly extensible and very easy to use. Customising the PW admin is very easy. There are a number of custom themes available. It is also trivial to make yours. Custom Admin themes go into the folder site/templates-admin/. You can have only one theme at a time. On a related matter, if you wish to create a custom Admin page, it is easy to do so. See this thread for more info. 2. File System After installing PW, you will see two main folders; “site” and “wire” in your file system. Site is where all things related to your site reside. This is your playground and will survive an upgrade. Wire houses the Core. You will never have to go into that folder. 3. Resources In MODX, Resources can be many things (documents, etc.). There is no such term in PW. However, the most important “resources” you need to know about in PW are page and pages. Pages are a very powerful concept in PW. Page can refer to your website’s frontend pages, i.e. what can be viewable by your website users. I say can be for a reason. There are many uses for Pages in PW. This can be confusing to newbies but once you get the concept, you will appreciate the power of the system. Just because something is a Page does not mean it has to be viewable. It can have other uses such as a container that holds data for use by other Pages - in this case the Pages do not have to be displayed on the frontend. In fact, everything you see on the PW tree is a Page. That’s right; even the Admin and its components (Users, Roles, etc.) are all Pages! Still confused by Pages? Have a read here. Pages reside in the PW tree - you may have noticed . You can drag and drop pages to move them around. If drag and drop doesn’t work you probably have MySQL 5.0.5.1 installed. Upgrade your MySQL and you are sorted. The root of your site is the uppermost Page in the tree. In the default PW install this is called Home. You can change the name to something else. The default PW install comes with a number of Pages pre-installed. Try editing a Page. All those Fields you see on that Page when under the “CONTENT” tab? They are not default Fields. They are all Custom Fields! Yes, not even the Title! The only required Field for a Page is “name”. You find this under the “SETTINGS” tab on the page edit screen. More about Fields below… Other related stuff: Menuindex: As an aside, if outputting something like a menu, unless you state otherwise, it will reflect the tree hierarchy. Show in Menu: This functionality is covered by the Page status, whether hidden or not. Hidden pages do not get output on menus (more about menus later) unless explicitly stated so using PW API selectors (see below). Menu Title: No such term in PW. You can name your menu items what you wish to name them. Very important: All Pages must be assigned a Template. 4. Templates In PW, Templates mean something slightly different compared to MODX and many other CMS. MODX describes templates as: That is not entirely true of PW Templates. In PW, the term Template is used in the sense of the English definition of the term: PW Templates serve as a pattern for the foundation of your Pages. By foundation, I do not mean the HTML or CSS. Rather, the Template servers as blueprint for your Pages. What is available to the Template is available to the Page that uses it. Templates establish a pattern for the Pages by the inclusion of Fields to the Template. A Template can have as many or as few Fields as you wish. You can create as many or as few Templates as you wish. You can easily change the Template a Page uses when editing the Page. See under SETTINGS. Note that if you have Fields on that Page that are not in the Template you are switching to, those Page Fields will be lost! PW will warn you about this when switching Templates though. OK, so how do you show “Resources to the world”? That will be the work of Template Files which we’ll look at in section 6. 5. Template Variables A powerful feature of MODX is Template Variables (TVs). If you loved MODX TVs you will absolutely adore the PW equivalent. In PW, TVs are known as Fields. You can define your own Custom Fields. In fact, you will need to create your own in most cases. This is because PW does not have any required Field except for “name”. It is perfectly reasonable to have a Page with only the name Field! Many people do add at least a Title Field for such Pages. In the default PW install, the reason you see the Title Field in all Templates is because it has been set as a “Global” Field under the ADVANCED settings of the Field (edit the Field to see this setting). There are many types of Fields to hold all sorts of data - images, texts, urls, passwords, reference to Pages, etc. You can call your Fields anything you wish. You can call the Field for your main content “body”, or “stuff”, or “content” or whatever you wish as long as you follow the naming convention, i.e. “[a-z], numbers [0-9], or underscores (no dashes or spaces)”. Fields are reusable across different Templates. The order in which they appear on your Page follows the order in which they are arranged on your Template. However, it is important to note that: The order in which Fields appear on your page and/or the inclusion of a Field on your Page does not mean that: The Field will be output on the Frontend. The inclusion of a Field on a Page does not automatically mean it will be output; PW does not make that decision for you. It only makes the Field available to you to use as you require. You can output all or none or few of the Fields on your Page. The order in which Fields appear on a Page does not mean the same order will be reflected when you output the Page. You make that decision. Also note that you are able to arrange Fields side-by-side on your Page (via settings on the Page’s Template) to mimic your site’s layout or for other visual/ease-of-use purposes as you edit the Page in the Admin. You can also give each Field a label and a description. These will appear above each Field when editing a Page. In most cases, the content of Fields will be saved directly to the database. In the case of file related Fields, the path to the file will be stored in the database. There are no direct equivalents of MODX TVs “@Bindings” (data sources). These are inherently built into the different types of Fields. Note that you cannot run PHP code within Fields (so no @Eval). This is by design. Fields are a very powerful and much loved concept in PW. Just Google "custom fields cms" and you’ll see what comes up tops. 6. Template Files So far, we've seen that you create Fields, add them to a Template you've created and edit a Page using that Template to input your content into that Page’s Fields. So far so good but how do you output the content to the world? You do this via Template Files. Template Files live in /site/templates/. You have to create your own Template Files. In MODX, a Template will have both system fields, e.g. body, title, etc. and custom fields (TVs). Rendering a Template is achieved by adding MODX tags to your Template. In PW, in order for the content of your Page to be seen by the world, its Template must have a Template File (or there must be some other Template File associated with a different Template that is dynamically pulling and outputting elsewhere the content of a Page whose Template does not have a Template File). This does not mean that all content within a Page will be automatically output by the Template File. No; in the Template File you can choose to render all or some Fields present in the Pages using that Template or none at all! You tell the Template about the associated Template File when you create/edit the Template. PW assumes that there is a Template File with the same name as the Template in /site/templates/ and will tell you if it does not find one. However, you have two other choices. You can either enter an alternative name for your Template File or tell PW you do not wish to have a Template File for that Template. This means that a Template does not require a Template File. Obviously, in such a case, you will not be able to directly output the content of the Pages using that Template. In some cases, that is exactly what you want . As you get to know more about the system, you will find out how powerful and flexible the PW Template system can be. For instance, you can use your Template as a controller. That’s beyond this guide but feel free to search the forums for more info. Template Files are typically PHP files with logic to dynamically output your content. In most cases, Template Files are HTML with PHP tags inserted to output your content. The PHP in the Template File will in most cases be PW API. Hence, you will see things like $page and $pages in Template Files. The former always refers to the current Page and the latter to any other Pages in the system. These are very powerful variables in PW and give you access to ALL information about ALL pages including their Fields and whether those are empty or not, etc. See below for more info about these variables and have a look the docs too. Note that Templates do not care about what’s in your Template Files. In fact, they won’t even check. All they want is for you to tell them if and how you wish your Pages' contents to be rendered. Your Template Files can even contain pure HTML (although that won’t be dynamic!)! Your Template Files can have references to other things related (or not related!) to the Page using that Template File. For instance, within your Template File, you can pull in the 10 latest “posts” from your Blog or the Children Pages of that Page. There are just too many possibilities to list them all here. Don’t let the PHP in Template Files scare you if you are no coder. I am no coder but I am able to use PW. You will only need to know at least some very basic PHP to use PW. The most important are: echo; foreach; and if… Anything else is a bonus in most cases. In addition, you will need to know how to use the two most important PW variables - $page and $pages. With these two, most of what you would have done in vanilla PHP is covered. They are easy to use and to understand and very much follow the jQuery concept. Check out the docs to learn more. 7. Snippets In MODX, Snippets are the method by which MODX allows you to run dynamic PHP code in any of your pages. In PW, the term Snippets does not exist. What!?! Not to worry; in PW MODX-like Snippet functionality can be achieved in two ways: Template Files: Most PW Template Files are essentially dynamic PHP code. That’s Snippets for you right there. PW Modules: PW Modules do what MODX Snippets do and more (see below). It’s just an issue of terminology. For instance, the popular MODX Snippet WayFinder has a Module counterpart in PW. This is the Module Markup Simple Navigation. However, you do not need to use the Module to create a menu in PW. You can do the same thing using PHP in your Template File. See the default PW install for a simple example. Check out section 12 of this guide for example “popular-MODX-Snippets-to-PW-how-tos”. 8. Modules MODX Evolution defines Modules as “a program that can only be executed from within the manager.” There are PW Modules that fit this definition, for instance, the Module Batcher which is equivalent to the MODX Revolution add-on Batcher. However, there are other PW Modules that are executed in the frontend, e.g. Markup Simple Navigation previously mentioned. In fact, in PW, a Module is PHP that extends the functionality of PW. Modules contain PHP classes that adhere to PW’s Module interface. 9. Plugins In MODX Plugins are PHP code that are set to execute during certain system events. In PW, although the term Plugin does not exist (except maybe in reference to Modules), MODX Plugin functionality is easily doable in PW. This is achieved via Hooks. There is one difference though. In MODX, Plugins are standalone code you can download and install. You cannot download and install PW Hooks. Instead, PW contains many methods that you may hook into in order to modify the behaviour of the method. In other words, PW offers the ability to hook into its processes/events and manipulate them before or after the event or even replace them, etc. Hooks are usually invoked inside Modules. However, Hooks may be attached from anywhere that you use PW's API, for instance in Template Files. The average PW user will not need to use Hooks. For more info about Hooks check the documentation. 10. Chunks MODX defines Chunks as “bits of static text which you can reuse across your site”. There is no equivalent term in PW. You can, however, easily create Chunks in PW. You can create Chunks as a Page that contains various Fields each of which can act as a Chunk. This means you can have Chunks of all sorts of data. You can then set the Page you create to hold your Chunks as hidden (not available to searches). The Page can also be assigned a Template without a Template File to further limit frontend access. It can also be created as a child/grandchild of the page Admin. That will limit access by User (e.g. login required to view it in Admin). Accessing the Fields of that Page as your Chunks using PW API is quite trivial really. Since you can use labels and descriptions to further define each of your Pages’ Fields, this makes it quite easy to describe what each Chunk is for and/or give instructions on how to use the Chunks. See this example for more info. You can also simply use text files to pull into your content as Chunks. Personally I prefer using Pages as Chunks when I need to. In MODX, it is usual for many Snippets to use Chunks (HTML + placeholders) to structure their output (i.e. tpl Chunks). You do not need to do this in PW. Code output can be wrapped in HTML right within the Template File. The important thing to remember is that any Field in any PW Page is available to any other Page and any Template File. Cross-referencing Fields and Pages is child’s play. Seriously; it is that easy. 11. Miscellaneous Tag Syntax: PW does not use a templating language (tagging syntax) like MODX does. See this article why this decision was taken. I agree 100% with the approach and have come to realise its many benefits over using a templating language. However, there are two Modules that allow you to use template language tags in PW. I have never used them so cannot comment further. They are here and here. Settings Page: PW has no settings page like MODX. Many settings are set in the /site/config.php. Other MODX settings equivalents are interspersed in various places including caching content on a Template by Template basis and in Modules. You can also store custom settings needed for your site in the /site/config.php. You can even use Pages to store your settings as mentioned in section 10 (Chunks). Modularity: PW is a very modular system. The whole of PW is made up of Modules (Core Modules) that accomplish different tasks. 12. Examples - the PW way… In this section I will show you equivalent MODX versus PW add-ons as well as how to accomplish various task using PW “Snippets” equivalent. a. Template Variables As previously mentioned, MODX TVs are PW Fields (although PW Fields are more versatile). Outputting the contents of your Fields is very simple. echo $page->name_of_your_field; This gives you the contents of the Field in the current page. Works slightly different for image fields though. For other pages echo: One page $pages->get(ID or PATH or NAME, etc.)->name_of_your_field; //note replace ID with ID of the Page you want, etc. Many pages $pages->find("selectors"); //this will return an array. You can then go through the array using foreach as shown in the examples below to output the field(s) contents MODX - output main content of Page //MODX Evolution[*content*] //MODX Revolution[[*content]] ProcessWire - output main content of Page //ProcessWire echo $page->content;//note; this assumes you have a Field called content in the Template of the current page. In ProcessWire you can find Fields of other pages like so $fruits = $pages->find("template=yumyum, limit=10"); foreach($fruits as $fruit) { echo "<li><a href='{$fruit->url}'>{$fruit->title}</a></li>"; } //find 10 Pages that use the Template yumyum and echo their url and titles in a list. From these examples, you can see the elegance and flexibility of TVs done the PW way. Since there is separation between a Template and a Template File, you can conditionally echo out the contents of Fields found in Pages. b. Snippets Common MODX Snippets and PW equivalent Modules 1. WayFinder: Markup Simple Navigation or code in Template File (see head.inc in default PW installation for a simple menu). 2. Ditto (Evolution) and getResources (Revolution): Functionality inbuilt in PW. Use $page and $pages variables + selectors to find anything, anywhere. 3. Jot (Evolution) and Quip (Revolution): Comments Module is part of the PW Core. It is not enabled by default. You will have to enable it in the Admin. See also the related Comments Manager Module. 4. eForm (Evolution) and FormIt and FormItBuilder (Revolution): There are various Form parser codes in the Forums. There is also a commercial Form Builder Module. It’s not expensive, is developed by PW’s lead developer and proceeds support the PW project. 5. MaxiGallery (Evolution) and Gallery (Revolution): Presently, there is no equivalent. However, it is quite easy to build a photo album. See this tutorial in the wiki. There is also an Images Manager Module (still in alpha though). 6. AjaxSearch: Ajax Page Search Module. 7. Breadcrumbs: Quite easy to accomplish using PW API. See default PW install for an example. 8. FirstChildRedirect: Very easy to do using PW API like this: $session->redirect($page->children->first()->url); in a Template File. 9. getField (Evolution) and getResourceField (Revolution): Inbuilt in PW $page and $pages variables as shown above. 10. GetParent: Inbuilt in PW $page and $pages variables. E.g. $page->parent. 11. getPage: PW has inbuilt pagination as part of the Core (Pagination Markup Module). See this article for a quick tutorial. 12. UltimateParent: Inbuilt in PW API as rootParent. 13. if (Revolution): Use vanilla PHP with PW variable and selectors in Template Files. 14. VersionX (Revolution): Versioning for text-based fields is coming in PW 2.4 (release date summer 2013). Support for maintaining separate draft and live versions coming in PW 2.5 (Winter 2013/2014). Currently, there is also the Module Version Control for Text Fields. 15. getRelated (Revolution): No out-of-the-box Module for this. Has been previously accomplished using PW API in various ways. Have a look in the forums. 16. importX (Revolution): Import Pages CSV Module. 17. phpThumbOf: Thumbnail functionality is inbuilt in PW. There is also the Module Thumbnails that further extends this functionality. 18. getValue and getValues (Revolution): Inbuilt in PW. You can get the value of any Page using PW API - $page and $pages. 19. getFeed (Revolution): RSS Feed Loader Module. 20. MIGX (Revolution): Repeater Module which is part of the PW Core. It is not installed by default. You will need to do that yourself. For more info see this tutorial. 21. Articles (Revolution): See the Blog Profile Module. 22. NewsPublisher (Revolution): See below under Plugins. Examples MODX Ditto [!Ditto? &parents=`5`&extenders=`summary` &tpl=`tplBlog` &orderBy=`createdon ASC`&display=`6` &truncText=`Continue Reading This Article` !] PW equivalent $items = $pages->get(5)->children("sort=date,limit=6"); foreach ($items as $item) { echo $item->title; echo $item->summary;//etc. } //this assumes you have a Field called summary on that Page The first line in the above gives you all information about the 6 child Pages of the Page with ID #5. It returns an array. In other words, a basket of various documents containing all the info about those documents. Next, you traverse the array using foreach. In layman terms, you rummage through the basket picking goodies! In order to wrap HTML around the code output, we do it like this instead (there’s other ways to do it as well!) echo "<ul class='articles'>"; foreach($pages->get(5)->children("sort=date,limit=6") as $item) { echo "<li><p><a href='{$item->url}'>{$item->title}</a><br /> <span class='summary'>{$item->summary}</span></p></li>"; } echo "</ul>"; In this example, we have asked PW to grab the child Pages directly within the foreach rather than creating a variable $items first. MODX getResources // Output a list of child Resources of the current Resource, using the 'myRowTpl' chunk: [[!getResources? &parents=`[[*id]]` &tpl=`myRowTpl`]] PW equivalent echo "<ul>"; foreach ($page->children as $child) { echo "<li><a href='{$child->url}'>{$child->title}</a></li>"; } echo "</ul>"; //You might want to limit the number of child Pages you are getting if they are many! MODX getResources // Output the top 5 latest published Resources beneath the Resource with ID '5', with tpl 'blogPost': [[!getResources? &parents=`5` &limit=`5` &tpl=`blogPost` &includeContent=`1`]] PW equivalent echo "<h3>Latest Posts</h3>"; $posts = $pages->get(5)->children("limit=5"); foreach ($posts as $post) { echo $post->body; } c. Modules 1. Batcher and Docmanager (Revolution): Batcher Module (covers most equivalent functions). 2. DocFinder (Evolution): Inbuilt in PW default install. d. Plugins 1. QuickManager (Evolution): Several Modules can do this, i.e., Fredi, Page Frontend Edit and Inline Editor Modules. 2. ManagerManager (Evolution): Same functionality can be achieved using Templates, Access Control and the Modules Page Edit Field Permission, Page Edit Per User and Page Edit Per Role. e. Chunks See this example. Btw, the PW Cheat Sheet is you best friend... Hope this has been helpful! /kongondo