Leaderboard

Just pushed version 1.1.0 to github. It adds options to hide tabs, but also new nice feature where edit area and links are shown on when hovering (fallback to normal links when using touch enabled device).

Hi Guys, I've only ever met one other person who uses Processwire (mainly as I told them too and i was wondering if there was many PW users in london and whether we should get togther for a drink sometime? ben

While I was it, I decided to tackle the PageTable problem also. So now the version 1.1.1 works with PageTables also (it's modal inside modal, so not exactly the dream come true, but it works if you need it).

Just pushed version 1.1.0 to github. Please let me know how it works. I went pretty closely with Bernhard's original css stuff, I also added options to hide additional tabs. Although I have feature detect for touch, when hovering is not required to see edit links.

if($page->Background_Image->count > 1 ){ $bgimage = $page->Background_Image; echo '<script>$.backstretch(["'; echo $bgimage->implode('", "', "url"); // results in url", "url", "url echo '"], {…});</script>'; } }

This is already on the Wishlist, but named a little different. https://processwire.com/talk/topic/9730-get-pages-used-by-a-pagefield/

Yes, my approach would probably result in cleaner markup and I guess more maintainable too. You can use this to avoid empty data (or class) attributes: <div <?= data_edit_id($page->id); ?>></div> I would do an each loop in js to add the actual edit buttons where data_edit_id is available. Plus add the click handlers of course. This also means that it won't run without javascript, but in the admin it is always available.

This worked really great for me in a site with thousands of pages $selector = "template=pages_template"; // as an example while (1) { $p = wire('pages')->get("{$selector}, id>$id"); // get page with id bigger than previous if(!$id = $p->id) break; // assign current page's id to $id or break the loop if it doesn't exist // do stuff using $p as the current page wire('pages')->uncacheAll(); }; Like this you never have an array in memory, only one page at each time, and you can do all the operation in one go. Of course you would probably have to constantly write to the csv file (like, open,write,close,open,write,close,open,write,close edit: this doesn't make any sense you can open, write, write, write,... close), but I don't think that would be a problem. Edit: Ideally you would do this from the terminal by bootstrapping PW, to prevent overloading apache.

Another option is to call $pages->uncacheAll() at a regular interval. This helps you avoid memory issues in most cases, and allows you to run the whole query at once. For a rough example, see how it's done in VersionControl.module. If you do take this route, make sure that your maximum execution time isn't an issue here either. If your script takes a long time to run, you'll usually want to increase the max execution time using set_time_limit() first. The default value is typically 30 seconds, and a script running longer than that gets killed. First things first, though: you mentioned that the page goes blank supposedly because of a memory issue. If you're not 100% sure of the reason for the issue, the very first thing you should do is checking why it actually happens. Do the same thing in a test environment with $config->debug = true, or see your error logs on the live site. Assuming is never a good strategy

In ProcessWire 2.5 or 2.6 the minimum PHP version is 5.3.8. Running your installation at any version less than what is stated is certainly possible but not supported. FYI, PHP 5.2 End-Of-Life was 6 January 2011. PHP 5.3 End-Of-Life was 14 August 2014. As the official PHP website states If you are using these releases, you are strongly urged to upgrade to a current version, as using older versions may expose you to security vulnerabilities and bugs that have been fixed in more recent versions of PHP.

I like the idea of adding class into parent element and using that to hide/show/style the hover. I think it will work in most designs, but not all. I'll add that as option into Fredi.

Since you guys asked for it, I'll take a stab at a case study on the development process. Most of the development was done in about a week and a half. I started with the basic profile, but it ended up being something somewhat similar to the Blog profile in terms of how it's structured. Below I'll cover some details on the biggest parts of the project, which included data conversion, the template structure, the front-end development and anything else I can think of. Data Conversion from WordPress to ProcessWire One of the larger parts of the project was converting all of the data over from WordPress to ProcessWire. I wrote a conversion script so that we could re-import as many times as needed since new stories get added to cmscritic.com almost daily. In order to get the data out of WordPress, I queried the WordPress database directly (my local copy of it anyway) to extract what we needed from the tables wp_posts for the blog posts and pages, and then wp_terms, wp_term_relationships, and wp_term_taxonomy for the topics and tags. WordPress stores its TinyMCE text in a state that is something in between text and HTML, with the most obvious thing being that there are no <p> tags present in the wp_posts database. Rather than trying to figure out the full methodology behind that, I just included WP's wp-formatting.php file and ran the wpautop() function on the body text before inserting into ProcessWire. I know a lot of people have bad things to say about WordPress's architecture, but I must admit that the fact that I can just include a single file from WordPress's core without worrying about any other dependencies was a nice situation, at least in this case. In order to keep track of the WordPress pages imported into ProcessWire through repeat imports, I kept a "wpid" field in ProcessWire. That just held the WordPress post ID from the wp_posts table. That way, when importing, I could very easily tell if we needed to create a new page or modify an existing one. Another factor that had to be considered during import was that the site used a lot of "Hana code", which looked like [hana-code-insert name="something" /]. I solved this by making our own version of the Hanna code module, which was posted earlier this week. Here's an abbreviated look at how to import posts from WordPress to ProcessWire: $wpdb = new PDO("mysql:dbname=wp_cmscritic;host=localhost", "root", "root", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $posts = wire('pages')->get('/posts/'); $sql = " SELECT * FROM wp_posts WHERE post_type='post' AND post_status='publish' ORDER BY post_date "; $query = $wpdb->prepare($sql); $query->execute(); while($row = $query->fetch(PDO::FETCH_ASSOC)) { $post = $posts->child("wpid=$row[ID]"); // do we already have this post? if(!$post->id) { // create a new post $post = new Page(); $post->template = 'post'; $post->parent = $posts; echo "Creating new post...\n"; } $post->of(false); $post->name = wire('sanitizer')->pageName($row['post_name']); $post->title = $row['post_title']; $post->date = $row['post_date']; $post->summary = $row['post_excerpt']; $post->wpid = $row['ID']; // assign the bodycopy after adding <p> tags // the wpautop() function is from WordPress /wp-includes/wp-formatting.php $post->body = wpautop($row['post_content']); $post->save(); echo "Saved post: $post->path\n"; } What I've left out here is the importing of images, topics, tags, and setting the correct authors for each post. If anyone is interested, I'll be happy to go more in depth on that, but didn't want to overwhelm this message with code. Template File Structure This site makes use of the $config->prependTemplateFile to automatically include the file _init.php before rendering a template file, and $config->appendTemplateFile to automatically include the file _main.php after. So the /site/config.php has this: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; You may recognize this as being the same setup from the Skyscrapers profile. The _init.php includes files containing functions we want to be available to all of our templates, and set default values for the regions we populate: /site/templates/_init.php /** * Include function and hook definition files * */ require_once("./includes/render.php"); require_once("./includes/hooks.php"); /** * Initialize variables populated by templates that get output in _main.php * */ $browserTitle = $page->get('browser_title|title'); $body = "<h1>" . $page->get('headline|title') . "</h1>" . $page->body; $side = ''; $renderMain = true; // whether to include the _main.php file The includes/render.php file that is included above includes several functions for generating markup of navigation and post summaries, or any other shared markup generation functions. Examples are renderPost(), renderNav(), renderTags(). This is similar to the blog.inc file from the Blog profile except that I'm letting these functions generate and return their own markup rather than splitting them into separate view files. I personally find this easier to maintain even if it's not as MVC. The includes/hooks.php sets up any hooks I want to be present for all of my templates. I could have also done this with an autoload module, but found this to just be a little simpler since my hooks were only needed on the front-end. The main hook of interest is one that makes all posts look like they live off the root "/" level rather than "/posts/" (where they actually live). This was in order to keep consistency with the URLs as they were in WordPress, so that the new site would have all the same URL as the old site, without the need for 301 redirects. /site/templates/includes/hooks.php /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } }); Our /site/templates/_main.php contains the entire markup for the overall template used site wide, from <html> to </html>. It outputs those variables we defined in _init.php in the right places. For example, $body gets output in the <div id='bodycopy'>, $side gets output in the right <aside>, and $browserTitle gets output in the <title> tag. /site/templates/_main.php <?php if($renderMain): ?> <html> <head> <title><?=$browserTitle?></title> </head> <body> <div id='masthead'> // ... </div> <div id='content'> <div id='bodycopy'><?=$body?></div> <aside id='sidebar'><?=$side?></aside> </div> <footer> // ... </footer> </body> </html> <?php endif; ?> We use the rest of the site's template files to simply populate those $body, $side and $browserTitle variables with the contents of the page. As an example, this is an abbreviated version of the /site/templates/post.php template: /site/templates/post.php // functions from /site/templates/includes/render.php $meta = renderMeta($page); $tags = renderTags($page); $authorBox = renderAuthor($page->createdUser); $comments = renderComments($page); $body = " <article class='post post-full'> <header> <h1>$page->title</h1> $meta </header> $page->body $tags $authorBox $comments </article> "; if(count($page->related)) { $side = "<h4>Related Stories</h4>" . renderNav($page->related); } What might also be of interest is the homepage template, as it handles the other part of routing of post URLs since they are living off the root rather than in /posts/. That means the homepage is what is triggering the render of each post: /site/templates/home.php if(strlen($input->urlSegment2)) { // we only accept 1 URL segment here, so 404 if there are any more throw new Wire404Exception(); } else if(strlen($input->urlSegment1)) { // render the blog post named in urlSegment1 $name = $sanitizer->pageName($input->urlSegment1); $post = $pages->get("/posts/")->child("name=$name"); if($post->id) echo $post->render(); else throw new Wire404Exception(); // tell _main.php not to include itself after this $renderMain = false; } else { // regular homepage output $limit = 7; // number of posts to render per page $posts = $pages->find("parent=/posts/, limit=$limit, sort=-date"); $body = renderPosts($posts); } The rest of the site's template files were handled in the same way. Though most were a little simpler than this. Several were simply blank, since the default values populated in _init.php were all that some needed. Front-end development using Foundation 4 The front-end was developed with the Foundation 4 CSS framework. I started with the Foundation blog template and then tweaked the markup and css till I had something that I thought was workable. Then Mike and I sent the _main.php template file back and forth a few times, tweaking and changing it further. There was no formal design process here. It was kind of a photoshop tennis (but in markup and CSS) where we collaborated on it equally, but all under Mike's direction. After a day or two of collaboration, I think we both felt like we had something that was very good for the reader, even if it didn't originate from a design in Photoshop or some other tool like that. I think it helps a lot that Foundation provides a great starting point and lends itself well to fine tuning it the way you want it. I also felt that the mobile-first methodology worked particularly well here. Comments System using Disqus We converted the comments system over to Disqus while the site was still running WordPress. This was done for a few reasons: Disqus comments provide one of the best experiences for the user, in my opinion. They also are platform agnostic, in that we could convert the whole site from WP to PW and not have to change a thing about the comments… no data conversion or importing necessary. Lastly, ProcessWire's built-in comments system is not quite as powerful as WordPress's yet, so I wanted cmscritic.com to get an upgrade in that area rather than anything else, and Disqus is definitely an upgrade from WP's comments. In order to ensure that Disqus could recognize the relations of comment threads to posts, we again made use of that $page->wpid variable that keeps the original WordPress ID, and also relates to the ID used by the Disqus comments. This is only for posts that originated in WordPress, as new posts use a ProcessWire-specific ID.

I have been spending some long evenings building PadLoper. It is my personal project to challenge myself as a developer, but also something I believe ProcessWire really misses: a solid eCommerce platform. I am happy to announce, that I am not very far away from public release, so I did create a little teaser site and email list for all of you that are interested: https://www.padloper.pw/ As many of you now, I also have bunch of eCommerce modules called "shop for processwire". Those remain open source modules, but I am not actively maintaining them (like I really haven't since 2012). All the code in PadLoper is new and it's totally build from ground up. If someone wants to maintain or develop shop for processwire further, I am more than happy for that. There will be some open source components coming from PadLoper also: at least payment modules, but I might also open source the shopping cart module. Padloper released 4th October, 2015: https://www.padloper.pw/

Please add your ProcessWire sites to our directory, immediately before or after posting to this board. We want to make sure that everything posted here is also posted in our official directory.

In the last few weeks I've notices some request (e.g. here and here) to be able to get pages based on if they are selected in page fields of other pages. I think adding a method for this would be a nice addition to ProcessWire, as it's often the case that the pages itself are options we just want to get, if they are used somewhere. Currently the task "Get all tags used by some blogposts" has to be done manually like this: $tags = $pages->find("template=tags"); foreach($tags as $tag){ // Filter unavailable if(! $pages->count("template=posts, tags=$tag") ) continue; // Do stuff with it } Now it would be nice to have something like this, where we don't need to have a selector for tags (this is done by the pagefield already). // Find all pages, which are selected in the "tags" field of the selected posts $available_tags = $pages->findSelectedPages("template=posts", "tags"); I'm not that big a MySQL guy, but I can imagine this not only improving readability, but also reducing database calls.

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/

So, when storing those pagetable child pages as native children in the pagetree, we can easily get them selected. But when we need to store them on a different (out of the way) location in the pagetree, this relation is lost. Wouldn't it be nice to have the ability to build a selector like: $pagetablechildren = $pages->find("parent-pagetablefield={$page->pagetablefield->id}, template=xyz"); Or is this already possible and I simply don't know it?

I think you can do it simpler than the way you are doing. <?php $bgimage = $page->Background_Image; $output = "<script> $.backstretch(["; foreach($bgimage as $image){ $output .= '"'.$image->url.'",'; } $output = rtrim($output, ','); $output = "], {duration: 3000, fade: 750});"; echo $output; Usual written-in-browser caveat. So, what we are doing is building our output as we go along. The main (minor) advantage is that after the end of the foreach we can strip off the last trailing comma using rtrim. It doesn't matter how many background images there are - 1 or n. Darn! LostKobrakai beat me to it (with a very elegant reply).

http://web.archive.org/web/20120819010829/http://lukasepple.de/blog/2012/08/grundlagen-processwire

I don't think there's a module for this, but it's kinda easy to circumvent timeouts. You'd build a php file that calls a reasonable number of users (1000 or so) using the pagination feature of processwire. The results are then written / appended to a file somewhere in the system. And the php then returns the next pagenumber, at best as simple json string. Now you'd just build some js, which calls the same page via ajax and iterates on as soon as the response is returned. After 40 calls you've your full csv. Another way would be using some SQL, to get all user id's and select the emails directly from the email fields table.

Seeing the same issue here in 2.6.0, MySQL version 5.5.42-37.1-log. Error is being generated by /wire/modules/Fieldtype/FieldtypeComments/FieldtypeComments.module: if($createdVotesTable) try { $database->query("ALTER TABLE `$table` ADD `upvotes` $upvoteSchema"); $database->query("ALTER TABLE `$table` ADD `downvotes` $downvoteSchema"); $schemaVersion = 5; } catch(Exception $e) { $this->error($e->getMessage(), Notice::log); } Without any deep understanding of what's happening here, I assumed it just needs to check if the columns exist before adding them, so I added some logic based on some other column-checking code I found elsewhere in PW: $isUpvotes = $this->wire('database')->prepare("SHOW columns FROM `$table` LIKE 'upvotes'"); $isUpvotes->execute(); $isDownvotes = $this->wire('database')->prepare("SHOW columns FROM `$table` LIKE 'downvotes'"); $isDownvotes->execute(); if($createdVotesTable) try { if ($isUpvotes->rowCount() === 0) $database->query("ALTER TABLE `$table` ADD `upvotes` $upvoteSchema"); if ($isDownvotes->rowCount() === 0) $database->query("ALTER TABLE `$table` ADD `downvotes` $downvoteSchema"); $schemaVersion = 5; } catch(Exception $e) { $this->error($e->getMessage(), Notice::log); } This seemed to work, and it reported that the FieldtypeComments schema was updated from 0 to 5 -- not sure if this the desired outcome. The errors have stopped, although I have no clue if that's a good thing...! Also, just tried installing FieldtypeComments on my local machine running PW 2.6.0 and MySQL 5.5.39, and it seemed to work fine without this modification. My "fix" is probably not the right way about it, I'm guessing.

Good Job! I like the design.

I just didn't want anyone to create unnecessary extra work for themselves unless they really wanted to

So basically you may found a bug in the previous version?

Ryan - I agree with Peter here. I find that Save label confusing, because by itself it doesn't make any changes to what the user sees in the admin if they then choose to "Cancel" rather than "Save as Copy" or "Save and Replace". I understand that the crop is saved to the page's assets/file folder, but it really becomes an orphan if "Cancel" is clicked - right? As for the "Save As Copy" and "Save and Replace" buttons, I really think the developer needs to be able to control which of these is available. There are many times when "Save As Copy" can really mess with template code loops to output images in carousel or thumbnail gallery. Thanks!

Hi and welcome! I actually just posted about this: https://processwire.com/talk/topic/10010-users-with-specific-role-as-checkboxes/?p=95546 You'll see a screenshot there showing how to configure a page field to grab all the users from your PW site. You can choose whether you want ASMSelect, checkboxes etc as the inputfield type. Let us know if you have any other questions.

Interestingly enough, I'm getting the same error (in 2.6.0), and I'm not even making use of the comments module... Edit: My bad, I see I do have a comments field in the template in question. That said, I don't recall adding it. But that could be my terrible memory. Edit 2: Nope, looks like Comments and Categories was added when I upgraded to 2.6.0. Why would that happen? (This could be an error on my part, where I may have experimented with the comments module, but I really don't remember doing it because I specifically said to myself that this site doesn't need comments...)

I would do it like this: foreach ($page->tags as $tag) { if($tag->allowed_users->has($user)) { //show news item } } That assumes your page field that is linked to users is called "allowed_users". PS Sorry I forgot about the role issue when setting up the page field selector, but glad you sorted it out!

Nice design and interesting topics (and german). Big thumb up (Y)

here you go: it's very simple, yet extremely comfortable for clients. you just need one simple javascript function: function editLink($pageid) { if(wire('pages')->get($pageid)->editable()) { // add page if action == add // check permission first! ob_start(); $editid = "editlink_" . uniqid(); ?> <div style="position: relative;" class="editlink" id="<?= $editid ?>"> <div style="position: absolute; right: 0; top: 0; z-index: 100;" class="uk-text-right"> <a href="/admin/page/edit/?id=<?= $pageid ?>&modal=0" target="_blank" class="uk-button uk-button-primary editmodal" style="color: white;"> <i class="uk-icon-edit"></i> edit </a> <?php // next floating button here ?> </div> </div> <script type="text/javascript"> $(document).ready(function() { $("#<?= $editid ?>").parent().addClass("editlinkparent"); // paddings must be adjusted when window is resized $(window).on("load resize", function () { // remove top and right margin var paddingright = $("#<?= $editid ?>").parent().css("padding-right"); var paddingtop = $("#<?= $editid ?>").parent().css("padding-top"); //$("#<?= $editid ?>:first-child").css("border", "1px solid blue"); $("#<?= $editid ?>:first-child").css("right", "-" + paddingright); $("#<?= $editid ?>:first-child").css("top", "-" + paddingtop); }); // colorbox /*$(".editmodal").colorbox({ iframe:true, width:"90%", height:"90%", onClosed: function() { location.reload(); }, });*/ }); </script> <?php return ob_get_clean(); } else return false; } and little CSS: // edit link .editlink {display: none;} .editlinkparent:hover {outline: 3px solid #ddd;} .editlinkparent:hover > .editlink {display: block;} note that i'm using markup for UIKIT css framework. what it does: let's say you have a blog-template showing all the children as postings. all you need to do when you want them to be editable on mousehover would be this: <?= editlink($page->id); ?> <section class="uk-grid uk-margin-left uk-margin-right uk-margin-large-top"> <div class="uk-width-large-3-4"> [...] <?php foreach($posts as $post): ?> <div class="uk-grid"> [...] <div class="uk-width-medium-3-4"> <?= editlink($post->id); ?> <h4><a href="<?= $post->url ?>"><?= $post->get('headline|title') ?></a></h4> [...] </div> </div> <hr> <?php endforeach; ?> the result is something like that: note that it needs only 2 lines of code! you can easily add this to any existing website in minutes... in FREDI you have to define your editable fields. that can be an advantage, but i prefer to only rely on the ID of the page (or the posting or the widget...) and have the user redirected to the right page in the backend. as you can see in the commented section of the function i also had this working with a colorbox and using modal=1, but it's more foolproof having it open in a new tab. using only the ID has the advantage, that if something changes with my field settings i don't have to change anything on frontend. how does it work? it injects some jquery javascript inline (it's only for logged in users so that won't affect your "public" markup of the page!) add HTML for the edit-button with edit-link add javascriptadd "editlinkparent" to parent DOM element this makes it possible to show the border around the affected content on mouse hover remove spacing so that the edit-button is on the very topright position of the highlighted div that's all again: i would love to pack that into a module so that it gets reuseable across other CSS frameworks with different markup and you don't have to care about adding the function and the css, but i don't know when i can find time for that. if anyone wants to try - all the info is above and i'm always willing to help

I like the logo personally. Fits the site. Pleasant, bright and does it's job perfectly friend.

sometimes clients need landing pages for marketing/seo that need to live off the root. all of these pages would make a mess in the page tree, so they are stored under /landing-pages/ I always do a hook (as was demonstrated in the CMS Critic Case Study) wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'landing-page') { // ensure that pages with template 'landing-page' live off the root $event->replace = true; $event->return = "/$page->name/"; } }); on the landing page template: // if someone tries to access this page at it's real location in the page tree, redirect to the fake URL: if(!$input->urlSegment1) { $session->redirect($page->url); } i should also add that on the homepage there is this: /** * First, check to see if there is a URL segment off the homepage * this is used to generate custom landing pages, for marketing etc.. * with a shorter URL, living off the root. * */ if(strlen($input->urlSegment2)) { // we only accept 1 URL segment here, so 404 if there are any more throw new Wire404Exception(); } else if(strlen($input->urlSegment1)) { // render the landing page named in urlSegment1 $name = $sanitizer->pageName($input->urlSegment1); $landingPage = $pages->get(2281)->child("name=$name, include=hidden"); if($landingPage->id) echo $landingPage->render(); else throw new Wire404Exception(); } else { // do the normal homepage... so that's why the segment check on the landing page template, because when it is being rendered from the homepage, if(!$input->urlSegment1) will be true

Ivan, you should have a look into the sites/assets/cache folder. If you can find a file there called LazyCronLock.cache, it is a sign that LazyCron once has started, but get not finished. To see when it has started, you may have a look to file date lastmodified, or look into it, it only contains a unixtimestamp. The reason(s) why it doesn't get finished could be that a script gots crashed / interrupted badly, - that a script is running in an endless loop, - or something that like.

Hey, after reading woop.s pdf over http://lightning.pw): Login: http://terbium-znu.lightningpw.com/processwire/ Name: demo Pass: demo123

I think it would be a nice idea to add an image/field count to these inputfields. Something like below, where it says '(12)'. For me this would be a handy little addition.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

I've posted the first iteration of the directory here: http://processwire.com/about/sites/ – I plan on doing a lot more with it (including a landing page for each site), but just wanted to get something posted quickly since we may be getting more traffic coming in soon with the Bitnami release. Thanks to those that have submitted their sites so far. Thanks especially to Marty (stillmovingdesign), one of the most prolific ProcessWire users, for taking the time to submit all of his ProcessWire sites in there. We went from having about 5 sites to having 30 after he submitted his. Now we've got about 64 sites in there. Please keep submitting posting your ProcessWire sites. We want to show a comprehensive diversity of work in the directory, and it's already coming along really well! I've added a few of your sites for testing purposes. If you already see your site there and want to change something about it, just re-submit it and I'll overwrite the existing one.

<?php /** * Page edit per user created id * */ class PagesCreatedEdit extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Pages created edit', 'version' => 1, 'summary' => 'Page edit only for created pages by user', 'href' => '', 'singular' => true, 'autoload' => true, ); } public function init() { // add edit permission hook for admin pages $this->addHookAfter('Page::editable', $this, 'editable'); } public function editable($event){ $page = $event->object; if(!$this->user->hasRole("editor")) return; if($event->return) { // only if edit rights are true if($page->created_users_id == $this->user->id){ $event->return = true; } else { $event->return = false; } } } } THis will get you there, not many different from frontend coding.