Leaderboard

We are now hosting our own store here at processwire.com (previously it was hosted through the DesignIntelligence bookstore). You'll see it as the STORE button on the upper left corner (next to FORUMS and MEMBERS). By hosting it here, we are able to provide better service to you. If you purchase a product through the store, your access in the forums is upgraded automatically at purchase time. Previously people had to request access or I had to track people down and tell them to create a forum account, etc. So the new system is much more automated. Now you can pay by credit card or by PayPal. Previously we could only accept credit card. Now you can purchase upgrades from one version to another. For instance, if you purchased ProCache Single and wanted to later upgrade to ProCache Developer, it lets you do so by paying only the difference in cost. This only works if you have done all the purchases through the new store. (If you did it through the old store and want to upgrade, then just PM me and I'll setup a special coupon code for you that subtracts the cost you already paid). The new store brings more revenue back to development of the ProcessWire project since our merchant fees are now a lot lower (2.5% rather than 10%). We will be adding more products to the store in the coming months, including more modules and enhanced ProcessWire support options for those that want it themselves or for their clients. A change to the FormBuilder and ProCache policies. Previously the developer or agency versions specified that you could install as many copies as you wanted, but only for 1-year (at which time you would renew if you wanted to install more). That time limit has been removed. When you purchase the developer or agency version of either product, you have no time limits. Incidentally, I've never enforced any time limits on either product, but just wanted to state it officially since I've recently been asked about it. The product pages also state this now. The only 1-year limitation that remains in effect is for support and upgrades. The new store lets you renew that automatically or manually, if you want to. The yearly support renewal cost is roughly 1/4 the product cost. For example, $10 for Form Builder Single. Coupon code (today through Saturday) To celebrate the opening of the new store and to make sure we put it through it's paces (not to mention, test the coupon code function) I've setup a coupon code that lasts from today to Saturday (April 1). The code will give you 10% off any Form Builder or ProCache version. The code is NEWSTORE. Please let us know if you see anything that we can improve in the purchase or checkout process. For those interested, the new store runs on IP.Nexus, which is a commercial add-on component to IP.Board (the forum software we use). The merchant gateway is provided by Stripe. A huge thanks to Pete (the forum administrator here) for recommending all this and helping to get everything setup.

What about merchandise? Like T-Shirts and this kind of stuff?

We recently won a pitch for a website of a larger organization that we hope will gain a lot of visits and interest (in our region). The specification book didn't force a CMS to be used but recommended using typo3 as the clients old website is already running with it. Of course(!) we are planning to build the website with processwire as it's our current CMS of choice (and because Typo3 is a pain in the a... ). After presenting PW to the client's IT-Department and the internal ressources that will be creating content they are interested but still not convinced because there are few example showcases and experience reports that match their organization size (1k+ employeers). As a result we were asked to collect some Information on large scale processwire sites and the companys behind them. Plus (if possible) give them some contacts on organization side who they can talk to about experiences (everyday work, performance, security). So: If any of you can help us with that (examples, contacts) your help will be greatly appreciated. I'm sure there will be a lot of interest for PW as a system when the website will be built with it.

This is an excerpt from an ongoing larger work that I am playing with so has a couple of references to things you haven't read - but it might be useful anyway. I notice that some new PW users are a bit confused about how they should structure their site within the /site/templates/ directory, so this is just some general waffle addressing that confusion rather than telling you what to do. Structuring Your SiteHere is a question that comes up in the forum more times than just about anything else: “I need to build a site that will have this bit as part of that bit and will need to have something over there while the bit under here relates to the image that isn't there and the entire lot needs to be static html….” What underlies the question and all its variant cousins is: “Is there a set way to structure the files for my site?” No. To be honest I am pretty tempted to finish this chapter here because that one little word really does sum up the entire point about ProcessWire, PHP, MySQL, Apache, JQuery and anything else that makes this system tick. None of it, including ProcessWire, is about how you want to structurally create your website; they are all tools that enable you to construct your site how you wish. Part of the problem, it seems, lies in the various demos and profiles that sdemonstrate how ProcessWire works and what it does. The very fact that they exist at all means that someone had to build them, and to do that, they had to structure them ... obviously. Developers and designers that have come to PW from other content management systems and who are used to having to follow fairly limiting guidelines automatically assume that the demo they are looking at represents how they MUST put the site together. Then they look at a different demo by another plonker and it is built in a completely different way. Bugger. The PW Templating System Most content management systems have a templating system of some sort or another. Sometimes it is based on a third party markup system, sometimes it is based around the idea of a huge amount of files that if you want to change you have to build overrides and put them in certain directories and then work out how to strip out all the ccs that is still in there. Some of them, particularly the ones that go on about CCK (Content Construction Kit, whoever that is) allow you a ton of versatility as long as you don’t mind that all the fields come complete with huge amounts of pointless nested DIVs and CSS referenced from one of the moons of Mars. Some have had this amazing idea that it is somehow really clever to separate the idea of an overall theme from the way components are laid out and therefore put them in completely unrelated parts of the file structure (some in the core that will be rendered useless at the next update). Anyone used Magento? The joke here is, of course, that none of this is about what a CMS is meant to do, it is about how to display the OUTPUT of a CMS, but somewhere down the line the two have got confused and the Content Management part of the system is now telling the public website part of the system how to do its job. And that brings me neatly to the ProcessWire Templating System. Which doesn’t exist. PW is a true CMS in that it gives you two layers of tools: Firstly it provides a way of storing, managing and processing data. Secondly, it provides an API that allows you to retrieve and manipulate that data. The bit it doesn't do is build your website for your – you are the designer or developer, you are probably the best tool for that job! There are a few rules … well, there is one rule actually, which we covered earlier: template files must have a php suffix and be kept in the templates directory. So, whether you construct your site using header and footer files included into your main templates, or whether you use a delegated approach or just one core template that you use to drag in markup from other files, or whether you use the API directly into a template, or as part of a php function or stored in a separate file, or whether you use jquery, ajax, JavaScript or anything else, this is all up to you and is NOT part of the PW system. It is back to how we started (in the main tutorial) with just one line of PW markup in an empty PHP file. <?php echo $page->title; ?> Now throughout this tutorial I will probably stick to some pretty basic construction – I will tend to use the API and PHP directly into a template file and possibly use an included header and footer just to reduce the amount of markup kicking around. However, this is not necessarily the best way of creating a website in PHP and PW, it is just a nice clear way; that is all. The PW forums have all kinds of discussions on different approaches for using PW and PHP and files and so do forums and blogs all over the web. The very fact that PW does not rely on one particular way to construct a website means that all those ideas from all over the place are perfectly valid and can probably be used in PW. Freedom is a wonderful thing, and so is a proper CMS. Joss

ProcessWire wordmark on the front, new logo as a neck print on the back. American Apparel BB401 T's. I'll take 5. Discharge printing too - none of this bulletproof plastisol stuff.

ere are few example showcases and experience reports that match their organization size (1k+ employeers). u building website no ? or u renovates company bathrooms ? tell.client look at web sites traffic not no. employee disclainer : i used to cleans bathrooms so i lookd at no. employee

underlines them for u i did

I think, following on from bwakad's comments and kongondo's (understandable) reaction is that the takeaway here is that you can't have too many example site profiles. What 'clicks' with one new user may well be different from what another new user has an epiphany with.

In the current version of PW (2.4) with the admin template, there is the facility for an Add New button. You need to set up a parent child relationship with two template - go to the Family tab in the parent template and under Allowed Templates for Children, chose you child template. Go to your child template, and under Family select the parent template for Allowed Templates for Parents. Save On the same tab you should now see Show in the Add-page shortcut menu? If it is not already selected, choose yes. You will notice that there are some useful instructions on the template too. An Add New button will appear above the Pages list that allows you to create a new page using this child template. You can create several of these combinations and they will be added to the Add New button. It will become clearer when you try it!

well this is interesting...most of us tell newbies to forget about the skyscrapers profile (because it is advanced; not for newbies!) for a while until they get a grip of the default profile;

Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.

This sounds like some typical .htaccess rewritebase stuff. Look in that file for pointers. Also try searching this forum because the subject of installing PW in a subfolder and whatnot has come up quite often.

They are knitted - I will lend you some needles...

I would love to buy one of those beards WillyC is wearing!

It's definitely getting closer to being ready diogo. To be honest I hadn't really thought about automatically capturing changes - I kinda thought that was already in the works here: https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes/ PTM is structured so that everything that is exported is based on the content of a parent page - all the child pages, templates, fields, page field content pages, etc. So it is designed to migrate new blocks of content. It can certainly update changes to these blocks to a live server too though. I guess it might be possible to make what you are saying work by using "Home" as the parent page of the export, so changes to the entire site are migrated. The automatic recording of changes so that the JSON file only contains changes is obviously the tricky part I'll read through mindplay.dk's experience in detail and see what suggestions I can garner. Off the top of my head I am thinking that maybe a simple approach might work - use the module's config data field to store and add to an array of pages, fields, and templates that change, captured whenever they are saved. That way I am not trying to record exactly what all the changes are, but rather just that something changed and therefore we should add that page/field/template to the list of things that needs to be exported. I'll think about it some more!

I found this today http://www.wei-wang.com/ExplainGitWithD3/ Very nice website for understanding some basic git concepts visually.

To clarify what WillyC is saying - there are DB tables that store the settings for template and fields. If you fire up something like PHPMyAdmin you should get the idea. The Page Tree Migrator (PTM) module that horst linked to is still in alpha, although I hope not for much longer. I just pushed a new update literally a couple of minutes ago that deals with some bugs that were introduced with a major new feature in the last version. I think PTMis very powerful and is a huge time saver when it comes to migrating fields, templates, and trees of new pages and their content. It should be able to solve your issue if you choose the correct settings (I have gone a little nuts on this?). It should allow you to export the new template structure (with the newly added fields) from your dev site and import them to the live site. The one thing I need to get this out of alpha is testers, but please do your testing first on two test PW installs. If it works as expected for your given scenario, then you should be good to use it on the live site.

Hi Etling, actually there is no prefered way to do this. Here is a module that may help: https://processwire.com/talk/topic/4420-page-list-migrator/ I haven't used it until now but have bookmarked it for the future. Adrian states it still alpha, but has done a lot of work to it allready. So more than worth a look.

Hi, I just unzipped and placed the module in the modules folder on localhost. To install this module the 'install' button is dimmed, does not seem to work. If I click the module-name itself then in a window it ask me if I want to install this module. But also nothing happens. Any suggestions? I use PW2.4 and am on localhost. EDIT>>>> I had to download and install Jquery Data Tables module first. In my opinion: when I see a text "requires..." I do not assume that I do not have it and WHAT it is. How is one to know what it is - a file or something - and if it is not installed in the core already? It would however be nice if this text - when not installed yet - could be: please download and install Jquery Data Tables module first! Any way it's working now. Thanks

You could always place the script outside the PW templates folder and bootstrap it to processwire so you still have access to PW pages and fields for grabbing the validation messages. http://processwire.com/api/include/

Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). 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. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.

Hey guys, I'm new here, and I'm loving ProcessWire and the community spirit so far. We're just about to start using ProcessWire for our new clients requiring PHP solutions. Moving in a Rails direction, structure in our projects is becoming more and more of a necessity. As such, I've tried to employ some MVCish techniques in creating a boilerplate for ProcessWire for getting projects going quickly. One of the primary goals of this structure is to make it easier to separate logic from markup, and to prevent tags from being split over templates. Keeping `body`, `html`, and structural markup open and close tags in the same file greatly reduces cognitive overhead, and reduces opportunities for mismatching tags to exist. This approach also reduces duplication, and is great for keeping files small, focused, and organised. The main structure of the boilerplate is well defined, and ready to use in production. The repo is available here: https://github.com/fixate/pw-mvc-boilerplate (link updated 2014/01/17) Structure Although not completely MVC (using classes for controllers feels redundant, there are no models, and a full MVC approach will require a fair amount of customisation), it is heavily MVC inspired. Additionally, the structure is an extension of Soma's delegate approach. File structure: ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── errors ├── partials // markup not specific to any particular template ├── views // layouts specific to a template ├── _init.php // used to load global and template-specific controllers ├── main.php // the 'alternate template' for all templates . . . **NB: This structure has largely been updated and improved - see the UPDATE - 2014/01/17 at the bottom of this post! Controllers Controllers hold template specific variables and functions. There is also a global controller responsible for making global fields, such as SEO fields, available everywhere, as well as being responsible for the actual delegation. Template logic should be handled as much as possible from within controllers. Views Views are responsible for handling markup and output. Views have available to them both the global controller, and their own controller. Logic should be, as much as makes sense, handled in a controller, with the view pulling the results in for display. Partials Partials hold markup not specific to any particular template on its own, such as the `<head>`, header, navigation, scripts, or footer. As with views, it is best to keep these as logicless as possible. _init.php _init.php is responsible for making controllers available to views. Controllers are only included if they exist - sometimes a template-specific controller may not be necessary, in which case you won't need to create one. main.php main.php is the default layout (equivalent to layout/application.html.erb in Rails) into which everything is rendered. This file has been kept small deliberately to let partials and views manage more fine grained markup structures, while this file serves the main site structure. A call to render_view(), defined in global-controller.php, is responsible for delegating rendering to the view of the current template. Additionally, there is a constant defined in globals-controller.php useful for serving different assets depending on if you are working in a local environment, or if your site is live. This is useful for preventing Google Analytics from running in a dev environment, or for using unminified scripts for debugging. This boilerplate eliminates the need to do much configuration when beginning a project, apart from having to change each template's alternate template in the admin. I hope this will assist in quickly organising and developing new projects! ------------------------------ UPDATE - 2014/01/17: ------------------------------ All files for rendering are postfixed with .html.php in good ol' Rails fashion. main.php has been removed in favour of mvc.php. mvc.php requires config/boot.php which then handles which controllers, views, etc. are used the main layout is now found in views/layouts/application.html.php - like Rails again. partials are now kept inside views/ each page template can have its own optional controller, or simply inherit functionality only from ApplicationController ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── core // core mvc files - base controllers etc. (project specific stuff does not go here) ├── errors ├── views // folder for template files, layout files, and partials ├── layouts // application layout ├── partials // markup not specific to any particular template ├── mvc.php // the 'alternate template' for all templates . . .

This is already old news to many of you here, but I finished writing up the full announcement today so figured I should post it (click the link below). Numerous upgrades and refinements make ProcessWire 2.4 our most friendly and powerful version yet! ProcessWire 2.4 is focused on listening to the feedback from of our users and answering with the best CMS experience for web designers/developers and their clients. Read the full announcement. For those upgrading from a previous version of ProcessWire, please read all of the upgrade instructions. Hope that you enjoy this new version! A huge thanks to Avoine for sponsoring the Field Dependencies feature new to ProcessWire 2.4!

Hi Antti, my wife crochets those - no joke. If you are serious about them, pm me your ear to ear measurements as measured from the top tip of one ear, then just under your nose and over to the top tip of the other side. I'll pass them on to my better half and get a qoute for you. I'll also see what can be done to mix in the new logo.

http://joshworth.com/dev/pixelspace/pixelspace_solarsystem.html (Actually, sadder than this site is the fact that I found out about it by reading the Adobe CC blog...)

man that was a lot of scrolling!

Yeah..beardscarfs ftw

Uh? Oh, I wasn't clear...by architects have no children, I meant the individual architect pages, e.g. Albert Khan, etc...have no child pages..Anyway, I sorted out your issue in the other thread...

Here is a working version...give me two minutes... EDIT: OK, here we go... Edit your search_form.php - add the following code: <p> <label for='search_architect'>Architect</label> <select id='search_architect' name='architect'> <option value=''>Any</option><?php // generate the Architect options, checking the whitelist to see if any are already selected foreach($pages->get("/architects/")->children() as $architect) { $selected = $architect->name == $input->whitelist->architect ? " selected='selected' " : ''; echo "<option$selected value='{$architect->name}'>{$architect->title}</option>"; } ?> </select> </p> Edit your search.php as you did above...but with the modification in the selector....and in the comments // added architect // if a architect is specified, then we limit the results to having that architect (architects field in those pages) if($input->get->architect) { $architect = $pages->get("/architects/" . $sanitizer->pageName($input->get->architect)); if($architect->id) { $selector .= "architects=$architect, ";//CHANGE YOUR SELECTOR AS SHOWN HERE $summary["architect"] = $architect->title; $input->whitelist('architect', $architect->name); } } Edit your CSS to style the new longer search form... Smile...am not such a bad guy

Sorry felix that I can't help you with what you specifically need, but I think - as SiNNut mentioned - it might be a good idea to break the clients questions down to concrete concerns instead of trying to cope with his diffuse discomfort. As a consultant I would ask the client what it is in particular he is concerned about and then trying to address this points. Narrowing things down to practical problems and their solutions makes it easier for you to compare PW with Typo 3 (which is indeed much overestimated) and to offer concrete solutions for concrete problems. (while showing him how easy it is to set up XYZ in PW he might even forget about his other concerns ...). In addition, offering solutions - even if it is only for a detail - gives you the chance to re-enter the driver seat and strengthen your position as an expert they hired for getting the job done. If you come up with a lot of references you are still not directing the process. That's the problem I see here. Hope that helps a bit. Good luck!

This is why I always open threads that show Willy's picture as last poster

Adrian, this module sounds more and more useful everytime. Next thing, you will be creating a "recording" mode that collects all changes that happen in PW during a certain period and makes it possible to export them as json to make late changes on published sites really easy! (did that sound like a suggestion?)

Except it will throw an error as I have never build a skyscraper and I don't live in Chicago. But other than that .....

OK, so Joss was faster...but yes, that's it.The first will find, for instance, all Skyscrapers that were built by "Joss"...the second will find all Skyscrapers in a particular City, e.g. Chicago...

Actually there isn't anything "special". The site will have to handle a pretty decent amount of traffic and there will be a lot of custom Code to connect the Website with various webservices. But that is even easier to achieve in pw than it would have been in typo3. It's just the Client that likes to have some sort of security apart from what we are telling him.

Certainly Apeisa, Wanze and Ryan come to mind as people you may want to talk to...perhaps...

This is wrong thread for this to be discussed. For me I assume you know what a module is and how to search for it, and finally install it. But as said this has nothing to do with Modules Manager.

Any module that has a requires line is saying it requires those other modules first in order to work. Perhaps it should display a toolkit on hover of the greyed out button or something to make it clear.

alexmercenary, How complex is the navigation? Do you even need a module? Set the child pages to hidden, and then try this: <ul> <? foreach ($page->children("include=hidden") as $c): ?> <li><a href="#<?=$c->name;?>"><?=$c->title;?></a></li>
 <? endforeach ?> </ul> P.S. Welcome to the forums.

A new project went live this week. We've been working hard the last couple month to redesign and relaunch the new SEV-Online site. It's now live at http://www.sev-online.ch (The non www. version is still the old site due to complications on company that handles the DNS.) The biggest challenge was to transport the old site from webEdition to ProcessWire. There was a lot of content that had to be taken care of. There was put a lot of work into importing articles and documents and also make sure most of the links and function still work, so some mapping had to be done using ID's of documents from the old system. This was especially tricky as the old system had a separate structure for the 3 languages in the old system, and is now handled with multilanguage feature of ProcessWire where each page contains the 3 languages. Nonetheless it was a pleasure to work with PW and it took everything I've thrown at it Although there were hard times were some bugs was found during the process, especially with multilanguage features. But the good thing is they're fixed. The site maintainers are very pleased to work with PW. Some general infos: The site is in 3 languages. Using built in ML, LanguageSupportPageNames. There's a register/login for members to see additional sections on the site. Members are synced from a CRM they already have. There's ~43K members that can create a account using their Member Nr and birthdate. Once they're registered they can change profil data that will then get back to the CRM. There's a calendar for events and courses that also visitor/members can send in new ones. There's a simple online shop using apeisa excellent shop module. We use Fredi for frontend editing. So almost all content can be directly edited via browsing the site. There's a simple widget system using page references, so they can build homepage and sidebar elements as they wish. There's many forms on site, that are all built using PW Form API (Inputfields), along with using jQuery Validation for better user experience. The navigation is quite large (number of entries) so I cached the markup generated by MarkupSimpleNavigation and use client side JS to highlight entries. Some modules used on this project: - LanguageSupport modules - PW Comments - Markup RSS - Hanna Code - MarkupSimpleNavigation - AdminTemplateColumns - EmailObfuscation (EMO) - FormSaveReminder - PageEditSoftLock - Fredi - CustomPageList - ModulesManager - Shop Module (apeisa) - Schedule Pages - Template Decorator - Template Notes - Video Embed Textformatter - MarkupCache Some custom site specific modules created along the way - Custom LinkAbstractor - Lots of custom hooks for doing things on save, indexing, page name and ocntent manipulations - Some custom Textformatters for LinksLists etc - Some custom Admin pages for managing member mutations etc.

Have tried $session->logout() maybe combined with $session->redirect($url) Make some PHP logic that says "if user is logged out show a login link or if user is logged in show a logout link. Also: https://www.google.nl/search?hl=nl&q=logout+site%3Aprocesswire.com%2Ftalk will give you alot of info on possible ways to get it just the way you want.

http://modules.processwire.com/modules/process-batcher/ https://processwire.com/talk/topic/5835-lister/ EDIT: was on mobile before. Batcher won't actually let you rename existing pages, but you can batch create pages easily. It will be possible with the upcoming Lister module though, or you could write some code to do it yourself - it's not that hard, but you do need to consider how you would batch rename - can you give an example of the format you might want, because you have to consider not just the title of the page, but also the name with determines the url of the page, unless you are talking about hidden pages (perhaps those that belong to a page field). I can't imagine you want page-1, page-2 etc. Do you have a schema in mind?

That's why I like this forum so much, non coders are not left out but are also learned into pw to become part of the scene.

Don't use it for the original source image. Simply save as PNG (not with the SaveForWeb-Plugin). Would assume you get 800-1600k filesize then. Upload it to site assets and do a test for the best quality / filesize: // you first need to install the PageImageManipulator $width = 680; $qualities = array(10,20,30,40,50,60,70,75,80,85,90,95,100); $options = array('sharpening'=>'none', 'cropping'=>false, 'upscaling'=>false, 'quality'=>100); // options for the image sizeing: max quality without sharpening $amount = 100; // unsharpMask default values $radius = 0.5; // " $threshold = 3; // " $image = $page->images->first(); $image->removeVariations(); foreach($qualities as $quality) { ini_set('max_execution_time', 15); $img = $image->pimLoad("{$width}_q{$quality}", true)->setOptions($options)->width($width, 'none')->unsharpMask($amount, $radius, $threshold)->setQuality($quality)->pimSave(); echo "<p>Quality: {$quality} :: Filesize: " . filesize($img->filename) . "<br /><img src='{$img->url}' width='{$img->width}' height='{$img->height}' alt='{$img->name}' title='' /></p>\n"; } If you have found the best quality value for your images you may try different values with USM-sharpening. (it is the same like with photoshop)

Usually the problem with using a PW page for processing a form is the HTML that is included in that page. You need a way to not have this extra stuff sent when requesting the page. How you do this depends on how you structure your PW pages - are you using head.inc and foot.inc includes, or are you using a main.inc? or are you making using of the before and after includes in config.php? You can make use of $config->ajax to see if the page was called via ajax, but then again, if it's just a form processing page, then you probably don't ever need to display it normally, so probably not relevant here. So, call that process page directly and make sure nothing gets rendered. Also, you mention that there is a redirect - is this coming from the process page to somewhere else? I don't think you want that when processing a form via ajax. You want the result of the processing to come back to the page on success. You can echo something back if you want. Here's a pretty decent tutorial: http://code.tutsplus.com/tutorials/submit-a-form-without-page-refresh-using-jquery--net-59

Interesting thread. MVC is still way over my head, but I'll give this a shot

Agreed. Also nice to see more Finnish agencies joining ProcessWire!

Then you need more likes, I gave you one xtra. (I appreciate that you're here)

Lets see if we can get a quick-start tutorial going here. We'll start with something really simple and then work up from there. Tell me when something makes sense and when it doesn't and we'll adjust as we go. My thought is that we'd make a tutorial that plays on the 'hello world' phrase and lists information about planets in the solar system, starting with Earth. To keep it simple, we'll assume that the basic site profile is installed, as that's what comes with ProcessWire (so there's no need to uninstall anything). But we won't start using any of it's files tat this stage. Instead, we'll start out by creating our own files. STEP 1 – Create a template file Create a new file called: /site/templates/planet.php, and copy+paste the following HTML into that file: <html> <head> <title>Earth</title> </head> <body> <h1>Earth</h1> <h2>Type: Happy planet, Age: Millions of years</h2> <p>Earth (or the Earth) is the third planet from the Sun, and the densest and fifth-largest of the eight planets in the Solar System. It is also the largest of the Solar System's four terrestrial planets. It is sometimes referred to as the World, the Blue Planet, or by its Latin name, Terra.</p> </body> </html> The above is just a plain HTML file with nothing specific to ProcessWire. We will use this as the starting point for our template, and we'll go back and modify it later. STEP 2 – Add a template to ProcessWire Login to ProcessWire admin and go to Setup > Templates. This page shows a list of templates currently in the system. Click the Add New Template button. On the next screen that appears, you'll see it found your "planet" template file. Check the box next to the planet template and click Add Template. You may ignore any other options that appear on this screen. STEP 3 – Creating a page using your template Your planet template is now in the system and ready to use, but it's not being used by any pages. So lets create a page that uses the planet template. In the ProcessWire admin, click Pages in the top navigation. This is a site map if your page structure. We want to create a new page under the homepage, so click the new link that appears to the right of the home page. The next screen has 3 inputs: title, name and template. Enter "Earth" for the title, and the name should populate automatically. For the template, select planet. Then click Save. Now you have created a new page using the template that you added. You are now in the page edit screen and you should see your title field populated with "Earth". Click the View link that appears on this page edit screen. You should see the output of the HTML from step 1. Click the back button in your browser to return to the edit screen. STEP 4 – Creating a new field Now you know how to create a template and a page using that template. You could create more pages using the same template if you wanted to. But that wouldn't be particularly useful – this template file is just a static HTML file. Lets make it dynamic by creating some fields and adding them to it. We are going to create 3 fields to represent the pieces of data that currently appear in our static template. These include the planet's type, age in years, and a brief summary. We will call these fields: planet_type, planet_age and planet_summary. In ProcessWire admin, click Setup > Fields. This screen shows a list of fields currently in the system, most of which are general purpose fields for the basic profile. For the purposes of this tutorial, we are going to ignore those and create our own. Click the Add New Field button. On the next screen, enter "planet_type" for the Name, select "text" as the Type, and enter "Planet Type" for the Label. Then click the Save Field button. Now that your field is saved, you are on the Field Edit screen. At this point, your field is created and ready to be added to your planet template. Optional: While editing your field, click the details tab where you'll see a select box for Text Formatters. Select "HTML Entity Encoder" – this ensures that characters like "<", ">" and "&" will be converted to HTML entities and not confused as HTML tags. While not required, it's a good practice for text fields like this. After you've done that, click the Save Field button. STEP 5 – Creating more new fields In step 4 we created the planet_type field. Now we want to create the planet_age and planet_summary fields. So in this step, you'll want to do the same thing for the remaining two fields: Create the planet_age field exactly like you created the planet_type field, but enter "Planet age in years" for the label. Create the planet_summary field exactly like you created the planet_type field, but chose "textarea" as the Type and enter "Planet summary" for the label. Note that a "textarea" field is just like a "text" field, except that it can contain multiple lines of text. STEP 6 – Adding new fields to your template Now that you've created 3 new fields, you need to add them to your planet template. In ProcessWire admin, click Setup > Templates > planet. You are now editing your planet template. In the Fields select box, choose planet_type, then planet_age, then planet_summary. You will see each added to the list. Cick the Save Template button. STEP 7 – Editing a page using your template Now that you have new fields added to your template, go back and edit the Earth page you created earlier and populate the new fields that are on it. In ProcessWire admin, click Pages at the top, then click the Earth page, and click the edit button that appears to the right of it. You are now editing the Earth page you created earlier. You should see the new fields you added, waiting for text. Enter "Terrestrial planet" for Planet Type Enter "4.54 billion" for Planet Age in Years Paste in the text below for Planet Summary and then click Save. STEP 8 – Outputting dynamic data in your template file While still in the page editor from step 7, click the "View" link to see your page. Note that it still says "Happy planet" for type (rather than "Terrestrial planet") and "Millions of years" rather than "4.54 billion years". That's because the page is still being rendered with just the static data in it. We need to update the template file so that it recognizes the fields we added and outputs the values of those fields. Edit /site/templates/planet.php and replace the static text in there with tags like this, replacing field_name with the name of the field: <?php echo $page->field_name; ?> If supported by your server, you may also use this shorter format which some people find easier to look at and faster to enter: <?=$page->field_name?> Here is the /site/templates/planet.php file updated to output the content of the page using tags like the above: <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <h2>Type: <?php echo $page->planet_type; ?>, Age: <?php echo $page->planet_age; ?> years</h2> <p><?php echo $page->planet_summary; ?></p> </body> </html> After making these changes, save your planet.php template file. Now view your Earth page again. You should see it properly outputting all of the content you entered on the page, including "Terrestrial planet" for Type and "4.54 billion years" for age. Any changes you make from this point forward should be reflected in the output. STEP 9 – Creating more pages, reusing your template For this last step, we'll create another page (for Jupiter) using the same template just to demonstrate how a template may be reused. In ProcessWire Admin, click Pages and then click the new link to the right of the home page. Enter "Jupiter" as the Title and select "planet" for the Template. Click Save. Now that you are editing the Jupiter page, enter "Gas giant" for Type, enter "4.5 billion" for Age in Years, and copy+paste the following for Planet Summary: Click the Publish button and then View the page. You should now see your planet template being used to output the information for Jupiter rather than Earth. CONCLUSION In the above, we covered the basics of how to develop in ProcessWire, including the following: Creating templates and their associated template files Creating basic text fields and adding them to templates Creating and editing pages that use your templates Outputting the values of fields in template files If all of this makes sense so far, I thought we'd follow up next with a tutorial to take this further: Adding and outputting photos for each planet Creating navigation that lists all the other planets that have pages in the system …and we'd keep building upon the tutorial from there. If you all think this tutorial is helpful, then perhaps this can be a draft for a real tutorial we'll put on the site, so all of your help is appreciated in making this as good as it can be.

I recently had to setup front-end system to handle logins, password resets and changing passwords, so here's about how it was done. This should be functional code, but consider it pseudocode as you may need to make minor adjustments here and there. Please let me know if anything that doesn't compile and I'll correct it here. The template approach used here is the one I most often use, which is that the templates may generate output, but not echo it. Instead, they stuff any generated output into a variable ($page->body in this case). Then the main.php template is included at the end, and it handles sending the output. This 'main' template approach is preferable to separate head/foot includes when dealing with login stuff, because we can start sessions and do redirects before any output is actually sent. For a simple example of a main template, see the end of this post. 1. In Admin > Setup > Fields, create a new text field called 'tmp_pass' and add it to the 'user' template. This will enable us to keep track of a temporary, randomly generated password for the user, when they request a password reset. 2a. Create a new template file called reset-pass.php that has the following: /site/templates/reset-pass.php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { $u = $users->get("email=$email"); if($u->id) { // generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789'; // add more as you see fit $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; $u->of(false); $u->tmp_pass = $pass; // populate a temporary pass to their profile $u->save(); $u->of(true); $message = "Your temporary password on our web site is: $pass\n"; $message .= "Please change it after you login."; mail($u->email, "Password reset", $message, "From: noreply@{$config->httpHost}"); $page->body = "<p>An email has been dispatched to you with further instructions.</p>"; $showForm = false; } else { $page->body = "<p>Sorry, account doesn't exist or doesn't have an email.</p>"; } } if($showForm) $page->body .= " <h2>Reset your password</h2> <form action='./' method='post'> <label>E-Mail <input type='email' name='email'></label> <input type='submit'> </form> "; // include the main HTML/markup template that outputs at least $page->body in an HTML document include('./main.php'); 2b. Create a page called /reset-pass/ that uses the above template. 3a. Create a login.php template. This is identical to other examples you may have seen, but with one major difference: it supports our password reset capability, where the user may login with a temporary password, when present. When successfully logging in with tmp_pass, the real password is changed to tmp_pass. Upon any successful authentication tmp_pass is cleared out for security. /site/templates/login.php if($user->isLoggedin()) $session->redirect('/profile/'); if($input->post->username && $input->post->pass) { $username = $sanitizer->username($input->post->username); $pass = $input->post->pass; $u = $users->get($username); if($u->id && $u->tmp_pass && $u->tmp_pass === $pass) { // user logging in with tmp_pass, so change it to be their real pass $u->of(false); $u->pass = $u->tmp_pass; $u->save(); $u->of(true); } $u = $session->login($username, $pass); if($u) { // user is logged in, get rid of tmp_pass $u->of(false); $u->tmp_pass = ''; $u->save(); // now redirect to the profile edit page $session->redirect('/profile/'); } } // present the login form $headline = $input->post->username ? "Login failed" : "Please login"; $page->body = " <h2>$headline</h2> <form action='./' method='post'> <p> <label>Username <input type='text' name='username'></label> <label>Password <input type='password' name='pass'></label> </p> <input type='submit'> </form> <p><a href='/reset-pass/'>Forgot your password?</a></p> "; include("./main.php"); // main markup template 3b. Create a /login/ page that uses the above template. 4a. Build a profile editing template that at least lets them change their password (but take it further if you want): /site/templates/profile.php // if user isn't logged in, then we pretend this page doesn't exist if(!$user->isLoggedin()) throw new Wire404Exception(); // check if they submitted a password change $pass = $input->post->pass; if($pass) { if(strlen($pass) < 6) { $page->body .= "<p>New password must be 6+ characters</p>"; } else if($pass !== $input->post->pass_confirm) { $page->body .= "<p>Passwords do not match</p>"; } else { $user->of(false); $user->pass = $pass; $user->save(); $user->of(true); $page->body .= "<p>Your password has been changed.</p>"; } } // display a password change form $page->body .= " <h2>Change password</h2> <form action='./' method='post'> <p> <label>New Password <input type='password' name='pass'></label><br> <label>New Password (confirm) <input type='password' name='pass_confirm'></label> </p> <input type='submit'> </form> <p><a href='/logout/'>Logout</a></p> "; include("./main.php"); 4b. Create a page called /profile/ that uses the template above. 5. Just to be complete, make a logout.php template and create a page called /logout/ that uses it. /site/templates/logout.php if($user->isLoggedin()) $session->logout(); $session->redirect('/'); 6. The above templates include main.php at the end. This should just be an HTML document that outputs your site's markup, like a separate head.inc or foot.inc would do, except that it's all in one file and called after the output is generated, and we leave the job of sending the output to main.php. An example of the simplest possible main.php would be: /site/templates/main.php <html> <head> <title><?=$page->title?></title> </head> <body> <?=$page->body?> </body> </html>