Leaderboard

What's about: $page->parent('parent=' . $page->rootParent); // $page->rootParent returns $foo as Page, not name, not id just for the case that the name of foo will change in future, or: what is about usage in a multilanguage site?

So I suppose this is a somewhat pointless addition, seeing as drafts are about to come to the core, but I needed this right now and ProcessWire made it possible for me to implement over the last two days. An experience that convinced me once more that ProcessWire is absolutely amazing. GitHub link. So what does this do? This module allows you to create a draft version of (hopefully) any page, which can be edited while the public facing page remains in place and unchanged. Drafts are placed under a special Admin page, which also doubles as a rudimentary manager. It shows what pages have drafts assigned and lets you update the original page with its draft. I need all this mainly for front-end editing, so for me the focus is on the added API methods. I have added functionality to redirect every edit to a draft page for testing, and it can make sense to have that behavior of course, so it will probably become a config setting. How does it do that? Page cloning is very very handy for this purpose, so that’s mostly what I’m doing here. It’s elegant in that very little code is needed, but it is perhaps somewhat crude to delete pages, including their field data and files on the file system, so much. I needed some hacky-feeling tricks to convince PW to delete pages that have children and clone pages to my custom admin page even when their template prohibits that sort of parent. What doesn’t this do (well)? Since a draft is linked to its page by having the page ID for a name (!), which conviniently also guarantees uniqueness, modifying page names should be pretty much impossible. It would be best to create a table to store the references, but I kind of like that you can keep everything 100% PW API. The most complicated fieldtypes I have tested this module with are Images/Files and Multiplier. That covers my immediate need, but perhaps PageTables will cause problems. I don’t have any experience with those. There are probably a lot of other things to look out for, but I can’t remember any more right now. Be aware this is most definitely not production ready or anything. I would like to thank Teppo Koivula, whose Changelog module I used for inspiration downright based this on. Great work there, and a lot to learn from. If you find fragments of Changelog in this module, that’s no coincidence. Also hugely helpful are the great members of this forum and Ryan’s code, which I assume we all use as our main documentation <3 Please absolutely tear this apart, if you can spare the time to have a quick look. I like to think I did okay, but I’m eager to learn and I’m sure this is full of questionable practices, bugs and inefficiencies. So yeah, its unlikely anyone will have the need to use this on a site, but hopefully I can get some feedback out of it and perhaps it can teach other beginners like me a trick or two. GitHub link again. /wall of text

Just in case anyone missed it... https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html The headline is: Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. Arriving Summer 2015 Extract: Let’s Encrypt is a new free certificate authority, built on a foundation of cooperation and openness, that lets everyone be up and running with basic server certificates for their domains through a simple one-click process. Mozilla Corporation, Cisco Systems, Inc., Akamai Technologies, Electronic Frontier Foundation, IdenTrust, Inc., and researchers at the University of Michigan are working through the Internet Security Research Group (“ISRG”), a California public benefit corporation, to deliver this much-needed infrastructure in Q2 2015. The ISRG welcomes other organizations dedicated to the same ideal of ubiquitous, open Internet security.

I prefer to do it this way: this, another, that & those $out = ''; $count = count($update->client_location); foreach ($update->client_location as $key => $geo) { $div = ($key + 1 === $count) ? ($count === 1 ? '' : ' & ') : ($key === 0 ? '' : ', '); $out .= $div . $geo->title; } echo $out;

The site I have just uploaded today, http://claysvehiclerepairs.uk is the first site I have done where the pressure was on to speed it up. The site has a lot of graphics, it uses foundation which is far from lightweight, it has 890 or so pages (it has left Pete's sitemap module smouldering), various extra bits of JQuery going on like equal heights and is just big and weighty. I managed to get it running fine, actually, and then I added AIOM and the site shook itself into a higher gear - very pleased indeed. So Thanks to everyone involved with AIOM. Then I gassed up procache, pulled the choke out and hit the start button. The full roar of the ProCache 289 V8 with Holly double pumpers, slot change box and overcharger, thundered into action and the website just about catapulted itself out of the traps and round the internet track at lightning speed. The difference was seriously noticeable. And the result? Page analysis says - &*$£king fast. Mobile analysis says fast too, which considering what is going on is very pleasing. So Thanks to to Ryan for making a CMS that is a joy to optimise with no secret stashes of rubbish to drag you to your needs and for a module that adds rocket fuel to the finished item. Gertcha my son!

kixie is right. Sorry, just to correct mine it would be index 2, because 1 is root parent and 0 would be root (home). $bar = $page->parents->eq(2); Just to summarize if called from the children // works $parent = $page->parent("parent=$page->rootParent"); // works and same as $parent = $page->parent("parent=1001"); // where 1001 would be /foo/ // works $parent = $page->parents->eq(2); $parent = $page->parents("parent=$page->rootParent")->first; // even works when on the parent itself $parent = $page->closest("parent=$page->rootParent");

Yep, I agree with Joss here. If you wanted to manipulate the value at runtime, here's an example based on Joss PHP date thingy... $myDate = date('F Y', $pages->get(5108)->getUnformatted('blog_date')); echo $myDate; //Outputs August 2014, for example.

Note to myself: Stop reinvent the wheel. I ended up just using standart code translation. If someone wants to translate it, he / she should know how to do it, without these extra module settings. class AddressGerman extends WireData { protected $titleOutput; … public function __construct(Page $page) { $this->titleOutput = array( 0 => $this->_('No title provided'), 1 => $this->_('Sir'), 2 => $this->_('Madam') ); …

Lots of ressources (links, articles, downloads) on this beautiful page: http://www.perf.rocks

@Jan Romero $page->parents("parent=$foo") //or $page->parentsUntil("parent=$foo") will return a pageArray. $page->closest("parent=$foo") will include foo too. $page->parent("parent=$foo") yes thats the best solution. Never used this as a method. Thanks! @matjazp You should use Jan Romeros Solution like: $page->parent("parent=/foo/") // searching for the name of parent $page->parent("parent=1022") // searching for the id of parent

By the way, there is also closest($foo) and parentsUntil($foo).

I have been seeing slower and slower response times on Processwire and Drupal sites on my local Xampp server for a while now. Just spent a couple of hours searching for some hints/fixes. Thought I would share this here as the answer I found that worked for me was reported on Wampp as well and using Joomla and Wordpress so seems to be across the board. I am running Windows 8.1 64bit. That seems to be where the issue stems, and has to do with a bug in that operating system with how they handle IPV6 first then fallback to IPV4. The way this manifests is frequent calls to the database being repeated, increasing server response times. So the fix is as follows. In phpMyAdmin\config.inc.php change $cfg['Servers'][$i]['host'] = 'localhost'; to $cfg['Servers'][$i]['host'] = '127.0.0.1'; This one I did not actually need as Xampp had that already, but according to the thread I found Mampp did need it. Next uncomment bind-address="127.0.0.1" in mysql\bin\my.ini And finally the real culprit, in Processwire site\config.php change the database configuration from $config->dbHost = 'localhost'; to $config->dbHost = '127.0.0.1'; This same applies for any CMS config file that connects to a MySQL database. (Maybe even any other database too as the issue is with OS) And hey, WOW!! my local dev sites are running way faster now. Hope all that is clear, and useful if anyone else is seeing slow response times locally. Just in case here is my current setup details. Windows Version: Windows 8 Enterprise 64-bit XAMPP Version: 1.8.3 Apache/2.4.7 (Win32) OpenSSL/1.0.1e PHP/5.5.9 MySQL Community Server (GPL) 5.6.16 libmysql - mysqlnd 5.0.11-dev phpMyAdmin Version information: 4.1.6

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

Hi Guys, I've decided to share my work on a Fieldtype for adding star ratings to page items. I used @apeisa's FieldtypePoll as a starting point. Check out the readme on github for usage: https://github.com/jdart/FieldTypeRate I've got a couple screenshots that should demonstrate the functionality. Feel free to give me any feedback. Regards, Jonathan

Not our first ProcessWire powered website, but definately our most interesting one so far: http://www.rabotheater.nl At Itix we build and maintain online ticketing software for theatres and cinema's. About 30 theatres across the Netherlands are powered by Itix. Our software has some form of integrated content mangement, but this "CMS" does not live up to current standards and client wishes anymore. We decided to move all frontend related content to a PW environment. Eventhough most data still exists within Itix, all website-specific enrichment is done within ProcessWire. PW gets it's data through export/imports (for complete datasets) and a method of triggering events, filling a jobqueue and updating specific single items. Rabotheater is our first client moving to a PW powered website, but I'm confident many will follow. http://www.rabotheater.nl

You can also PW API since 2.4 or 2.5 echo $page->blog_tags->implode(", ", "title");

Also worth reading: http://en.wikipedia.org/wiki/SPDY http://en.wikipedia.org/wiki/HTTP/2 This is where we are going, and if not for anything else, at least for performance reasons you should adopt this as early as possible.

Ah, filling in ..... Martijn, the more I look at your solution, the cleverer it gets It is also one of those that I would put a big comment above because when I look at it again in a year's time I would be thinking, "Now, what the hell was I trying to do there?"

I'll stay with ST though the slow development pace is a shame.

I've only just switched to PHPStorm from DreamWeaver - I don't think I could handle more than one change a decade

I guess I'm planning on changing the output format depending on the template. Therefore, starting off with the most detailed info and whittling it down to just Month Year would be best so I'll run with something like this $customdate= date("M Y", $update->getUnformatted("blog_date")); Cheers Joss. Cheers @Kongondo. Looks like we posted at the same time again

Wellllllllllllll Kind of depends what you want to do! If you want the output of that specific field to look the same every time for consistency, then do it at the field end. if you want to change it (sometimes have only a bit, sometimes display as a shorter format), then just output it unformatted and use the php date thingy to do what you want. http://cheatsheet.processwire.com/page/built-in-methods-reference/page-getunformatted-field/

Why do you think the conversation wouldn't be seen? Module developers follow the support forums of their modules and are notified of new posts If we were to open new topics just because some threads were 'long' things could become chaotic and confusing very quickly. This forum is Hanna Code's support forum. You have raised a Hanna Code support question hence it should be here . To further clarify...(not just for you): Each module has (should have) its own support forum. these are found here: https://processwire.com/talk/forum/4-modulesplugins/ If one wants to discuss general module development they should post them in this sub-forum: https://processwire.com/talk/forum/19-moduleplugin-development/ I hope these clarify things.

//doesn't work should work if called in a child page //works even if called from the page you are looking for

The old system just got this great feature implemented and around comes a new system

I will get him to add a bit about servicing snowmobiles immediately!

Ok, finally fixed it. I realised the second foreach loop needed to be way down the code. Once I figured out my list of brackets, semi-colons, quotation marks etc etc it worked Here's my code <?php $updates = $pages->find("template=blog-post, blog_tags=Studio Watch");//Get blog posts tagged Studio Watch echo"<section id=\"cd-timeline\" class=\"cd-container\">"; foreach ($updates as $update) { echo"<div class=\"cd-timeline-block\"> <div class=\"cd-timeline-img\"> <img src=\"img/cd-icon-picture.svg\" alt=\"Picture\"> </div> <div class=\"cd-timeline-content\"> <p>{$update->title}</p>";{ echo "<i class=\"fa fa-tags\"></i>"; foreach ($update->blog_tags as $t) { echo "{$t->title}"; } echo"<span class=\"cd-date\">Jan 14</span></div></div>" ;} } echo"</section>"; ?>

I use $p = $page->parents->eq(1);

genious! and $page->closest("parent={$page->rootParent}") will work in bar1 and bar2 too. If you are using the same template. PW API is a creative one.

That shouldn’t happen, actually. Does it do that on your site?! It’s supposed to return the parent closest to Home, as matjazp said. I mean, what would be the point of just returning Home for every single page on the site

Try $page->parent("parent=$foo") edit: parent, not parents.

You can make a master / slave configuration with continuous syncing from one to another. For this to work you would have to make sure that admin traffic is only routed to one ("master") server. You could use rsync (which could be triggered by a module after onPageSave), the more "true" way as far as I understood is block level syncing. I don't know anything about this however. Alternatively, you could for example mount one server's /assets/ folder into the other one. This makes sure you always read / write to the same dir. In this case, you should make sure in your application logic that the same information cannot be stored at the same time from different servers. You could also combine these two options.

Ivan - take a look at the latest version for me - let me know if that works how you expect. It should work exactly as you requested.

@DaveP it looks like that solved it. I changed this setting and it seems to be working so far. I am not 100% sure from the user's standpoint, but since my user's are verified authors. I think it will be okay to leave this off @Ben I will look into this as well if @DaveP's fix doesn't seem to be it.

Translation: Cover = Any pub building with a bar roof and alcohol doors. There is a bit of me that would like a mac, but there is another bit of me that does not want another learning curve! There is a third bit of me that has just run and hid my credit card.

Dear Nik, That did the trick! Thanks! I think my stumbling block is that I've come from the Perl / PHP procedural method of coding, and I've not taken adequate time to truly digest the PHP OOP model. So, I run into knowledge gaps with things like objects, etc. Learning OOP PHP is on my todo list. I'm not using the admin interface to run this app -- at least not the part above. So, I'll be including code to update the account_id field in the domain_ip data record, after someone selects and saves a selected IP. By the way, I saw a note from Soma about PW v2.3 being buggy and needing this code in the above custom PHP field: $p = $pages->get($_GET['id']); But... with your code above, I don't seem to need that. Do have any thoughts on that? Thanks again!! Peter

Which is why I said you should use an equal heights system above. That way, they are neat, fit properly and you are not constrained by how much text you use. You could also look at a solution that Pocketgrid uses that might work with bootstrap http://arnaudleray.github.io/pocketgrid/examples/fix-for-different-block-heights-nthchild.html Edit: the advantage of using equal heights, by the way, is if you have borders or background in your blocks, then with equal heights everything lines up.

Pocketgrid is one. And any that work on a block method rather than a strict row method You will like how complicated the code is in the css

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

It depends on the exact needs but most of the time i use like this: http://modules.processwire.com/modules/batch-child-editor/ http://modules.processwire.com/modules/process-batcher/ http://modules.processwire.com/modules/process-page-field-select-creator/ http://modules.processwire.com/modules/import-pages-csv/ Not seldom i use them all in a project. They really go quite far as 'bulk' actions are concerned. I quite like the fact that it's not all bundled into the core features.

There's also the chance that you could simply create these as child pages of a page. At the beginning it may sound strange to do it that way, but It's actually the cleanest way and makes everything very clear to you and to the client. Plus, if you set the template of these pages to admit only one parent, you will automatically have a quick button in the admin to create these pages.

Another processwire relaunch made by neuwaerts: The Website of the Shopping Mall "Galerie Luise" which is located in the center of Hannover, Germany. The mall was recently bought by one of our customers, accom (whose [interims]website is also powered by processwire and launched some weeks ago) and needed some refreshment in terms of design, marketing and strategy. As a result we've created a slightly adjusted logo, a new claim, new print materials and a shiny new websites which mainly features upcoming events held in the galerie luise. http://www.galerie-luise.de/

I'm pretty sure MarkupSEO is causing issues when viewing form results generated by FormBuilder. I posted the issue in the Form Builder Support but in case anyone isn't a member (VIP forum), here's the details. Error on viewing FormBuilder entries Error: Exception: Unknown Selector operator: '' -- was your selector value properly escaped? (in /home/sites/pretendy-url.com/public_html/wire/core/Selectors.php line 247) #0 /home/sites/pretendy-url.com/public_html/wire/core/Selectors.php(284): Selectors->create('1.2', '', '') #1 /home/sites/pretendy-url.com/public_html/wire/core/Selectors.php(81): Selectors->extractString('1.2') #2 /home/sites/pretendy-url.com/public_html/wire/core/Pages.php(165): Selectors->__construct('1.2') #3 [internal function]: Pages->___find('1.2', Array) #4 /home/sites/pretendy-url.com/public_html/wire/core/Wire.php(389): call_user_func_array(Array, Array) #5 /home/sites/pretendy-url.com/public_html/wire/core/Wire.php(344): Wire->runHooks('find', Array) #6 /home/sites/pretendy-url.com/public_html/wire/core/Pages.php(260): Wire->__call('find', Array) #7 /home/sites/pretendy-url.com/public_html/wire/core/Pages.php(260): Pages->find('1.2', Array) #8 /home/sites/pretend This error message was shown because you are logged in as a Superuser. Error has been logged. Ryan's suggestion Uninstalling MarkupSEO makes the FB entries viewable again.

ProcessWire IS successful. I've not read all but think it's all kinda way off to what PW is in its philosophy and core. Sorry, but I usually am too lazy to read more than 2-3 paragraphs. You need to work on your end-user usability (me reading your post, or not).

Out of interest, do you have any details on the Bing and Yahoo parts? Google is obvious, but as far as I can tell, Bing and Yahoo still use keywords, though they're not exactly important ranking factors (quite the opposite, really -- they seem to have much less weight than regular body copy). Also, for anyone targeting the Russian or Chinese markets, it should be noted that Yandex specifically suggests using meta keywords (they're not revealing how important these are as ranking factors though) and according to some sources Baidu considers meta keywords "very important" (though keyword stuffing is a major negative signal there too).

Hi everyone, I'd like to announce a complete overhaul of this module - problem is that I am not sure whether to release it as an update to this module, or perhaps as something completely new, perhaps called PageProtector. UPDATE: The functionality described in this post is available as a separate module: PageProtector This new version (not on github just yet) makes it very easy for site editors to set up various password protected areas on their site, or to simply protect a new page or section while they are still working on it. New functionality Ability for your site editors to control the user access to pages directly from Settings tab of each page Includes whether to protect all children of this page or not Optionally allows access to only specified roles Ability to change the message on the login page to make it specific to this page Option to have login form and prohibited message injected into a custom template Access to the above "Protect this Page" settings panel is controlled by the "page-edit-protected" permission Table in the module config settings that lists the details all of the protected pages Shortcut to protect entire site with one click What do you all think - replace the existing module, or release this functionality as a separate version? Module Config Settings Page Protection Settings

I am working with a designer who's experience lies mostly in print. So, I have written a document explaining the fundamentals of modern adaptive web development. This is not a technical manual, but rather looking at what needs to be considered by the creative designer when coming up with something that a developer can deal with well. Since we have a good assortment of multi-disciplined souls here, would a few of you care to read it and suggest anything I perhaps should add, without making it heavier or much longer? Some of you may find this useful for your own purposes too and you are very welcome to use it. UPDATE I have done a new draft, removing the adaptive idea which kind of got lost as I wrote - the trials of writing an essay off the top of my head with no planning whatsoever! Silly me. It is now called Responsive Websites UPDATE 2 Cleaned up version - the chat about flat icons is now shoved at the end as an after thought Responsive Websites 2.pdf

Our clients have reported identical problems a few times. After clearing browser history things have returned to normal. This is probably unrelated, just wanted to point out that the issue may not be site-related at all..

Now you can have some more fun converting everything to wiki, and putting it '''[http://wiki.processwire.com/ here]'''

The best way is to avoid having PW in subfolder and on root on production. Search replace the sql dump is maybe most simple. And there's also this module http://processwire.com/talk/topic/236-module-page-link-abstractor/