Leaderboard

I want to like this post multiple times but the forum software doesn't allow me to do that. So: Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Honestly: It's comparing apples to oranges. PW is strong. It is the most intuitive, the best designed (in terms of API and UI) CMS out there with the smallest footprint possible. I recently used again the multi language support. I mean, look at the API. Look at the solution for a problem each CMS has. It is just beautiful. You have several ways to solve that problem (as always with PW). But it is there, written in the core, well documented on one(!) API page, because it just works intuitively, it is just simple. Every addition to the core is an addition which solves general problems and the way Ryan solves them is just genius. There is no addition you have to scratch your head when reading the new API. You always think: "wow, clever". And this is the way to go with the core. Make it simple, make it smart, make it beautiful! Regarding themes, profiles and such: It is already possible. It is out there. Provide a custom profile for a real estate agent: Give him a set of modules, fields and templates to handle his offers. This is no problem! This is even easier and more flexible than it ever will be in WordPress, because it goes way beyond a custom theme and can be installed with one click. But: Nobody will care at the moment, because ProcessWire has no own category in theme/template websites, because ProcessWire has not the attention of other plug&play systems. And this is totally okay! Think of TYPO3, a widely spread system, mostly used in enterprise environments and even on small sites (dunno why), but the point is: Everyone (at least in Europe) knows it, it is one of the most used systems in the business sector (not on private children soccer club websites). But: this is the goal! Be the system developers use. Don't be the system every idiot wants to use. Concentrate on performance, flexibility and most of all: beauty of the API! The rest will follow.

In the famous "30 minutes" thread MadeMyDay somehow made a point by putting ProcessWire into context with TYPO3. Recently, I got an inquery for a multilingual website for a speaker agency. A customer looking for an Open Source solution. These speakers had meta data attached (topics, languages, speaking areas, gender) and this database would be the most essential part of the website. Also, a password protected area was needed where speakers could supply materials such as slides to an exclusive user group. Sounded like the perfect job for ProcessWire, unfortunately, after a while of internal consulting and decision-making, the customer chose TYPO3 instead. PW was totally new for them, they admitted to be fascinated by it, but went with the system they knew in the end. That, and Marc's above mentioned comment made me think. ProcessWire does a good job catering developers but still has room for improvement, in my opinion. Throughout the 30 Minutes / WP Tavern article I often read, "once the developers are on board, the rest will follow". I'm not so sure. It would not hurt to emphasize PW's abilities to serve as a business/enterprise CMS right now. Take the benefit teaser on typo3.org for example, a perfect intro. It states: Open Source Enterprise CMS Scalable Web Application Framework Large, active global community User friendly with unlimited extendability Integrated Development and Editing Workflows I guess most of these advantages do fit to ProcessWire as well or, in the case of continuous integration, are on the doorstep (at least that's how I read "Integrated Development"). And PW's community may not be large yet, but is damn active. Apart from that, the home page is full of, hm, let's say: trigger words that work on some business business owners: "enterprise", "professional", "web solutions" and "certificates". I'm not proposing to copy all this. But I have an idea: Since both TYPO3 and ProcessWire are relatively big here in Germany (each on their own scale) one could emphasize the "also a perfect business CMS" aspect on http://de.processwire.com. I guess this won't hurt "the brand" at all, but, possibly, create some insights on if and how such a communication strategy could work. /edit: These automated capitalized words in the thread title are really annoying :-/

I do agree with what everyone is saying, however I do think at sometime, in the near future, we should have a business model properly explained. We do need to promote and sell the business capabilities/potential of ProcessWire. I would hope that is what everyone is already doing now. I believe we can put our collective heads together and define what the actual business capabilities are and why they are. I believe a lot of the information is already on the website, we just haven't made a solid business case for using ProcessWire over other solutions. Sometimes it's simply using the basic keywords that business managers are looking out for. We have to remember that when we do use those keywords they have to be matched with solid and verifiable technology solutions (that work as advertised). Being considered an Enterprise solution is something totally different and as @Pete rightly says will take major input from Ryan and others.

I think anything that sees PW being marketed as Enterprise needs ryan's input as there have been discussions around enterprise support etc in the past and the last thing any of us want is to market it as enterprise without the infrastructure to back that up (for example if I was an enterprise customer seeing PW marketed as such, I'd go straight to the PW website to see if there was any official support from the core team in case things went wrong with the dev doing the work - it's only sensible to be cautious with large sums of money). I know marketing it as suitable for enterprise work and official support are two different things, and it's fine to discuss how to market it as such, I'm just saying that it's not as simple as putting up a page or mini-site.

I may would go with something like processwire.com/business/ or business.processwire.com or business.pw ((or enterprise.pw or vip.pw) redirecting to processwire.com/business/) which points out why ProcessWire is able to be used as enterprise/business CMS. Maybe also offer Premium Support and so on. Probably I would use a little different design of the page (at least colours). A little bit darker. So it feels more classy. And enterprise people think they are in there own section. Good examples: http://vip.wordpress.com/ https://www.dropbox.com/business/

No, of course not. The intention of this thread was to think about how one could emphasize PWs aptitude for business websites - as it is able to stand the test of being extandable, reliable and user friendly, to chose a few of the aspects TYPO3 advertises with. Emphasizing this alongside the other advantages already communicated, aimed at developers. No microsite, and no business model. Way too big.

1) Introduction A great ProcessWire site is useless without visitors. If the site lacks of direct traffic, the webmaster has to rely on search engine users clicking on the right result. The goal is a good position on the result pages of special keywords. Optimizing sites for search engines, mostly Google, is called Search Engine Optimization (SEO). You will find many of techniques, methods and ideas on the internet. The topic is widely discussed and new ways of SEO arrive every day. This tutorial covers the technical aspect for SEO with the ProcessWire CMS and should give you a general overview on the topic. 2) Why ProcessWire fits perfectly to your SEO strategy With ProcessWire, nearly all practices for SEO can be used. It might be one of the best CMS in this field. Let us explain these bold claims. Every SEO aspect is related to the content on your page. It can be some meta tags in the HTML-Head or how you structure your headings. Even microformats are just another way of how markup is presented to the visitor (or the search engine bot). After all, it's the logic on how we generate the HTML that we try to optimize. Where to put the content, how to define a site description or how URLs are made up. Most SEO modules for common CMS like WordPress or Drupal are generating the right markup. ProcessWire is a little bit different. As you might know, there is no pre-defined markup. Every line of front-end HTML code can be written by the programmer. As a result, there is no limit on how we can structure the HTML. You want those new fancy HEAD Attributes? No problem. Grab the first image of a gallery and define it as the meta og:image? Easy job, even if you need a special resolution for Facebook and a smaller one for Twitter. So, what do we have to do? We can't just simply install a one-click "SEO module". We have to define, which fields will represent which HTML attribute or how we wrap the content into microformat schemas. Ask yourself the following questions: Which values(keywords,descriptions,information) do I need for my SEO strategy? Are those values stored per page, for a section of your site or can they be defined for the whole site? Should the user/administrator enter those values or can they be combined/calculated based on other fields? What happens if there is no value defined for a field? How does the fallback look like? Beside that, some good practices for SEO are already implemented by ProcessWire. The URL structure representing the page tree is clean and you can even customize it to fit to your requirements. Unique URLs are standard. With modules like ProCache, MinimizePW or AIOM you can optimize page speed quick. Everything else, expect the server performance is part of the undefined HTML markup. 3) Example on how to integrate meta tags (or anything you like) We want to have some keywords and a (short) description in our HTML Head. So we create two fields, calling them e.g. keywords and description and add them to a template. Create a page with that template and enter some keywords and a description. In your template file output the fields in the HTML head: <meta name="description" content="<? echo $page->description ;?>"/> That's all. We can now extend this to have fallback or choose the fields with a more advanced logic. Nico explains this for example in his blog post. Extra hint: If we want to fallback on the (mandatory) title field of a page, we can use the ->get Method. <meta name="description" content="<? echo $page->get('description|title');?>"/> This will use the title field in case the description field is empty. You could use this to provide the user an option to "override" the SEO logic by manually entering the values. Another example would be the alt-tag for images. To provide an alt-tag for an image, we use the description field of the image field. In this example, we take the first image from the field "images" on the page. <img src="<? echo $page->images->first()->url ;?>" alt="<? echo $page->images->first()->description;?>"/> The description attribute is part of every PageImage field. You could hide it from the backend but it's visible by default. 4) Modules for SEO 4.1) XML Sitemap This module will generate a sitemap.xml that can be crawled and used by search engines. The basic setup just generates a sitemap.xml with every page included. You can finetune the settings if you want. 4.2) Textformater Microformats This module sets microformats for content in TextAreas/WYSIWYG areas. It will wrap basic content into the right schema.org schema. The module page provides further information 4.3) Page path history Moving a page to another URL? With this module you don't have to worry about visitors getting an 404 error. It will try to track changes in the URL of pages and redirect visitors to the new location - as long as there isn't a new page with the URL. 4.4) Multisite Sometimes you want to have some entry-pages for special keywords. If you need a special domainname for those site, you can setup the Multisite module. 5) Further links and tutorials Categorize content and build the right URLs. Might be useful for SEO strategies. Rebuild the URL structure by using URL-segments Another forum entry on the topic of SEO 6) Conclusion Maybe this little tutorials helps starters to get an idea, on how to optimize their page for search engines. This might seem little bit more difficult then just to install a one-click solution. But if you put in an hour to just think about a clean and readable markup with all tags, you will get great results. Any additions or practices are welcome. I will try to answer any questions in this thread and make the tutorial better over time.

Had to restart the apache manually via commandline - now the error message in the apache logs is away and the installation does not show the PDO problem - will try now to install. Success! So the problem with the missing PDO warning came from a corrupted php.ini Thanks again for your help!

Funny thing, I usually associate “Enterprise CMS” with something expensive and closed-source that consists of a weird combination of Java, Perl, XSLT and other outdated technologies which should not be used to build modern web sites or apps any longer. As for “Business CMS”, that's a term that I (just my 2 cents) find rather confusing. A lot of us make a living building more or less complex web sites and apps using ProcessWire. Judging from the Showcase forum, a lot of those web sites are for businesses. Besides, what would be a “non-business” CMS? Something for hobbyists? (Did I just hear someone say “Joomla”? ) In all seriousness, I don't think it's necessary to market PW for Enterprise/Business use. It (currently) is a CMS for developers. Devlopers who make/made an educated, informed decision to use this particular CMS. Developers who will (individually) market this wonderful CMS to their clients. I really liked the way Marc put it in the original thread – focus on building a smart, yet simple CMS that developers like. The rest will follow organically. No need to hurry it.

Solution was simpler than I thought (Thanks @Sumurai8 at Stack Overflow). Damn, .htaccess rewrites screw with my brain..... # rewrite the URL: folderTwo/* to http://domainTwo.com/* # as we want domainTwo.com/folderTwo to look like domainTwo/ # this works for any domain, so will rewrite: # http://domain.com/folderTwo/* # http://domainTwo.com/folderTwo/* etc # to http://domainTwo.com/* RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^folderTwo/?(.*)$ http://domainTwo.com/$1 [R,L] # redirects domainTwo.com to the PW /folderTwo folder RewriteCond %{HTTP_HOST} domainTwo\.com$ [NC] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ /index.php?it=/folderTwo/$1 [L,QSA]

My 2 cents, and sorry if I'm repeating things that have already been said – didn't have the time to read everything already posted here. Wordpress has become vastly popular as a blog system. It is being used by a gazillion of people worldwide, most of them not very tech-savvy, which is why there is a huge market for prefabricated themes and plugins. It started out as a small open source project, but is now – at least partially – being developed by a company with about 250 employees plus a very active community of freelance developers. Due to its huge popularity, it has morphed into a system which can also be used as a CMS. This exponential growth into the most popular content publishing system worldwide has taken it's toll. It's bloated, there are unmaintained plugins, it has security issues and if you look closely, the sheer number of themes and plugins does not necessarily say much about their quality. (Did I just hear someone say “Windows”? Nevermind.) ProcessWire is a content management framework/system which was originally developed by a single developer. The community is picking up lately with more people developing plugins as well as contributing to the core while the system also gains traction with a small, but loyal user community. It's clearly not a system for everyone, mostly based on the design of the system. It might never become a system for end users, but obviously it has become rather popular among developers looking for certain features in a CMF/CMS. Why anyone would seriously want to compare both systems is beyond me.

From my point of view - the critical points of PW in that article are the best for me Some day i've read a very interesting article about "Are you a tooler?" (i think it was AListApart - not shure) So for me i was until now in the world of "toolers" - using this addon, snippet, module to make the system i choose to do what i want - because in lack of skills to bending this system complet to fit my/customers needs. Always willing to learn and helped some real devs out with testing and translating - to get some help on the different things. And now with ProcessWire i feel like i'm a "thinker"!! I've ONE tool to use in different kind of models/usecases/options to get what i want. Ok as usual and first i've tested all the modules and addons in the rack - but i feel they are all just needed for a special propose and not to get a website work great like this is the fact for the drulapress CMS world!! Every week i'm reading this forum i'll get new ideas how to use PW from this really great community (Like to set up a "onliner" with a hidden pagetree to get a complete tagsystem running or other usefull stuff) Themes are for me no problem - get a HTML Theme from ever you want and setup is done in about let's say "30 minutes" So are you a tooler or a thinker? Are we talking about a software that helps you working without a limit - or a tool that complete works for you but always have it's limitations you have to take? Thankyou Ryan for this one great tool - thank all others here as far as i read this forum - here is a meetup with great people! 2 cents from a guy that love PW after 30 minutes testing

I still think that if a complex profile were to be created that had theming, widgets, other expected fair, then it should be on its own site with its own support. It would be "built" on ProcessWire, but it would no longer be the core PW. Likewise, if a full blown e-commerce system was built on PW (now, that would make far more sense as a project), then that too should be on its own site with its own support structure. There is a bit of me that says that to create a themable version of PW seems more to be fulfilling the idea of attracting WP type users, than does it achieve anything huge. I am part way writing a tutorial to help WP and Joomla designers and developers to make the transition to PW. It is not a technical "how to" but more about how you need to change you way of planning and working and thinking. In the process, it strikes me that there are already lots of perfectly good "out-of-the-box" pop-up type CMS solutions out there. As I write the tutorial and explain the strengths, they tend to be more about the fact that is hasn't got a theme or template engine, that it does not rely on bespoke plugins to create functionality and so on. Its core strength is that unlike WordPress which is really an AMS (Article Management System), ProcessWire is a true Content management System - you create content with it and then you manage it. Separately you work out how to display it. Importantly, if you discard the current default profile and, instead, install it with a blank profile, its strengths are much more obvious, The default profile with sample pages and some images, misleads you into thinking it is something like the rest of the AMSs out there. When you have nothing except a title field, an admin.php and a home.php (no html of course, just a single $page->title call on its own), then its nature as a true CMS is clear. To paraphrase old MS marketing: "Welcome to PW. What content would you like to manage today?"

Well basically when you follow the RESTful approach when creating systems, you use resources rather than actions. you can know more here http://restcookbook.com/ http://restpatterns.org/ http://www.restapitutorial.com/ and this books https://leanpub.com/build-apis-you-wont-hate http://www.soa-in-practice.com/ Example if you want to make an admin for the users resource. you can have this URL http://api.example.com/users In the traditional CRUD aproach, the verb is inside the URL like http://api.example.com/users/create but in REST you must use only HTTP Verbs to interact, so the same endpoint url makes different actions depending on the verb used to call it. In our system that could be http://api.example.com/users GET - result in a list of users POST - creates a new user ------------------------------------- http://api.example.com/users/clsource GET - result in the user data PUT - updates the all the data of a specific user PATCH - updates a specific data field of a specific user DELETE - deletes the user Using the HTTP response codes and mime types you can notify the result of an operation, usually with a JSON or XML body for information. The Web services Approach, specially REST web services, enables us to separate complex systems in smaller ones, easier to mantain and test. Basically you can have multiple backend systems that just are APIs and one frontend system that glue them all. this add a layer of security and robustness, because you can separate your systems in different servers. A possible attack can not affect all the system, just small parts of it.

PDF Fieldtype/Inputfield Module for ProcessWire allowing you to easily generate thumbnails of the PDF files embedded to the site. Current version: 1.1.2 (Changelog) Module page: http://modules.processwire.com/modules/fieldtype-pdf Github: https://github.com/uiii/ProcessWire-FieldtypePDF For detailed instructions see: https://github.com/uiii/ProcessWire-FieldtypePDF/blob/master/README.md

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/

This is an inputfield module integrating Trumbowyg WYSIWYG editor into ProcessWire, quickly hacked together after some discussion at the Redactor thread. Trumbowyg is a light-weight alternative to more feature-rich editors, such as CKEditor or TinyMCE. Both this module and Trumbowyg itself are still in alpha state. Customisation options include only a subset of what Trumbowyg provides, more will be added in the near future. Also, link and image features as seen in other RTE modules (TinyMCE and CKEditor) are not implemented yet. The module is available at https://github.com/teppokoivula/InputfieldTrumbowyg.

Hi guys! I'm working on several processwire 3d wallpapers. Hope you like it. I will upload more soon. Wallpapers: Signatures:

Btw, what are you PHP and MySQL versions...?

Hi Netcarver, Just to let you know, your suggestion worked but I had to comment out the line in all three of the .module files in order to get each of them to install. Thank you very much for the module and your help with getting it installed Cheers.

This would be a good article for the new docs section!

you could also make a module that would automatically add the child pages to the parent's page table if they are created from the page tree, hooking into saveReady on the child page's template... $page = $event->arguments[0]; if($page->parent->my_page_table->has($page)) return; $page->parent->setOutputFormatting(false); $page->parent->my_page_table->add($page); $page->parent->save();

You don't close the <ul> of your blog posts (2nd error). 3rd error is a following error because of that. 1st error is a common html5 boilerplate thing which shouldn't concern you. One thing in general: Put the Javascript to the bottom and I don't know the CSS framework underlying, but using CSS expressions for responsive web design seems a bit outdated ;-) Besides that: The site looks good and does fit to the topic. I know your struggling with given font and colors, but you made the best out of it!

Good link Nico. Didn't know that was there

Unobtrusive support at it's best

Hi Gazley, I have an idea what this might be. Can you edit TextformatterTextile.module and comment out the 'requires' line... // 'requires' => 'PHP>=5.3.0' ...save the file and reload the modules page. Let me know if that fixes the issue for you.

@LostKobrakai: You are right, but only to, maybe 80 - 90%. I also can understand pwired a bit. Just imagine the client from your example chooses PW one day because it supports 1-click theme-switching for those who are willing to use it. Additionally to that he can import a whole WP-blogsite content by using the WP-migrator with only clicking two or three buttons. What do you think does this do to him if he later on want to extend his site with a cool shopping cart, a newsletter system and some other shiny things he has read from here? I bet he think that this can be done with just clicking some buttons, because he has changed to PW because he has heard this is better than XY before. Also his first steps really only needed some simple clicks. So why should he think that this cannot be done that easy? Also the community is so friendly and helpful. - If he has only little or no HTML/CSS skills and no PHP/JS skills, (and maybe he also has no interest in learning this), I only can say: good luck and a lot of patience with such new users. So, it will be different with those who are able and willing to understand the differences of application modules. We should do it in a relaxed manner. One of the best goods here (besides PW itself) is the helpful and kind community. And it takes time to "assimilate" new users from that spectrum. Also I think it only could be a small amount at a time. - The worst case would be if they try to assimilate us

Imagine what would happen if PW should change into an out of the box cms with shiny templates, plug and play, 1 click add-on's, etc. etc. Everything would start to degrade right away even the forum. The inner architecture of pw is one of the clear reasons why this forum is filled with talented coders, people who know what they are doing and people who want to learn. A great side effect of working with pw and being on this forum is that it pushes less talented coders to upgrade their coding skills. This is many times the preferred way. If people need shiny templates, banners, slideshows or other things then tutorials on how to do this with pw would be the best way I think.

I won't tell to much but I'm currently working on a theme module anyway. Website is already kind of ready: http://processthemes.com/ But I think we all should agree on at least one thing: ProcessWire should never integrate a real theme engine in it's core. never.

Hello, If ProcessWire goes down the road of theming, I would be very vocally against it. Along with "themes" comes a set of assumptions and core approaches that many of us detest. One of the main reasons I fled from Joomla, Drupal, WordPress is specifically because of theming. Anyway, providing themes would be a temporary attraction to people accustomed to the way the "Big Three" CMSs work. The moment users of those other systems need something further, they again would have to understand core design/markup/interactive web technologies. Beyond superficial themes, the general fact that ProcessWire is different will become apparent again. In other words, the differences between ProcessWire and the Big Three goes far beyond profiles or themes. It's somewhat of a waste of energy for us to appeal to Big Three users with themes or profiles. I think we need to be clear that ProcessWire is a system that expects you to take some initiative to get up to speed on the core web technologies. It is not, and should not become, a system that "does it for you." It may be difficult to accept, but ProcessWire will never appeal to most WordPress/Drupal/Joomla users for that reason. Thanks, Matthew

I think most of us go little bit too hard on this article: it was mostly a well written response to a Mike's "PW vs. WP" article, responding some of the reasons that Mike underlined why they moved from WP to PW. It was honest about the scope regarding ProcessWire (30 minutes, looked for demo, visited forums etc, but mainly just first impression). It also has nice summary about why PW is not Jeff's next publishing system: PW audience seems to be developers (instead of "I just want cool looking website without any coding") It doesn't do out of the box things that Jeff excepts from publishing system PW doesn't have themes PW and WP are totally different tools and I think that both Mike's and Jeff's articles showed that it is pretty hard to have "head to head" comparisons between these two. I really enjoyed reading both articles, and I believe that most developers who end up reading those articles (and their comments!) probably will at least try ProcessWire. Now we should also try to get people from Laravel, Zend, Django, Drupal etc. crowds to try PW. I think that is much more interesting crowd than your regular "hi, I created WP site in 5 minutes" people. Developers using those frameworks are building the greatest stuff there is currently. Of course lot to learn from WP camp also, but I would really focus on developers and framework side of PW instead of "best website builder there is". It's not surprise that WordPress seems to be heading also to more "general cms / framework / platform" direction instead of "easy to use publishing". The latter is very competitive market, with all those website builders like squarespace, virb, weebly, wix, google sites.. even facebook etc. You need keep developers happy, to make sure cool things are coming in future too.

Processwire: used by people who were looking for something better and used by talented coders who recognized pw´s internal core. Processwire is chosen and not followed. For some hard to swallow.

@jeffro: Great that you joined this conversation over here! As far as I can see one of your main concerns is that ProcessWire doesn't offer ready-to-go themes. That's right and I think one of the points why processwire still is in the developer niche. But if you understood the ProcessWire concept (create fields, build a custom template/form and add it to pages) you should realize that it is probably not possible to create switchable themes for ProcessWire. It's like using WordPress with ACF and trying to find a theme for it which works out of the box with every custom ACF field. Our approach was to add a thing called "Site Install Profiles" which is a compilation of the template files, the needed modules and the needed fields and backend configuration. My suggestion was to offer like three default "Site Profiles": Demo Profile The Demo could include a guided tour through the CMS. Or we could build a "tutorial module" which could be in the /site/modules/ folder and would be deleted after the tour. Not sure on this point. Like the name said this would on the one hand a module do demonstrate how you build a template for designers / developers and on the other hand an template for presenting how Processwire works to your clients (with the backend tutorial stuff). Starter Profile I would rename the "default" profile to "starter". It should include all the fields an average user would use (like title, headline, body, images, files, ...) and should be the main profile which is included in your default installation. This one is a ready to go solution. This "starter profile" would be the profile we could design Themes for and stuff like that. So like I said a ready-to-go profile for the average user who don't need customized stuff. This would be the profile for my mother Clean/Air Profile The third profile should be for advanced users who like to set up their own fields and templates. Kind of how Soma's blank profile is. It would be shipped without these amount of templates and demo pages.

Prerequisites: Basic knowledge of git and git submodules A git hosting solution (e.g. GitHub) No aversion against bash commands Once you've built a couple of websites with it, a set of your own personal must-have modules emerges. For me, such a module and always the first install of the day is Soma's MarkupSimpleNavigation. But there's also MarkupSitemapXML. And so on. Depending on your usage of ProcessWire, the type of pages you build with PW or your customers, your set of modules may differ. Installing modules and functionalities that you'll need in most instances should be an automated and easy process. ProcessWire itself offers a range of possibilities to do so. First, there is installation via ClassNames: In Backend, chose "Modules", then "New" and paste or type in the class name the desired module established in the PW ecosystem, for example `LoginPersist`. From that point on, the particular module gets downloaded and installed within two clicks and just a matter of seconds. Rinse and repeat until your starter module set is complete, but be sure to memorize or note the correct class names. Secondly, you can create an own starter site profile with your modules in it. This not only gives you the means to bootstrap in a module related way but also many possibilities for template and field groundwork. But a disadvantage (on the module site) remains: Unless you control and update all the modules in your site profile, only certain, possibly outdated versions will be installed - and you have to manually update them afterwards. For my last few projects I found a third way: Bundling all starter/must-have modules together in a git repo, using the modules as git submodules. After ProcessWire installation on my local machine, I just clone this bundle and recursively pull every module's master to its latest commit. An example (with my set of starter modules): cd site/modules && git clone --recursive git@github.com:marcus-herrmann/ProcessWire-BootstrapModuleSet.git && cd ProcessWire-BootstrapModuleSet && git pull --recurse-submodules What does this code do? At first, let's assume you've navigated via the terminal to you ProcessWire's installation root folder. Afterwards, these steps follow: 1. Change directory to module folder 2. Clone your bundle repo 3. Change directory to the folder created by aforementioned bundle repo clone 4. Pull all submodules to their latest commit That's all. After you've created your own module bundle repo, you can even create a bash alias for this and accellerate the process even more: alias getpwstartmodules='cd site/modules && git clone --recursive git@github.com:marcus-herrmann/ProcessWire-BootstrapModuleSet.git && cd ProcessWire-BootstrapModuleSet && git pull --recurse-submodules' I possibly may have reinvented the wheel. But at least I haven't yet found such a way for "PW kickstarting" before (apart from maybe pure bred package managers such as npm and composer). But if a better solution exists, please do not hesitate to drop a comment here Disclaimer: This is also a blog post

I am having a lot of fun today (having worked out a game throttling kink with Soma last night - thanks mate) I have about 900 plus pages all about car manufacturers, models, servicing, prices and the rest. So what? Well, it is the way I have been able to put them together with PW and PHP So, I have a function that lists all the services like gearbox rebuilds, or body work repairs. On its own, on a normal page, it just links to the pages about those things. On a car manufacturer page it changes from Gearbox Rebuilds" to "Audi Gearbox Rebuilds" with an extra URL segment in the URL that adds /audi/ The function gets two extra arguments to work the magic: rightMenu($page->title,$page->name); Now on the gearbox rebuilds page it is suddenly all about Audi gearbox rebuilds with text changes all thanks to hanna code. Also on the manufacturer page it lists all the models for audi and gives servicing prices for each model. Prices are set globally (since most cars cost the same) but can be overridden individually if the client wants. Now I just need to add Ryans clever linking thingy for text and suddenly I will have everything cross linking all over the place. The Really, Really, Really amazing thing about this is that I have been able to code all this from scratch with so little knowledge that it is frightening, but there I am, staring at a 900 line functions file, stuffed with php and PW API, and I did it all. And it works! The reason is the API - to code this fully would be so overwhelming that I would not even consider it, assuming I even knew where to start. But the API wraps up so many complications is such brief statements, that suddenly it is not only easy, but clean, clear and understandable - even for an old has-been, burnt out, media bloke like me. The only down side is that the client is being so undercharged for this that it is criminal - but then, it is not his fault that I decided to get carried away and add 900 pages to his site.

Ohh wallpapers! I have one too!

The great thing about ProcessWire and all the great tools/modules associated with it is that I have been motivated to relearn PHP, HTML, CSS and Javascript. I have never had so much fun as in the last year. Hanna Code specifically with Ryan's original Foundation 4 profile made learning too easy. I have now gone on to other CSS Frameworks with no fear. I still got the API, functions, modules and many other things to learn in ProcessWire. I can't say that I am bored with ProcessWire. From my point of view, It's great to be an old geezer. I embrace it because it doesn't keep me from learning new and exciting things.

I guess Teppo is on holidays

Hi tehandyb There is a rough translation between traditional terms and ProcessWire's, which is: Templates = tables Fields = columns Pages = rows Template files = controllers & views In ProcessWire, you would create the necessary fields for your content, add the to one or more templates (to define your "schema" in a way), and you create pages based on those templates. The page output is handled by it's template's file. The fields you add to the template can vary from integers to text input to map markers (and more). In your example, you would probably want to create templates for at least event and location. Users, roles and permissions already exist in PW, but you can extend these for your own needs if you have to. The key to linking pages together (individual users, locations and events) is the Page fieldtype. This allows you to create a field that can reference one or more other pages of a type of your choosing. Back to your example, I'm going to presume an event might have one location or none at all. First, create a location template with the basic fields you need. Create a section of your page tree to store them. If you don't want them to show up in lists or searches, set the parent to Hidden. Then, create a new field called location and add it to your event template. Configure it to list pages with a template of location and the parent page where they're stored in your tree. You can also choose what type of inputfield it will use - a Dropdown or PageListSelect might be appropriate depending on how many you have. When you have done that, creating or editing an event will allow you to choose a location from the list. In the event template file, you would access it like this: <p>This is the <?php echo $page->title ?> event.</p> <p>The venue is: <?php echo $page->location->title ?>.</p> I'd recommend reading some more documentation and this brilliant thread on categorising your content.