Leaderboard

Absolutely, I consider it essential. Placement of images is one of many reasons to use an RTE, but it's a big one. Our tools were somewhat lacking in this area before, and that may have even been a reason not to use them. CKEditor is perhaps the Inputfield that our (or at least my) clients interact with the most in PW, and I'm committed to making sure the tools we provide in this area are the absolute best they can be, as with all areas of ProcessWire. That doesn't mean you have to use all the features an RTE provides. In fact, I rarely recommend doing that. You may find some features suitable for some situations more than others, and you have control in your field settings to determine what is available. There are some site designs I work with where I'll turn off the ability to insert images at all (or even turn off the RTE all together). But there are also plenty of site designs I work with where that ability is very important to the client or the needs of the site. One of ProcessWire's key benefits is not pushing assumptions about the front-end, or pigeonholing the software into some specific types of sites. We're trying to accommodate a diverse range of needs, not just specific ones. We accommodate specific needs with configuration. We've always provided image placement capability in our RTE, but with limited ability to manipulate the image beyond just resizing it. I've been looking to make this part better for a long time for the needs that I see with my own clients. That's what the first paragraph of the blog post was trying to explain. Beyond that is selling PW itself. It's one of those things that users look at when evaluating a CMS. Regardless of what you may think about RTEs in general, lack of RTE is a deal killer for many/most, and how good the RTE and related tools are is a seller. Look at WordPress, which is limited relative to PW in so many ways, but their tools like the one discussed here have always been significantly better than ours. ProcessWire has very little in common with WordPress, but when compared side by side for editing features, things like this make WordPress look better to the casual evaluation. This is one reason why you see WordPress used in so many inappropriate scenarios. So when it comes to tools that we provide already, I want to make sure they are the best they can be, and not just half way. That has not been my experience. I have had clients mess up things in RTEs, but rarely related to images. It's usually about typography, so I like to introduce limitations about what markup elements the client can use, particularly headlines. CKEditor with ACF and Purifier enabled has also solved the vast majority of clients-messing-things-up issues I've had in the past. Maybe your experiences are different, but these are the problems with images that I've seen with my clients: It's nearly always about poor image selection, not placement. By that, I mean the client will upload really bad stock imagery of business people on 1990s cellphones and such. This issue has nothing to do with an RTE, and is an issue anywhere the client can upload images. Clients rarely have the image tools [on their own computer] necessary to prep their image before uploading. They've not had a way to crop images to make them right for the context. For instance, needing to show a picture of a specific person but instead having only a photo with a group of people, and using anyway. Though this update does solve that problem among other things. I understand there are site designs where you want limit what the client can do with images, or maybe you want to prevent them being able to place images in text at all, leaving that for your own code to handle. This lets you have more control over the resulting layout. I get that, and I work on plenty of those too. But understand that this is a specific need in some layouts, not a universal need in every site or design. The same goes for use of an RTE at all. There are plenty of situations where entity encoded plain text or an LML like Markdown or Textile is more appropriate. But for situations where an RTE with image placement capability is the appropriate tool, I want it to be as good as it can be. This is a tool we already have, and so this update was about enhancing that tool to make it better for its intended purpose.

I recently created an ecommerce website, iBuildMacs, that I built with ProcessWire. Given that there's been quite a bit activity on combining ecommerce with ProcessWire, I feel many people would be interested in the approach I took. Feel free to visit it at: http://ibuildmacs.com/ The requirements for this site were: a computer configurator, much like the Apple website; example product page here cart checkout payment methods: paypal or check/cash shipping methods: the cost of shipping is based on a fixed cost that is related to the country being shipped. no live quotes The requirements did NOT include: tax rules inventory management coupons, gift certificates different product types: simple products, variable products, digital/downloadable products, etc. user accounts, address management a fancy ajax driven checkout So, I had a bit of flexibility for this site given the specific feature set. I then thought about how I wanted to develop the site. The options I considered included: WooCommerce: I've built several intricate websites with WooCommerce, the most recent being caviar.com. It was good fit that website, but for iBuildMacs, which has less requirements and a very unique product configurator, which WooCommerce could do but with a tremendous amount of overrides and working backward, I decided this wouldn't but the right fit. Plus, I'm trying to become as WordPress-free as possible. FoxyCart: A ProcessWire favorite, however I wanted to challenge myself a little bit with this site, and also keep things under one roof. Magento, Shopify, (insert some specific heavy or cloud-based ecommerce system you like): No. Overkill and making a product configurator would be a pain. After considering my options, I felt just rolling it entirely with ProcessWire and programming the catalog, payment methods, shipping methods and checkout tailored to the site's specific needs was the way to go. This would definitely reduce the time and headache needed in bending anyone of the above systems I mentioned to behave exactly the way I wanted it to. Products This was one of the complicated parts of the website, but ProcessWire, with its infintely flexible custom fields, made this a breeze. I have a product template (product.php). It has some general fields like Title, Body, Image and Base Price. It also has a PageTable field called Features. These features are child pages of the product and use feature template (feature.php), so the Features PageTable field just grabs its data from there. Then, the feature template has some general fields like Title, Body, Image and PageTable field called Feature Options. These feature options are child pages of the feature template using the feature option template (feature_option.php). So, what I ended up having is a 3 level deep structure, with two nested PageTable fields. Here's a video of what it looks like, which is quite slick is very easy to manage: https://vid.me/kjDW Cart When a user adds a configured product to their cart, it must be stored somehow and I thought of a variety of ways to do this. Ultimately, I decided that cart data is handled as a page (using the order.php template) undernearth /orders/. This order.php template has a page name that is based on the session id of the user, so it'll remain unique and not cause a conflict with other people's carts (as well as obscure from people trying to guess it's url, which is used for the order confirmation page). One of the fields in this order.php template is called "products_ordered", which utilizes the Table fieldtype (a Profields table). Video: https://vid.me/MIRl Checkout The checkout is a straight forward form with the basic questions. However, the shipping section is where it gets tricky. The requirements for this site were that each computer has a fixed shipping price depending on the method being used to ship. The shipping methods available to a customer are dependent on their country. I think WooCommerce could manage rules like that, but directly coding it wasn't that difficult. I create an array that stored the 2 payment methods, and another array that stored the 6 total shipping methods. I also have an array for all the countries. I then wrote some JavaScript that managed the relationships between the country chosen and the shipping methods available for the chosen country. When choosing a method, it will update the Shipping cost line item on the car to the right. Just basic JavaScript going on here. All nice and on one page. When the submit button is pressed, it will run through some logic and validate all the data and save it to the same page that stored the cart data. An order confirmation email is sent to the customer, and one is also sent to the admin (SwiftMailer). If Check/Cash was chosen, the user is then simply forwarded to the order confirmation page, which is at /orders/whatever-their-page-name-was-saved-as/. The email they are sent also has a link referencing this page. If PayPal was chosen, a URI is built and the user is taken to PayPal complete payment with PayPal Payments Standard using the Cart Upload command. Documentation here. After they complete Payment on PayPal, they are then taken to the order confirmation page as described previously. Video: https://vid.me/hwfB I will eventually be using ListerPro for a nicer admin orders list display and build a few custom actions to allow administrators to quickly send general emails from the system (like, when the order is shipped). Modules Used Admin Template Columns: http://modules.processwire.com/modules/admin-template-columns/ Markup Simple Navigation: http://modules.processwire.com/modules/markup-simple-navigation/ Maintenance Mode: http://modules.processwire.com/modules/maintenance-mode/ Batcher: http://modules.processwire.com/modules/process-batcher/ Form Builder (for the contact form only): https://processwire.com/talk/store/category/2-form-builder/ Swift Mailer: http://modules.processwire.com/modules/wire-mail-swift-mailer/ PageTable field type ProFields Table: https://processwire.com/talk/store/category/7-profields/ ListerPro (eventually): https://processwire.com/talk/store/category/9-listerpro/ Enjoy!

@ last 3 posts - I agree but there are still times where, as long as you trust the person editing to do it properly, this is still okay (although not usually ideal, I agree). With regards to the craft screenshot and Apeisa's link to SirTrevor - this is the ideal way to handle this and I did actually start to play with an inputfield to accomplish this using SirTrevor but couldn't get it to work properly (I may go back and check it again now I've got more experience). The idea is simple enough - allow as many image fields and text editors as you like in a single fieldtype (I got that working) and simply have ONE textarea field that stores the order of the elements and the editor content as JSON. That way you just need one multi-image field to store the actual images, and the textarea field stores all the editor contents. A nice little render function would pull the content together to display on the frontend and you're sorted I think if I revisited it I wouldn't even bother with SirTrevor to be honest and I'd roll my own interface so as to keep the styling in line with the PW admin themes.

The problem I have with SirTrevor and other similar projects I've seen are that the actual editor experience just isn't as good. It feels downright unnatural relative to anywhere else one might edit text. When I experiment with SirTrevor and others, I can't convince myself I'd want to use it on my own site. And if I can't convince myself, I won't be able to convince my clients to use it. How would you like it if we switched to SirTrevor for the editor in these forums? I think we'd have a lot less activity. There is an assumption with these tools that the end user is actually authoring the content directly in the editor. That's what I do most of the time, but most of my clients author content offline or work with existing content created by somebody else. Basically they are pasting content and often lots of it. These block editors become an especially huge pain when you are doing that. Many other types of edits just become unnatural and clumsy. It's not about the implementation of the block editor being faulty in anyway, its just that the entire concept doesn't result in a better editing experience. Where I like the block editors is that it's less to accommodate and worry about on the front-end development side. It also opens up some other kinds of element placements and previews that would be difficult with a regular RTE. So I totally agree there is a place for these editors. But I don't think we'll ever see RTEs replaced entirely by block editors, no matter how good the implementation is. Though I'm sure we'll see some good hybrids.

Yeah, navigation in general is being discussed behind the scenes at the moment.

I'm with Soma on this one. I don't like using RTE's as well. What I would really like to see is something like craft is doing: I can see, that this is a quite complex thing with processwire's pages methodology and PageTables even provides something slightly similar already, but I see it more as a RTE replacement. You'd use it in places where you used only the RTE before. In my opinion such a field doesn't need to support more complex things besides images or textual elements. It would also just save markup for the frontend, while it would probably need to save the different fields somewhere as well. For me it's mostly about the interface. It just guides the user much more, so I would even think it's easier for them to understand, while in the same time limiting the potential points of error. Edit: I don't fully understand, why there's still a image-icon in the screenshot's RTE.

I think the best way to put a gallery in CKEDitor would be Hanna code to be honest - only sane way I can think of My Block editor implementation allowed multiple CKEditor fields too (in inline mode) so I'm going to stop referring to SirTrevor completely at this point as it's confusing. I'll try and revisit it this week as I think a lot of what I've been doing the last couple of days might help me get over the final hurdles with it and then I'll be confident about sharing a screenshot. Topic thoroughly derailed now though, sorry!

Congratulations! We are currently running over 100 pw powered websites / applications. Most of those don't have any kind of version control (other than modules). We have separate dev/staging installation, where development is done and then manually migrated into production site. That works pretty ok, since our clients tend to buy bigger updates instead of lots of little tweaks. Also few shell scripts to create new sites based on profiles, resetting the dev enviroment etc. Very simple setup, and we are currently looking little tweaks into the workflow (adding git and sass into mix for example). I think that we will still keep separate installations and (semi)manual deployment. What do you mean with migrations in this scene? If migrations from another system, then currently we always build custom migration scripts where needed. If data schema migrations when adding new features, then see deployment part of my answer. If something else, we probably do it manually also. We also have some software that we have build using ProcessWire (one big one coming) - there we have given much more thought on these issues, since we need to have it automated. We have our model installer, that reads YAML files and does templates/fields/pages based on those. That's pretty advanced and currently tied into our product, but might be something we could try to generalize a bit and release at some point. Well, depends what you are looking for. Front end fellows that have been fighting with Drupal or WP are very happy with ProcessWire. Backend guys who like PHP in general do enjoy PW also. More experienced PHP developers do find the documentation lacking, when you dive deep enough. All in all, PW is technology that most devs & designers find exciting and I think recruiting people into ProcessWire is "easy" (recruiting is never easy, but with PW you can really focus on the person and his skills, not that if he/she has 3 years of experience with certain legacy tech). Last time I recruited the fellow I ended up hiring did build full pw website on the very same day we had an interview

Another Friday blog post with core updates just posted. This time we've got several image editing updates, particularly with regard to image editing for images placed in rich text fields. Also included are HiDPI/Retina support, an image variation tool, and more… Read all about it here, plus a video and screenshots: https://processwire.com/blog/posts/new-image-editing-features-2.5.19/

Seems like I've got the first job thanks to the developer directory

Just had one more thought for you - how hard do you think it would be to also offer this as an inputfield for Ryan's new Options fieldtype, in addition to the Pages fieldtype that is currently uses. Thought it might be nice because with tags it is often unlikely that you actually need these to be accessible via a URL, hence no real need for having them as pages now that we have this new fieldtype. Just thinking out loud if you are looking for something to do

Actually they can place the images anywhere they want to in the text. They aren't limited to just placing it at the top. Of course, when you find where you want to place the image in the text, then at that point you have to specify whether its an image that should be left aligned, right aligned, or centered. On the front-end, you can choose how you want to handle that. While most of the time the text floats around it, sometimes I'll take an alignment and make it pull into a blank left/right column. Images for predefined placement in a layout shouldn't go in the text at all. You'd want to have a dedicated field or tag for those images. If there are more than a couple predefined placements, I might use tags so that an image with the tag "hero" automatically goes to your dedicated hero spot, etc. I usually treat galleries as predefined placements (like appearing above or below the main content). Rarely does the need arise where galleries need to be part of the actual copy, but others may have a different need/experience, so I think that's a good example. While I like having a consistent placement for a major feature like that, it's really more about having markup that is generated dynamically when the page is viewed. But if you wanted the ability to place galleries of images in-between blocks of copy, then I agree that's a good use case for a block editor. Whether it's worth the compromise would depend on the need I suppose. Perhaps that's a great case for a hybrid editor that is primarily RTE but provides certain blocks you can work with. CKEditor does actually provide something called Widgets that allow insertion of more complex predefined markup elements, but I don't think it's quite there enough to where I'd want to use it for a gallery. That's because it's something I'd want to generate on the front-end rather than directly in the RTE-generated markup. I don't like RTE's generating anything other than basic markup because it's just not as portable... once you start using CKE widgets, you can't really switch to another RTE without losing those widgets. Probably what would be ideal is CKEditor with a block-editor style select input at the bottom that lets you add certain types of elements like galleries, paginations, or other things (but not simple markup elements like headlines), and then lets you continue the text content underneath in another CKE instance. That would let the RTE do what it's good at, and let blocks handle the things that would benefit from having their markup generated at runtime (like a gallery).

I would love to have full featured options for both RTE and a block editor. As much as I would like to do away with RTE's — they are still relevant and essential at times. In my case, we won't be abandoning the RTE anytime soon, but there are a lot of times where a block editor would make things simpler. @ryan, These new additions are awesome, and make images inside RTE (CKEditor) a lot better. Thank you! @Pete Your implementation sounds great! Having it look/feel like part of the admin seems ideal. Can Ryan loan you one of his clones to help get it release ready?

I don't know if this does help you, but templates are kinda like your models in ProcessWire. So you'd probably need threads, messages, and users (the last one is alread there). States and participations could be managed independently or as fields of thread/message. You can read more on this here: https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/. I would suggest taking the hierarchy of pages in consideration as well (messages as children of thread). Your template.php files are your views, which render the current data. If you're then still in need of some kind of controller structure, url segments and maybe some autoload modules are your friend.

Awesome - so much better with Enter working to add tags - thank you! As for the no results/placeholder text - I might just go with some jquery. Thanks again for a fantastic job on this - it really is the best solution for tags fields!

@Ryan, love the new features. Regarding inserting images in a RTE, is this something you guys still do? How do you handle it so clients don't mess up? I don't see how that is convenient? I mean if we allow clients to insert images in the Text, shortly after there's a complete mess of images to clean up. So I'm not sure what to think of the new image features being focused on this? What we love to see is a image manipulation tool to cut an original image, to then create thumbnails from. Croppable image does a good job, but still missing a cut the original image feature.

Hi, I have implemented the feature and it's available in the dev branch: https://github.com/wanze/Pages2Pdf/tree/dev If anyone has time to test it out, please do so and report any issues back here. I will merge it into the master branch after some more testing How does it work? First, you need to enable multilanguage support in the module configuration. If enabled, the module creates a PDF in the language of the current user. The same is true when downloading a PDF. If the PDFs are pre-generated when saving pages in the admin, a PDF for each language is created. The language name is appended to the PDF filename in order to distinguish between files of different languages. In addition, if the module "LanguageSupportPageNames" is installed, the local page name is used for the filename. At the same time I added the newest version of mPDF to the module WirePDF. As always, please check that your PDFs are still rendered correctly after updating! Good night to everyone from Switzerland

Hi guys am a complete Noob to Processwire and i have spent the past two weeks reading codes and understanding the structure and concept around it. So i am the type of dev who obesseses about architecture structure before getting to work, and i think my mind is broken due to my limited knowledge on PW. So i will expain my goal. I intend to rebuild http://styljunki.com from Wordpress to Processwire because of two reasons. 1. PW has no templating system meaning no hacks like shortcode or mundane template conventions. 2. Modules dependency meaning i can leverage on existing modules (easily) e.g wire('moduleName')->method this really appeals to me alot However there are certain tasks i want to achieve. Concept of Blog vs Pages There are some contents which are Post and some which are pages, is there some such dinstinction in PW, I know PW manipulates pages and adds fields but what of Blogs which just take entry and nothing special, I tried my hands on the Blog Module on PW 2.5.8 but it threw some errors. Menu Management My Client intends to manage menus and from what i have seen ; PW lists all the pages, we were looking for something where we can simply create menus for the front page and we simply pick those. But if there's a module around I am willing to use/ contribute code if it is neccessary. Custom Post In Wordpress you can create a custom post and query that, is there any similar thing to that ? Unit testing PHPUnit Testing in WordPress was a big joke, is there any link to unit test processwire while we work Thanks this are my questions NOTE: Also i'd really like to say congrats because, I have spent the 4 years of my life developing with CMS from Joomla,WordPress,ImpressPages and really this is the first time i am really excited about a CMS. Working with WordPress as a CMS is a pain in the ass, esp for someone used to MVC frameworks like Zend and Yii. I have searched and searched till i came across your site on CMSCritic and Joss Salinger 's post the rocker blogger (rock on) on how easily he could use it despite no coding experience. I intend to contribute in my way. Keep up the good work guys. Love from Nigeria

InputfieldChosenSelect This topic (https://processwire.com/talk/topic/71-categorizingtagging-content/) showed the need for a Inputfield that would provide a real tagging UI to be useable with FieldtypePage. It uses the chosen library, which can be found here http://harvesthq.github.io/chosen/. It's meant for MultiPageFields and works kinda like asmSelect, but with a different skin. Features: Inline adding of new tags, which will then generate the corresponding pages. Sortable tags. Usage Install the Module Edit your pagefield and choose InputfieldChosenSelect as inputfield. Use Enter or Tab to create new Pages with the currently typed name. Enter will fill in the tab currently selected in the dropdown. http://modules.processwire.com/modules/inputfield-chosen-select/ https://github.com/LostKobrakai/InputfieldChosenSelect

Some time ago I developed a module (FieldtypeImageExtra) which extends Fieldtype Image with the ability to add custom fields to an image. This worked well but it had a somehow restricted applicability and did not meet all of our needs. There of course are other useful image modules like CroppableImage or ImageFocusArea, but up to now there was no possibility to combine image cropping with custom fields support. So you had to decide whether to add image cropping or the possibility to add custom fields because each of those modules sets up their own field type (and input type) which cannot be combined. The new module ImageExtra allows you to have both functionalities. You can get the module from GitHub. For more informations have a look at this blog post. If you notice any problems or unexpected behaviour please let me know.

Fredi is friendly frontend editor for ProcessWire. Code and documentation: https://github.com/apeisa/Fredi Module page: http://modules.processwire.com/modules/fredi/

This basic tutorial is primarily aimed at those new to PW. It could also serve as a reference to others more seasoned PW users. The question about how to categorise content comes up in the forums now and again. Hopefully with this post we’ll have a reference to guide us right here in the tutorials board. Many times we need to organise our site content into various categories in order to make better sense of the data or to logically and easily access it. So, how do you organise your data when you need to use categories? Here are a few tips gathered from the PW forums on how to go about this. Using these tips will, hopefully, help you avoid repeating yourself in your code and site content and keep things simple. See the links at the end of this post to some useful discussion around the topic of categorisation. Before making decisions about how to organise your site, you need to consider at least three questions: What items on my site are the main items of interest? These could be people or things (cars, plants, etc.). In most cases, these are the most important content on which all the other stuff point to. Where do items need to be grouped into categories? This is about where items need to “live”. It is about the attributes of the items of interest (e.g. responsibilities, job types, colour, etc.). Attributes can have sub-attributes (e.g. a category job type = driver could be further sub-classified as job type role = train driver). Can they live in more than one place? - This is about having multiple attributes. There could be other issues such as the type of content your main items of interest are but that’s for another post. We’ll keep these examples simple. The main principles explained below still apply. There are at least three possible ways in which you can organise your content depending on your answers to the above three questions. These are: Single category Simple multiple categories Complex multiple categories These are illustrated below. Note that this is what I call them; these are not PW terms. 1. Single Category Suppose you need to do a site for a company that’s made up of several Departments each with employees performing unique functions. These could include “Finance”; “Media Communications”; “Administration”; “Technicians”; “Human Resources”; “Logistics”. We ask ourselves the following questions based on our 3 questions above: 1. Q: What items on my site are the main items of interest? A: Employees. 2. Q: What attributes of our items of interests are we interested in? A: Departments. (Single main category) 3. Do the Departments have sub-categories? A: Yes. (Multiple sub-categories) 4.Can Employees belong to multiple sub-categories? A: No. (Single sub-category) We conclude that what we need is a Single Category model. Why? This is because, in Single Categories model, items of interest can only belong to 1 and only 1 main/parent category and within that only 1 sub-category Employees in this company can only belong to one and only one department. Finance guys do their finance and Logistics guys do their stuff. Letting Techies do press conferences is probably not going to work; that we leave to the Media guys . Assuming the company has the following employees - James, John, Mary, Ahmed, Peter, Jason, Barbara etc., arranging our site content to fit this model could look like the following: Items of interest = Employees Categories = Departments Adopting out strategy to keep it simple and logical, let us write down, hierarchically, our employee names against their departments to mimic the PW tree like this: James Finance John Finance Mary Technician Ahmed Logistics Barbara Media Etc. We notice, of course, that departments start repeating. It doesn't look like we are doing this very logically. If we think about this carefully, we will conclude that, naturally, the thing (attribute in this case) that keeps repeating should be the main criteria for our categorisation. This may seem obvious, but it is worth pointing out. Also, remember, that as per the responses to our questions, the categories (Finance, Logistics, etc.) do not have sub-categories. In this aspect, we are OK. Using this principle about repeating attributes, we find that Departments, rather than Employees, need to be the main categories. Hence, we categorise our PW site content by doing the following. Create a template for each Department. Hence, we have a template called Finance, Logistics, etc. Add the fields needed to those templates. This could be a text field for holding Employee phone numbers, email field for email, title field for their names, etc. Create top level pages for each Department and assign to them their respective templates. Give them appropriate titles, e.g., Finance, Media, etc. Create a page for each employee as a child page of the Department which they belong to. Give them appropriate titles, e.g. James, John, etc. We end up with a tree that looks like this: 1. Finance (ex. main category) a. James (ex. item of interest) b. John c. Shah d. Anne 2. Logistics (ex. main category) a. Ahmed b. Matthew c. Robert d. Cynthia 3. Media a. Barbara b. Jason c. Danita 4. Human Resources a. Michael b. Pedro c. Sally 5. Technician a. Mary b. Oswald c. Dmitri d. Osiris Since an employee can only belong to one Department, our work here is done. We can then use PW variables, e.g. $page->find, $pages->find with the appropriate selectors to find employees within a Department. This is a very basic example, of course, but you get the idea. You have the choice of creating one template file for each category template as well. I prefer the method of using one main template file (see this thread). You could do that and have all Departments use different templates but a single template file. In the template file you can include code to pull in, for example, the file “technician.inc” to display the relevant content when pages using the template “Technician” are viewed. Example code to access and show content in Single Categories model $hr = $pages->find("template=human-resources, limit 50"); foreach ($hr as $h) { echo "{$h->title}"; } But sites do not always lend themselves to this model. Many times, items of interest will need to belong to multiple categories. 2. Simple Multiple Categories Let’s say you were building a site for cars - red cars, blue cars, 2-seaters, 5-seaters, etc. Again, we ask ourselves our questions based on our initial three questions: 1. Q: What items on my site are the main items of interest? A: Cars. 2. Q: What attributes of our items of interests are we interested in? A: Colour, Number of seats, Models, Year of manufacture, Types. (Multiple categories) 3. Do these multiple attributes have sub-attributes? A: Yes. e.g., the attribute Colour has several sub-categories - red, white, green, etc. (Multiple sub-categories) 4. Can Cars have multiple sub-attributes? A: No. e.g., a yellow car cannot be a green car. (Single sub-categories) We therefore conclude that what we need is a Simple Multiple Category model. Why? This is because, in Simple Multiple Categories, items of interest can belong to multiple parent categories. However, within those parent categories, they can only belong to one sub-category. Assuming we have the following cars, manufactured between 2005 and 2008, as items of interest: Mercedes, Volvo, Ford, Subaru, Toyota, Nissan, Peugeot, Renault, Mazda, arranging our site content to fit this model could look like the following: Items of interest = Cars Categories = Model, Year, Colour, Number of seats, Type Sub Categories = Model [Prius, etc.]; Year [2005, 2006, 2007, 2008]; Colour [Red, Silver, Black, White, Green]; Number of seats [2, 5, 7]; Types [sports, SUV, MPV]. Adopting out strategy to keep it simple and logical, if we wrote down our cars names against their attributes like this: Mercedes Model-Name: Year: 2005 Colour: Silver Seats: 2-seater Type: Sports Volvo Model-Name: Year: 2007 Colour: Green Seats: 5-seater Type: SUV Ford Model-Name: Year: 2007 Colour: Red Seats: 7-seater Type: MPV Etc We notice, again, that car attributes start repeating. In order not to repeat ourselves, we want to avoid the situation where our child pages “names” keep repeating. For instance, in the above example tree, we want to avoid repeating year, colour, etc. within the tree. Of course in the frontend our output needs to look like the above where we can list our cars and their respective attributes. We just don’t need a tree that looks like this in the backend. Since we have multiple categories and sub-categories, we need to rethink our strategy for categorising our content as illustrated below. The strategy we used in the first category model will not work well here. Hence, these repeating attributes (year, colour, etc.) need to be the main criteria for our categorisation. We need to end up with a tree that looks like this: 1. Cars a. Mercedes (ex. item of interest) b. Volvo c. Ford d. Subaru e. Toyota f. Range Rover g. Peugeot h. Renault i. Mazda 2. Model (ex. main category) a. Fiesta (ex. sub-category) b. Miata c. Impreza d. Matrix e. Prius f. E-Class g. XC-90 h. Scenic i. L322 j. 505 3. Year a. 2005 b. 2006 c. 2007 (ex. sub-category) d. 2008 4. Colour a. Red b. Silver c. Black d. White e. Green 5. Number of Seats a. 2 b. 5 c. 7 6. Type a. MPV b. Sports c. SUV d. Other At the top of the tree, we have our main items of interest, Cars. They do not have to come first on top of the tree like that but it just makes sense to have them like this. Next, we have the Cars’ categories (attributes). The main categories are parent pages. Each main category has children which act as its sub-categories (cars’ sub-attributes). For instance, the main category colour has sub-categories “red”, “green”, etc. Grouping them under their main category like this makes better sense than having them dangling all over the tree as parent pages themselves. Now that we know what we want to achieve, the next question is how do we go about relating our categories and sub-categories to our main items of interest, i.e., cars? Fields come to mind. OK, yes, but what about the sub-categories (2006, red, 5-seater, etc.)? Surely, we can’t keep typing those in text fields! Of course not; this is PW. We like to simplify tasks as much as we can. What we need is a special type of field. Page Reference Fields or Page Fieldtypes add the ability to reference other pages, either single or multiple pages, within a page. For instance, we could have a Page Reference Field in the template that our Car pages use. Let’s call this “car-template”. When viewing Car pages, we would have the ability to select other pages on our site that we wish to reference, for instance, because they are related to the page we are viewing. In other cases, we could also wish to reference other pages that contain attributes/values of the page we are viewing. This is the situation with our Cars example above. Hence, the sub-categories/sub-attributes for our Cars will be pulled into our car pages using Page Reference Fields. There are two types of Page Reference Fields; single page and multiple pages. What each do is obvious from their names. Single Page Reference Fields will only reference one page at a time. Multiple Page Reference Fields will reference multiple pages. OK, let’s go back to the issue at hand. We need to categorise Cars by various attributes. Do we need to reference the main categories (Year, Type, etc.) in our Car pages? In fact, we don’t. What we need to reference are the sub-categories, i.e. 2005, red, SUV, etc. These will provide the actual attributes regarding the parent attribute of the Cars. We have said we do not wish to type these sub-categories/attributes all the time hence we use Page Reference Fields. Which type of Page Reference Field should we use? Remember that our Cars can have only one sub-category/sub-attribute. That’s our cue right there. In order to select one and only one sub-attribute per Car, we need to use the single Page Reference Field. Hence, we categorise our Cars PW site by doing the following (you may follow a different order of tasks if you wish). Create a template to be used by the Car pages. Give it a name such as car-template Create a page for each of your cars and make them use the car-template Create one template to be used by all the main attribute/categories and their children (the sub-categories). We do not need a template for each of the categories/sub-categories. I name my template “car-attributes” Of course you can name yours differently if you wish. Add the fields needed to this template. You don’t need anything other than a title field for each actually. Create top level pages for each main category and assign to them the template car-attributes. As before, give your pages meaningful titles. Do the same respectively for their child pages. E.g., you should have the following child pages under the parent “Year” - 2005, 2006, 2007 and 2008. Create the Page Reference Fields for each of your main categories/parent attributes. Using our example, you should end up with 5 Page Reference Fields (model, year, colour, seats and type). Each of these should be single Page Reference Fields. It’s a good idea, under the BASICS settings while editing the fields, to include some Description text to, include additional info about the field, e.g. instructions. In addition, you don’t want any page that doesn't belong to a particular attribute to be selectable using any of the Page Reference Fields. For instance, when referencing the year a car was manufactured, we want to be able to only select children of the page Year since that is where the year sub-categories are. We do not want to be able to select children of Colour (red, green, etc.) as the year a car was manufactured! How do we go about this? PW makes this very easy. Once you have created your Page Reference Fields, while still in the editing field mode, look under the settings INPUT. The fourth option down that page is “Selectable Pages”. Its first child option is “Parent of selectable page(s)”. Where it says “Select the parent of the pages that are selectable” click on change to change the parent. By now you know where I am going with this. For the Page Reference Field named Year, choose the page “Year” as the parent whose children will be selectable when using that Page Reference Field to select pages. Similarly, do this for the remaining 4 Page Reference Fields. Note that under this field settings INPUT you can change how you want your pages to be selectable. Be careful that you only select the types that match single Page Reference Fields, i.e. the ones WITHOUT *. For single Page Reference Fields, you have the choices:Select - a drop down select Radio buttons PageListSelect Now edit the car-template to add all 5 of your Car Page Reference Fields. We are now ready to roll. Go ahead and edit your Car pages. In each of them you will see your 5 Page Reference Fields. If you followed the instructions correctly, each of them should only have the relevant child pages/sub-attributes as selectable. Do your edits - select year when car was manufactured, its colour, type, number of seats, etc. and hit Save. By the way, note that Page Reference Fields give you access to all the fields and properties of the page being referenced! You have access to the referenced page’s title, name, path, children, template name, page reference fields, etc. This is really useful when creating complex sites. I call it going down the rabbit hole! These properties of the referenced page are available to you on request. It does mean that you will have to specifically echo out the property you want from that page. Page Reference Fields are echoed out like any other field. Example code to access and show content in Simple Multiple Categories model $cars = $pages->find("template=car-template, limit=10, colour=red, year=2006, seats=5"); foreach ($cars as $car) { echo $car->title; echo $car->year; echo $car->colour; } I have made the above verbose so you can easily follow what I'm trying to achieve. The above code will find 10 red 5-seater cars manufactured in 2006. Remember, colour, year and seats are the names of your custom Page Reference Fields that you created earlier. Some sites will have content that belong to multiple categories and multiple sub-categories. We address this below. 3. Complex Multiple Categories Suppose you are developing a site for a school. The school has teachers (duh!) some of whom teach more than one subject. Besides their classroom duties, some teachers are active in various clubs. On the administration side, some teachers are involved in various committees. You know the drill by now. Let’s deal with our basic questions. 1. Q: What items on my site are the main items of interest? A: Teachers. 2. Q: What attributes of our items of interest are we interested in? A: Subjects, Administration, Clubs (Multiple categories) 3. Do these multiple attributes have sub-attributes? A: Yes. e.g., the attribute Subjects has several sub-categories - History, Maths, Chemistry, Physics, Geography, English, etc. (Multiple sub-categories) 4. Can Teachers have multiple sub-attributes? A: Yes. e.g., a Teacher who teaches both maths and chemistry (Multiple sub-categories) Apart from the response to the final question, the other responses are identical to our previous model, i.e. the Simple Multiple Categories. We already know how to deal with multiple categories so we’ll skip some of the steps we followed in the previous example. Since our items of interest (Teachers) can belong to more than one sub-category, we conclude that what we need is a Complex Multiple Category model. In Complex Multiple Categories, items of interest can belong to multiple parent categories and multiple sub-categories both within and without main/parent categories. By now we should know what will be the main criteria for our categorisation. We need to end up with a tree that looks like this: 1. Teachers a. Mr Smith (ex. item of interest) b. Mrs Wesley c. Ms Rodriguez d. Mr Peres e. Mr Jane f. Mrs Potter g. Ms Graham h. Mrs Basket i. Dr Cooper 2. Subjects (ex. main category) a. History (ex. sub-category) b. Maths c. English d. Physics e. Chemistry f. Geography g. Religion h. Biology i. French j. Music 3. Clubs a. Basketball b. Debate c. Football d. Scouts e. Sailing f. Writing 4. Administration a. Discipline b. Counselling c. Exams board d. Public relations e. Education We are ready to build our site. Which type of Page Reference Field should we use? Remember that our Teachers can teach more than one subject and can be involved in various sub-category activities. That’s our cue right there. In order to select multiple attributes/categories, we of course go for the multiple Page Reference Field. Similar to the previous example, create necessary templates and fields for the site. For our multiple Page Reference Fields, remember to select the correct input field types. These should match multiple Page Reference Fields and are marked with *. For multiple Page Reference Fields, the available choices are: Select Multiple* AsmSelect* Checkboxes* PageListSelectMultiple* PageAutoComplete* Remember to add the multiple Page Reference Fields to the Teachers template. Go ahead and test different selectors, e.g. find Teachers that teach Maths and Chemistry and are involved in the Writing club. Whether you get results or not depends on whether there is actually that combination. An important point to remember is that your multiple Page Reference Fields will return an array of pages. You will need to traverse them using foreach (or similar). Example code Complex Multiple Categories model Find the subjects taught by the Teacher whose page we are currently viewing. You can use if statements to only show results if a result is found. In this case, of course we expect a result to be found; if a Teacher doesn't teach any subject, he/she has no business teaching! subjects is the name of one of your custom Multiple Page Reference Fields. echo "<ul>"; foreach ($page->subjects as $x) { echo "<li>{$x->title}</li>"; } echo "</ul>"; There will be situations where you will need to use both Single and Multiple Page Reference Fields (independently, of course). For instance, in our Teachers example, we might be interested in the Gender of the Teacher. That would require a Single Page Reference Field. Summary What we have learnt: Categorising our site content need not be a nightmare if we carefully think it through. Of course not all sites will fit neatly into the 3 models discussed. By providing answers to a few simple key questions, we will be able to quickly arrive at a decision on how to categorise our content. There are at least 3 models we can adopt to categorise our content - single category; simple multiple category; and complex multiple category. In the latter two models, we make full use of PW’s powerful Page Reference Fields to mimic a relational database enabling us to roll out complex sites fast and easy. Useful links: http://processwire.com/talk/topic/3553-handling-categories-on-a-product-catalogue/ http://processwire.com/videos/create-new-page-references/ http://processwire.com/videos/page-fieldtype/ http://processwire.com/talk/topic/1041-raydale-multimedia-a-case-study/ http://processwire.com/talk/topic/683-page-content-within-another-page/ http://processwire.com/talk/topic/2780-displaying-products-category-wise/ http://processwire.com/talk/topic/1916-another-categories-question/ http://processwire.com/talk/topic/2802-how-would-you-build-a-daily-newspaper/ http://processwire.com/talk/topic/2519-nested-categories/ http://processwire.com/talk/topic/71-categorizingtagging-content/ http://processwire.com/talk/topic/2309-best-way-to-organize-categories-in-this-case/ http://processwire.com/talk/topic/2200-related-pages/ http://processwire.com/talk/topic/64-how-do-you-call-data-from-a-page-or-pages-into-another-page/

Hi everybody, First of all: Thanks to everybody for keeping the community alive. Every time I search for something in the forum I find the solution. Great work! I wanted to share a small module with you / my first one. I use it in order to switch the user language on page load. Processwire GeoInfo GeoInfo is a small module that Implements Geoplugin PHP web service. Please donate to "geoplugin.com" in order to keep the service alive. The Module ads two methods to retrieve data from the web service. $page->GeoInfoIP('IP ADDRESS'); you can enter the ip address manually. If left blank the server remote address will be used. The retrieved data is then stored to the active session, in order to limit the requests. The web service gives back following data. 'geoplugin_request' 'geoplugin_status' 'geoplugin_credit' 'geoplugin_city' 'geoplugin_region' 'geoplugin_areaCode' 'geoplugin_dmaCode' 'geoplugin_countryCode' 'geoplugin_countryName' 'geoplugin_continentCode' 'geoplugin_latitude' 'geoplugin_longitude' 'geoplugin_regionCode' 'geoplugin_regionName' 'geoplugin_currencyCode' 'geoplugin_currencySymbol' 'geoplugin_currencySymbol_UTF8' 'geoplugin_currencyConverter' for e.g. $page->GeoInfoIP('IP ADDRESS')->geoplugin_countryCode; will give back the country iso code. $page->GeoInfoLatLong('LAT', 'LONG'); Enter Latitude and Longitude in order to get following information: 'geoplugin_place' 'geoplugin_countryCode' 'geoplugin_region' 'geoplugin_regionAbbreviated' 'geoplugin_latitude' 'geoplugin_longitude' 'geoplugin_distanceMiles' 'geoplugin_distanceKilometers' for e.g. $page->GeoInfoLatLong('40.712784', '-74.005941'); will give back the city name "New York City". Todo store places in json file / check if place exists implement nearby "service" https://bitbucket.org/pmichaelis/processwire-geoinfo

Your right with the "stick a image into a placeholder" types, but actually I meant it more in the kind of predefined grid sizes or something like that. Eg. 1/2 width, 1/4 width and such things. My bad of being not precise enough. I've done this for the client behind this request,too ,but here's an example: Think of an blog post about an event. The user uploads all the photos of the event, but they are a lot of them, so the client wants to have two galleries. E. g. one for the lunch and one for the actual event itself taking place. Each should also be accompanied by the text which reviews them. Maybe it's just an edgecase, but until there's another way I have to get used to hanna codes and/or subpages for galleries if need be. At least it's really interesting to see how others feel about this topic.

This was also part of the update, but not yet finished. It'll be finished in this week's update. If you want a preview of what it does, you can click on the filename of any image (currently hidden that way, since it's not yet fully functional). It'll let you size and crop it just like in the RTE version, and then give you the option to replace the original or save as a new copy. But if you try it, no need to send issue reports just yet because it's only a work in progress at this point (the code just isn't there yet). Btw, it's not a replacement for CroppableImage, so if you have that need, you'll still want to use CroppableImage. The tool being added is purely about manipulating the base images in the image field, not about creating predefined/named variations to pull on the front-end. Though manipulating the base image may be exactly what you need to keep your api-generated variations from copping off someone's head, etc

I have. But mostly stuff, that's not as complex as I'm not as comfortable with such big featuresets. I've also "ProcessStitch" on my someday todo-list, the module to drag and drop fields to templates. So I don't think I'll do such a thing in a really near future.

I agree. Still think this is most promising open source "block rte": http://madebymany.github.io/sir-trevor-js/ LostKobrakai has been building modules like a crazy: maybe this one next?

Thanks for the response! I was expecting to be able to literally create a draft version of the page to be able to work on the changes before making it live. It would be great to be able to just click a "Save Draft " if the user has "managedrafts" permission. at the moment the module assumes the draft creators and publishers are 2 separate and exclusive roles. Approvers/publishers can not create drafts themselves and draft creators cannot publish. Perhaps it needs another role/-s? nice work though!

Yeah the breadcrumbs are currently all over the place on this site.

thanks, didn't search it there because in the breadcrumbs it says "Home > Dev Dir" so i was guessing its a top-level item

What exactly don't you get?

Hey guys! I just got a new position in a startup where I'll be in charge of running most things development-related. I did a small presentation to the team on ProcessWire, suffice to say they were very impressed by the ability to run anything from small pages to complex sites/semi-applications, dynamic or static using ProCache. They are currently using mainly WP, but I want to move away from this in the future to cut on dev time/costs and maintenance. I have a few questions, and I hope this will lead to a discussion on best-practices of running a PW shop. I'm used to be a "one man army", so my workflow will need to change.. The questions: Development: ​What have you found to be the best workflows to deploy and version-control PW sites? I'll probably be implementing Docker to help setup things, but what about staging/production using GIT and deployment? Migrations: Since PW doesn't have something like ActiveRecord/Eloquent (yet?), how do you manage migrations? I currently have a workflow that's mainly manual, but that won't scale so well considering we have ~ 40 clients, and plan to have ~ 100 within 2 years. Hiring: Have you found it easy to introduce front- and back-end devs to PW development? I know we'll probably not be finding long-term devs like we can on WP/Joomla/Drupal/Laravel/insert-framework-or-cms-of-choice, so that's something I'm wondering about. Add your own questions! I'm really looking forward for your ideas and feedback. If possible, provide details on your team size and what kind of sites you do most often.

Mostly migration during staging on production websites when the content still continues being edited from the client so you can't just copy the dev folder and overwrite the database (I know there are ways to diff a database, but I'm not that versed into it). Especially, if there are changes to the model (template, field changes) / structure, things can get messy, although it is indeed manageable manually without so much effort… I might be overthinking this one! Migrating from other systems is pretty straightforward, most of the time a CSV import might be all that's required. That's nice to hear! You pretty much confirm my thoughts. I do agree there are some problems with the documentation on deeper aspects, but it seems there are efforts right now in improving that. I would gladly take part in this effort and will be taking notes as I take the team through the migration.

I've updated the module to give users the ability add pages with Enter as well. Let me know if there are any problems. Edit: I've also added some more fitting styles for AdminThemeReno.

Hi Christophe, Please refer `site/templates/_functions.inc` file. Inside of that file there is a method named `getContactUsForm()`. At the moment `from email address` would be your admin email address. Please feel free to modify it in `getContactUsForm()` method. Thanks

@OllieMackJames my advice would be to use the dev branch for new projects, and the master branch for existing projects. Though I mostly use the dev branch for both. If you use the dev branch on a production site, you just want to make sure it's one that you keep track of and can report any issues if/when you see them. The current dev branch actually has a lot of bug fixes from 2.5.3, so it may technically be more stable in many ways. However, it also contains a lot of new features and code that doesn't yet have as much mileage on it.

Hi again, In FormTemplateProcessor.module, I've precised an email address (not this one of course...): // Optional E-Mail address that form will get submitted to $this->set('email', 'name@domain.tld'); I still receive the messages as pages, but not as emails. How can I receive them as pages and as emails, or just as emails? NB: I've seen commented code(s) related to all this at the top of the file, but I don't want to mess things up.

First, Thank You for your comments. No problem with disagreeing, however my point is that if a developer is using ProcessWire as a solution, they should have confidence in and knowledge of the product. Maybe what I don't fully understand is, if you are a professional Solution Provider, I would sincerely hope that you aren't ever providing crappy solutions. This would be the case regardless of what software you are developing with. That is a situation where the skill of the developer determines the outcome. It's never crappy software that's to blame, it's always a lack of focus that leads to a crappy implementation. In my humble opinion (and remember this is my opinion), ProcessWire as a tool for developing websites has more to offer (on a technical basis) a client than Wordpress. You have more control over the front-end and back-end development processes. You have an enormous variety of field types that can be customized. With ProcessWire, the limitations are few and the benefits are many. Yes, Wordpress is more popular and will most likely always be that way. I appreciate Wordpress' status and pedigree. I believe they have much to offer just not at the technical level that ProcessWire does. Serious web development (once again in my humble opinion) should be about creating workable solutions for your clients. We discuss the requirement with our clients and end up giving them a solidly built self-maintainable website. They only get the good website (in their opinion) when we listen, appreciate and respond to their needs. You are right, they are the final say in whether it works for them. Thanks again for giving me your perspective. I agree with many things you say. This forum has people from all over the world, with a variety of skill-sets and opinions. For me, that is a good and healthy situation. I honestly believe we are all here working with the ProcessWire project because this tool is unique and fun to work with.

@Mont Hello, In Firebug, the rule is: body { background: url("images/bg.gif") repeat scroll 0 0 #e4ebee; } In the css file, it's different. Wouldn't it be "better" to precise repeat-x? Otherwise, it can also repeat itself on several lines under the footer.

The function that gets hooked by the module (Page::editable) does exactly what it sounds like. Return if a page is editable by the current user. Page::addable is the function to control the ability to add children. Essentially you'll need another function addable(), which does the same check for users as editable, and in init() a second hook to Page::addable which points to your new function.

I've a feature request. As I can assign users of ProcessWire the right to view/list hanna codes it would be nice to be able to incorporate a description field, where I can add small explanations for each code. This way the list/view permission would be more useful on it's own. This could maybe later be incorporated in something like a small dropdown underneath hanna code textfields.

Thank you very much Ryan; you had me at Field editor now lets you target templates—Fab!

It's about time this was pulled together as a configurable module. So here it is on github and in the module DB. You can configure a set of roles and a target redirect page under the module config. I've done very limited testing here - hence it being marked as alpha in the module DB - so please let me know if it works for you. A word of thanks to both Wanze and kongondo are in order as they pulled most of the material together that I used for this!

Every time i read about some new amazing feature in a CMS, it's always stuff that is a totally natural part of Processwire and has been around and used by us PW folks for ages. Read this for example. http://alistapart.com/blog/post/longform-content-with-craft-matrix And always, always!, there's some Wordpress guy in the comments saying: "You can do that with wordpress!". Yes, of course you can, but only with a bunch of ugly hacks and tweaks and 37 plugins that may play nice together if you're lucky. I have split emotions about this. A bit of sadness - Processwire should be given much more attention and recognition. At the same time, I feel lucky for having discovered it. What about you guys?

I personally don't see a reason to extend pwire's core to support Craft's matrix block stuff. It's taking the repeater paradigm a little too far / specific for inclusion out of the box. For me, processwire's repeater fieldtype is pretty much perfect as-is, and actually is the sole reason I started using processwire. The way I see it, the jump from child pages to in-template repeaters for organizing certain kinda of data is substantial and incredibly useful from a client UX/UI perspective, but the jump from the existing repeater type to something like matrix blocks from Craft is not as substantial. Just use multiple child templates I'm curious Ryan, what for you is the ideal situation for repeaters vs child pages? For me, I use them in situations where it's helpful to see repeating data all at once, as opposed to seeing a list of child pages and having to drill down into the individual pages to see specific data. For instance, if I have a relatively complicated gallery in a page (which requires more fields than the images field offers) repeaters are perfect because they allow clients to see all of their images in a single page, drag them around, etc. If I were to build all the gallery fields into a separate template and have them as child pages, it would be difficult to visualize the entire gallery all at once. So a repeater works wonders. Ryan I hope you aren't considering phasing out repeaters because you don't use them yourself. For me, it's a killer feature. They aren't candy, they serve a real distinguished purpose from normal child pages. When the next version of pwire comes out with gridded image galleries, that will be icing on the cake for my CMS wishlist. The only weakness I see with the current pwire release is the inefficiency of viewing image galleries. Pwire is near-perfect

as I said I'm a non coder... I have a glance of what is a string, but where is there a php string??? there is some html... So, to my opinion, it's almost not possible for a non coder to use PW and the target audience never would come from wordpress Compared to other designers, I do a lot of coding and never give up before I have the solution - and even for me, it's exhausting. How would it be for "normal" designers??? Without all the help here which is really unusual, I wouldn't be able to do a single thing in PW!

Are you gone crazy? And even with colors!

Hi Lance, Steve is correct. One of the first things I built in order to learn PW, was a front-end profile editor. What I have is fairly specific to a University environment, but I think I can strip it back to a more simplistic form and get a walk-through posted. I'll report back soon.