Leaderboard

You got the problem right there in the error message. A page need to first be saved before images can be added or loaded. I think the from processing tries to render image field with the uploaded image but isn't really yet uploaded or saved. Not sure what you're using this for but FormTemplateProcessor isn't meant to work with file fields and also not recommended for front end forms with uploads. Kinda big security risk there. There's some examples around for different forms for front-end with file uploads. http://processwire.com/talk/topic/2089-create-simple-forms-using-api/ long thread with various things. Some examples you'll find in my gists namely https://gist.github.com/somatonic/5236008 https://gist.github.com/somatonic/4150974

In my experience, clients understand and accept very well when you tell them that you created some constrains on purpose. The important is that they look at their website and their friend's website and see why theirs looks much better. I'm not implying that we should be offering all the control of Word to the client. I totally agree with using and communicating the constraints. Our RTE's are very constrained in their default configuration, relative to most other CMSs using RTEs, and that's of course intentional. I've spent a lot of my development career being opposed to web-based RTEs. But over time have come around to feeling that a constrained RTE is about the ideal situation… clients have a high level of comfort with it, as a result of it having similarities to desktop RTEs (Word, etc.). I've now had clients using TinyMCE for years (and now CKEditor) and I like the fact that it reduces the support burden a lot. A well constrained, quality RTE is going to make it very difficult for a client to break things. I'm especially a fan of CKEditor 4 paired with HTMLPurifier, for this reason. In the past, I've tried to get clients to rally behind Markdown. Dictator CMS (which had no RTE) was built around it, for example. I like Markdown, but it unfortunately takes a special client to adopt and like Markdown, and a lot of extra support burden for me. HTML is allowed in Markdown as part of the standard, and this is inevitably what clients resort to when they can't figure something out... which creates a new and perhaps worse kind of mess. GitHub-flavored Markdown seems to be a improvement in this respect. I'm sure there are both benefits and drawbacks to the blocks approach that's been mentioned, a compromise, like anything else. A CMS built around that is conceptually distant from ProcessWire, as we aim to keep layout concerns and markup generation out of the content management. In our environment, there is a clear separation between where and how things are output, versus management of content that is contained. Though for those cases where people do find the concept beneficial, ProcessWire also aims to be flexible, more than anything.

refer to this http://processwire.com/talk/topic/4114-как-вставить-flash-в-структуру-сайта/

Everyday I'm amazed by the PW member's support. Its amazing! I was over-complicating. So after nik's great post that I missed I added the to the module 'FieldtypePage', // add this line http://processwire.com/talk/topic/383-module-import-pages-from-csv-file/page-4#entry21476 Now I have the numbers of the roles I want to import separated by pipes, and it works great, never thought it would be so straightforward: "title","pass","email","roles","headline","member_district" "261","userspassword","afcob@net.com","99|3899","AGÊNCIA","Lisboa" I only read renobird's post, have framed the posts so I don't forget to read carefully next time https://www.dropbox.com/s/xyalrrel6pw2mp1/frame.jpg And it works great! Thanks again SiNNUT

..and there's no need to pass an object explicitly by reference in the first place. Just pass by value and it works as expected (for that part, that is). See PHP: Objects and references for more information. And in case it was for performance benefits, read "Do not use PHP references" as well.

The 'roles' field is of type 'page' and isn't supported by ImportPagesCSV out of the box. If you want it to show up you need to add something to the modules fieldtype array: 'FieldtypePage', // add this line I haven't tried it myself but nik has, so courtesy nik. For more info you should read his comment in this thread: http://processwire.com/talk/topic/383-module-import-pages-from-csv-file/?p=21476 Also pay attention to his words on how to reference the roles in your csv file. In this case i think it would be best to look up the id's of the roles you've defined and put them in your csv (find and replace, you know the drill). In case you don't know: you can look up the page id's of the roles in a couple of ways but hovering the edit link and looking at the status bar of your browser is easiest;

@lowlines: you're probably already aware of this, but if you've got a sitemap planned out already and just want to quickly create matching pages, Batcher is very helpful for stuff like that. You should check it out if you haven't already.

Holy cow! Pro Cache is f#$@ng awesome! ... Hell nooo! Whare are no mates in my messengers list to share my joyfulness!

@bcartier: The ImportPagesCSV-module can't do this as is. But I tried making a tiny addition to make it support FieldtypePage (those used to make page references) and it worked amazingly well. The only change needed was to add 'FieldtypePage' to $fieldtypes array (just before init() function if you take a look at the module file), like this: protected $fieldtypes = array( 'FieldtypePageTitle', 'FieldtypeText', 'FieldtypeTextarea', 'FieldtypeInteger', 'FieldtypeFloat', 'FieldtypeEmail', 'FieldtypeURL', 'FieldtypeCheckbox', 'FieldtypeFile', 'FieldtypePage', // add this line ); After that addition it's possible to choose a Page field when connecting the fields from the CSV to the ones in the chosen template. I had pre-populated categories at the target site and used their id's in the CSV file to reference those categories. Multiple categories worked like a charm as well, just use a pipe in between id's (123|456|789). Moreover, if you've got only one category per entry to reference, then you don't even need the id's of the categories - you can use paths as well. Here's a little example: cat.csv: title one two three four entries.csv: title,categories a,/cats/four/ b,/cats/three/ c,/cats/one/ d,/cats/two/ Import cat.csv using a template for categories with (at least) title field, under a page at /cats/. Then import entries.csv using a template for entries, having a title field and a page field. This should leave you with entries that are connected to categories. I hope this gets you somewhere. @ryan: Looks like page references could be supported very easily. I just used this successfully to import ~3500 pages with category references from an old site to a new PW one. But maybe there's still something else to be done before they're fully supported?

You can detect whether the current page was loaded from ajax by checking the value of $config->ajax from your template file: <?php if($config->ajax) { // page was requested from ajax } Following that, you will likely want to render the page differently to accommodate whatever you are doing from the javascript side. For instance, you might want do one of these: 1. Deliver alternate or reduced markup when loaded from ajax 2. Deliver a JSON or XML string for parsing from javascript Below are examples of each of these scenarios. 1. Deliver alternate or reduced markup when loaded from ajax You might find checking for ajax helpful when you want portions of pages to load in your site without re-rendering the entire page for each request. As a simple example, we'll use the default ProcessWire site and make it repopulate it's #bodycopy area when you click a page in the top navigation. (To use this example, you'll need the default ProcessWire site templates, though you can easily adapt the example to another situation.) To accomplish this, we'll update our main page template to only include the header and footer markup if the page is NOT being loaded from ajax: /site/templates/page.php <?php if(!$config->ajax) include("./head.inc"); echo $page->body; if(!$config->ajax) include("./foot.inc"); Next we'll update the top navigation to do ajax loads of the pages when the client has javascript (and leave as-is when they don't). Paste this javascript snippet before the closing </head> tag in the header markup file: /site/templates/head.inc: <script type="text/javascript"> $(document).ready(function() { $("#topnav a").click(function() { $("#topnav a.on").removeClass('on'); // unhighlight selected nav item... $(this).addClass('on'); // ...and highlight new nav item $("#bodycopy").html("<p>Loading...</p>"); $.get($(this).attr('href'), function(data) { $("#bodycopy").html(data); }); return false; }); }); </script> Now when you click on any page in the top navigation, it pops into the bodycopy area without a page load visible from your browser. And all pages remain accessible from their URL as well. Note that this is just a test scenario, and I probably wouldn't use this approach for the entire bodycopy area on a production site (it would make bookmarking difficult). But this approach can be very useful in the right places. 2. Deliver a JSON or XML string for parsing from javascript Lets say that you want pages in your site to return a JSON string with the page's id, title, and number of children when it is requested from ajax. When not requested from ajax, they will return their content as normal. To handle the ajax requests, you'd want to add something like this at the top of your template file before any other output. <?php if($config->ajax) { // this is an ajax request, return basic page information in a JSON string $json = array( 'id' => $page->id, 'title' => $page->title, 'numChildren' => $page->numChildren ); echo json_encode($json); return; } // not ajax, continue with regular page output And here is some markup and inline javascript you might use to test the ajax call on some other page (or the same one if you prefer). You would paste this snippet right in your site's markup where you want that info to appear. <ul id='info'></ul> <script type='text/javascript'> var url = '/'; // this is homepage, so replace '/' with page URL you want to load JSON from $(document).ready(function() { $.getJSON(url, function(data) { $.each(data, function(key, value) { $("#info").append("<li>" + key + ": " + value + "</li>"); }); }); }); </script> The above snippet would output something like this: • id: 1 • title: Home • numChildren: 5 To take this example further, you could build an ajax-driven sitemap or any number of web services. Conclusion Hope this helps you to see how simple it is to use ProcessWire to deliver output for ajax. These are just contrived examples, but hopefully examples that might lead to more ideas. In addition, much of what you see in these examples is also applicable to building web services in ProcessWire.

Michael van Laar was kind enough to make a vectorized version of the ProcessWire logo with several variations, and he sent them to me. This is the first time the PW logo has existed in a vectorized format. Now I'm thinking I need to have some coffee mugs, hats, t-shirts, or airplane banners made. Attached is a ZIP file of the logos he put together, in case anyone wants them to make their own "powered by ProcessWire" banner or anything like that. This will probably become part of a more formal media kit at some point. ProcessWire-logo-michael.zip

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

This thread is used as a place to collect: 1. links to posts in the forum answering (repeating) newbie questions 2. links to posts in the forum and elsewhere on the net giving good insight in processwire 3. links to good articles about processwire 4. links to good tutorials posted in the forum 5. links to movie clips 6. links to posts in the forum talking about modules 7. code snippets or links to code snippets 8. Usefull Helpfiles Many good posts that answers (repeating) newbie questions or give good insight in the how and why of processwire, links to tutorial posts, (also on the net), movie clips, clarifying articles and code snippets are spread over the forum. PM me if you know a link. About this kick start see this post: http://processwire.com/talk/topic/4143-wordpress-dominates-19-of-the-web/page-2#entry40910 This is a work in progress, it takes time to make it grow bigger and better. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = STARTING NEWBIES AND DESIGNERS Link1: Starting and growing with processwire. https://processwire.com/talk/topic/3990-another-simple-photo-gallery-tutorial/page-4#entry61069 Link2: I am basically a designer with some programming skills. My question is this: Can I go ahead to use processwire for this even though i am still learning php. http://processwire.com/talk/topic/3954-starting-out-with-website-intranet-and-internet/ Link3: Feeling overwhelmed http://processwire.com/talk/topic/3215-newbie-overwhelmed/ Link4: Questions concerning PW and it's capabilities http://processwire.com/talk/topic/1557-questions-concerning-pw-and-its-capabilities/ NEWBIES FIRST CODING QUESTIONS link1: Using a default install, I'm stepping through the tutorials, templates, etc and trying to understand the basic concepts behind processwire and at this point in time "head.inc" & "foot.inc". http://processwire.com/talk/topic/3421-footinc/ Link2: I am puzzled why some html tags are starting in head.inc but don't end in head.inc Instead they are ended in foot.inc http://processwire.com/talk/topic/3388-question-about-headinc-and-footerinc/ Link3: Question about not using ?> in processwire http://processwire.com/talk/topic/3370-question-about-missing/ Link4: After you installed processwire, it comes with a default website. What is the best way to fill in your own website ? How do you replace the default processwire website with your own ? http://processwire.com/talk/topic/3379-how-to-fill-in-your-own-website/ Link5:How much extra work/time will I have to put in, as far as understanding and writing php and getting the hang of the PW system, just to be able to create the same responsive designs I would make in HTML/CSS/Javascrip, while also achieving the easiest type of content editing capabilities (in line with what you can get with a CushyCMS type product)? http://processwire.com/talk/topic/3961-new-to-cms/ Link6: I realize what I am confused about was really something quite basic, such as where are the snippets of php code go beside on templates? Can they go on a page as the value of body field for example? http://processwire.com/talk/topic/3383-back-to-basic/ Link7: I'm stuck in something that should be very simple. http://processwire.com/talk/topic/3720-my-first-doubt-using-pw/ Link8: Several questions before I can start. http://processwire.com/talk/topic/3589-several-questions-before-i-can-start/ PROCESSWIRE CMS INSIGHTS Link1: Reading this thread makes you understand processwire real quick. http://processwire.com/talk/topic/5667-help-a-noob-get-started/ Link2: Very good case study from RayDale giving good insight in processwire http://processwire.c...a-a-case-study/ Link3: Symphony or Processwire ? Another good insight. http://getsymphony.com/discuss/thread/79645/ ARTICLES Link1: Why he choses processwire over modx http://www.mademyday.de/why-i-chose-processwire-over-modx.html COMING FROM MODX ? Link1: 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… http://processwire.c...ning-from-modx/ Link2: A MODX refugee: questions on features of ProcessWire http://processwire.com/talk/topic/3111-a-modx-refugee-questions-on-features-of-processwire/ Link3: Code comparison between modx and processwire. http://processwire.com/talk/topic/2850-processwire-for-designers/page-2#entry30349 COMING FROM DRUPAL ? Link1: How to move your site from Drupal to ProcessWire. http://processwire.c...ndpost__p__8988 PAGES IN PROCESSWIRE Link1: Understanding pages in processwire http://processwire.com/talk/topic/5667-help-a-noob-get-started/page-2#entry55820 Link2: More about the function of pages in processwire http://processwire.c...fused-by-pages/ Link3: How to hide Pages from the Topnavi via Adminmenu http://processwire.com/talk/topic/2037-how-to-hide-pages-from-the-topnavi-via-adminmenu/ TEMPLATES IN PROCESSWIRE Link1: A good post with code examples to start a template http://processwire.com/talk/topic/43-template-tutorial/ Link2: Template design a better route http://processwire.com/talk/topic/2782-template-design-better-route/ Link3: A different way of using templates http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/ FRONT-END / BACK-END Link1: ProcessWire Setup and front-end editing made easy http://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/ Link2: Creating a front-end admin http://processwire.com/talk/topic/2937-creating-a-front-end-admin/ Link3: How would I build functionality and write information from the front-end to the back-end? http://processwire.com/talk/topic/2174-writing-from-front-end-to-back-end/ Link4: Is it possible to create a custom login page like a template ? http://processwire.com/talk/topic/107-custom-login/ Link5: A "members-only" section in the front-end. Integrating a member / visitor login form http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/ Link6: Trouble deleting pages from the front-end. http://processwire.com/talk/topic/2290-trouble-deleting-pages-from-the-frontend/ MODULE Front-end Edit. It turns the content of $page->body into a clickable area and gives the ability to frontend edit the content via tinyMCE http://processwire.com/talk/topic/3210-module-frontend-edit https://github.com/Luis85/PageInlineEdit/ MODULE Fredi, friendly frontend editing. http://processwire.com/talk/topic/3265-fredi-friendly-frontend-editing/?hl=fredi http://modules.processwire.com/modules/fredi/ MODULE Admin-bar Provides easy front-end admin bar for editing page content in ProcessWire 2.1+. http://processwire.com/talk/topic/44-is-there-way-to-get-information-about-current-user-in-templates/ http://processwire.com/talk/topic/50-adminbar/ http://modules.processwire.com/modules/admin-bar/ MULTI LANGUAGE WEBSITE IN PROCESSWIRE Link1: Multi-language website page names / URLs http://processwire.com/talk/topic/2979-multi-language-page-names-urls/ Link2: API http://processwire.com/api/multi-language-support/multi-language-urls/ Link3: The name of the default language can't be changed in Pw, but the title. http://processwire.com/talk/topic/4145-recoverable-fatal-error/#entry40611 ADD NEW USER TO YOUR WEBSITE AND PASSWORD RESET Link1: Integrating a member / visitor login form http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?hl=%2Bpassword+%2Breset#entry15894 Module http://processwire.com/talk/topic/2145-module-send-user-credentials/?hl=%2Bpassword+%2Breset BASIC TUTORIALS FOR NEWBIES Link1: Approaches to categorising site content http://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ CODE SNIPPETS AND FUNCTIONS Link1: Get page id from images object https://processwire.com/talk/topic/6176-get-page-id-from-images-object/ Link2: Function to render Bootstrap 3 carousel markup from ProcessWire images object https://gist.github.com/gebeer/11200288 .HTACCESS EXAMPLES ON YOUR HOSTING SERVER Example1: A working .htaccess file. The issues were that the .htaccess file must exist on the server before installing processwire and that the server did not allow options in the .htaccess file. After fixing that processwire could be installed on the server without any problem. Note that such restrictions might be different on your server that you need to find in the faq of your host. RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?q=$1 [L,QSA,NC] HTML KICKSTARTER Link1: How can i integrate HTML Kickstarter with processwire? http://processwire.com/talk/topic/2731-how-can-i-integrate-html-kickstarter-with-processwire/ MOVIE CLIPS Field dependencies are coming in ProcessWire 2.4. Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. https://www.youtube.com/watch?feature=player_embedded&v=hqLs9YNYKMM HELP FILES Cheatsheet Link1 Cheatsheet 1.1 as pdf file Download: http://processwire.com/talk/index.php?app=core&module=attach&section=attach&attach_id=1299 Link2 Cheatsheet is now a processwire site (great work by Soma) http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-find-selector/ INTERVIEWS Link1: About the history and coming to be of processwire http://processwire.com/talk/topic/4084-about-ryan-and-processwire-an-interview-with-ryan-cramer/

http://processwire.com/talk/topic/3775-formbuilder-export-to-csv-or-excel/

Welcome Demiansan to pw. Inside this collection of posts http://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/ there is this post about how to switch from drupal to processwire. http://processwire.com/talk/topic/1015-switching-from-drupal-to-processwire/

$pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->template == 'article') $e->return = "/blog/$page->name/"; } http://processwire.com/talk/topic/1799-routes-and-rewriting-urls/

Did couple of quick tests and there's no problem with this (just like @Soma pointed out above.) Sounds like it's something about your "more complex" thing that's broken.

Thanks adrian that's exactly what I needed. My module is based upon AfterSaveActions but extends what it does to other parts of admin. To answer your question, auto-publishing would likely only be used during the initial site setup where the client isn't doing the majority of the page creation. Often I have a sitemap before the actual content so it is better to at least get the structure setup rather than the whole process getting bottlenecked. Then once the site is at a complete enough stage we would toggle off auto-publishing so clients can create any future pages without them automatically going live. In the early stages, the less button clicks / steps required to do something the better!

Hi lowlines and welcome to PW. Not sure if you have seen this module or not: http://modules.processwire.com/modules/after-save-actions/ but it allows you to control what happens after a page is saved. Not sure exactly what would be your best option, but you should be able to hook into before save, eg: $this->pages->addHookBefore('save', $this, 'setPublished'); The setPublished function would then remove the unpublished status for the page. Does that help at all? Also, have you seen: http://processwire.com/api/hooks/ http://processwire.com/api/hooks/captain-hook/ EDIT: Have a read of this: http://processwire.com/talk/topic/2331-doing-additional-logic-after-saving-a-new-page/?p=21881 Talks about doing additional logic after saving a new page and so I think might suit your needs. Might be the addHookAfter('added' that you are looking for, although do you really want to publish a page that has just been created and still only has a title and name field assigned?

To me it sounds more like you want a custom admin page to frame a pho ftp client to access and upload your design files from the admin instead over a IDE or coding tool ftp.

OK. So just make sure you do not delete that "settings" page . You can create it as a child of admin so that it is hidden from the frontend.

Here is a revised version of the module. It accepts all Page::status options, eg. $form->pagestatus = Page::statusUnpublished; $form->pagestatus = Page::statusHidden; If left blank, then the page will be published. Not sure if this is really an ideal default. Maybe it would be good to get some input from others on this. FormTemplateProcessor.module

To give you some ideas, here is what I do. I append my site name to the end of every <title>, it helps with SEO, bookmarks, etc. OrganizedFellow.com To the left of that I prepend the category name, whether it be Blog/Article, Products, Contact Page, About, etc. Blog | OrganizedFellow.com To the left of that I prepend the title of the page itself. I took up jogging | Blog | OrganizedFellow.com Contact Me | organizedfellow.com Screws and Nails | Products | OrganizedFellow.com There is no ONE way. Feel free to do it how you like.

Ha! Now I have another ten pages to read, along with those 30 designer depot etc. articles piled up in my inbox and a couple of issues of .Net gathering dust under the bed. I'm actually working on ClipperCMS, a fork of Evo, now, and it's while researching something that cropped up during a write-up of its API that I found your post. I suspect it's what I needed some time last year to help me make sense of PW, since my brain has been rewired to view the world from an Evo standpoint. And now I'll have to read it and have another look. Pretty much like MODX, in fact - my first reaction to that was: "Oh no, another CMS that keeps everything in the database" (after finding Joomla site after Joomla site like watching paint dry as the page built up from bits & pieces). Something spurred me to have another look at MODX later, and I latched on to it immediately second time around. I'm pretty committed to Clipper, I think it has a great future for Evo fans, but I'm sure it's worth having a go at PW as well, and your guide could well give me the boost I need to do that in a reasonable time. TVM! KP

I love this module too! I noticed that it doesn't seem to list Page References created inside Repeaters. That would be a nice addition. -Brent

i.am first you can puut this in your head.inc tamplate or some includeded file before.u are doing $page->url $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->template == 'article') $e->return = "/blog/$page->name/"; }

For something like that, I think you'll be better off just importing from the API. Probably 70% of the time that I need to do any kind of importing of anything, I just use the API because it usually makes a quick and easy job of it, without having to consider any limitations. But if you want to get image/file descriptions in with the CSV import module, then I would probably create a temporary field to store them in, for import purposes. Then go back and paste a little code in a template to quickly convert them over: foreach($mypages as $p) { $p->of(false); $p->image->description = $p->temp; $p->save(); } Once you've done that, you could then go and delete that 'temp' field from the template.

Hi Jason, if you're doing it just for a few pages, you don't need any module/plugin; you can do this simply by using templates! Create field 'redirectTo' – customizable, of course Set that field to be 'single page', and select the inputfield you wish Create template 'redirectPage' – again, custom put following code in your template file Create page that links to original page you've made your virtual page Code for your template: <?php /* * Template: redirectPage * * Used to redirect URL adress to other page with 301 HTTP code */ $session->redirect( $page->redirectTo->url ); I actually use this at least once each site.

Thanks for taking the time to think this through. I agree with everything you've stated here, and also like the execution in the screenshots (and the link style for 'keep unpublished'). After seeing Benbyf's message today, I am thinking we might do one more thing to highlight that it's unpublished... perhaps strikethrough text for the page title in the editor, as well as in the page list, just so there's no way to miss that it's unpublished.