Leaderboard

ProcessWire Online Installer Since there's now a shortcut to download latest stable PW http://grab.pw , I created a simple helper PHP script you can upload to your server to download and extract a new PW installation. Upload this php file to the server where you want to install latest ProcessWire Go to the browser and call this script. It will download and extract ProcessWire files. Once done successfully it will redirect to the installer. Downloaded zip the grabpw.php will be removed. If anything fails, make sure permission are correct on server and you remove files manually in case. I tested this on my local XAMPP (Mac) install and on some of my account on a ISP. Also I took some methods to download and extract files from my ModulesManager which seems to be "reliable" so far. Download The script can be found on github: https://github.com/somatonic/PWOnlineInstaller Why Just because it's cool. There's many ways to accomplish this task if you have ssh access for example using shell. Just wanted to have this alternative and maybe people find this useful too. @ryan. Do you think you could provide an latest dev shortcut url too?

... and assuming that you don't / can't add all image field names in your code, something like this should also work: $allImages = array(); foreach ($fields->find("type=FieldtypeImage") as $f) { foreach ($pages->find("$f.count>0") as $p) { foreach ($p->$f as $i) $allImages[] = $i; } }

book ams.i writng also good for all in.deph and comperhansive.topkicks for.it begnner and.master pw user

I think that purely because it varies so wildly from individuals up to agencies, plus how complex the job is (a forum setup in one software is easier than another, similar with styling) you might have a hard time getting responses to this manviny. In my experience, no two jobs are ever the same, even if someone wants the same as a previous client

echo wireRelativeTimeStr($page->date_field);

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/

you.will find only what you bring in

I'm not totally sure but it seems that you can read the dBase file directly with PHP, so you will be able to read the records from the file and use the API to import them. http://php.net/manual/en/ref.dbase.php EDIT: here is a guy who has converted dBase to CSV: http://www.dev-zero.de/php/mit-php-dbase-zu-csv-konvertieren.html He uses a dbase class from another guy: http://www.dev-zero.de/downloads/dbf_class.php and the code to do the convert is short: <?php include("dbf_class.php"); // include the class $dbaseDB = ‘DB.dbf’; $dbf = new dbf_class($dbaseDB); // open the dBase file $csvFile = ‘file.csv’; // create a CSV file $csv = fopen($csvFile,"w"); // get record count, loop through and convert to csv $num_rec=$dbf->dbf_num_rec; fputcsv($csv, array_keys($dbf->getRowAssoc(0))); for($i=0; $i<$num_rec; $i++) { fputcsv($csv, $dbf->getRow($i)); } fclose($csv); // ready! now use Ryans CSV-Importer But want to note that I only have googled that and have not tested / used this by myself, so- no warranties ;-)

by.per hour web developmant 14,692.50 jmd or $150 usd or 3.5 oz kb

Well, managed VPS is one option. There you can ask hosting company to configure the server for you. Servint (their vps: http://www.servint.net/vps.php) seems to be great choice and also what Ryan & ProcessWire recommends: http://processwire.com/servint/.

// assuming your images field is named "images": $pagesWithImages = $pages->find("images.count>0"); // now that you have all pages with images, you can put them all in 1 array if you want $allImages = array(); foreach($pagesWithImages as $p) { foreach($p->images as $image) $allImages[] = $image; }

Found little typo in main.js Here is the pull-request https://github.com/somatonic/ProcessWireCheatsheet/pull/1

Local Audio Files - MP3-DB The Local Audio Files DB is a combination of a Module and a SiteProfile. It is intended to import MP3-files from your filesystem into ProcessWire, read ID3-Tags and pull coverImages from it to feed the DB. It is thought as a starting point for your own site creation. A sort of comfortable aggregated reuseable code for PW-lovers. How to Install Grab a copy of the latest ProcessWire. Replace the install, modules and templates directories with those in this profile, as shown below: /site-default/install/ /site-default/modules/ /site-default/templates/ With SiteProfile-Installs normally that is all there is to do. With this Profile you also have to copy the file LocalAudioFilesImportShellScript.php (for simplicity) to your PW-rootfolder, (where the index.php reside). If you are on Windows you also should copy mp3_import_starter4win.cmd to the same location. Now install ProcessWire as per the instructions included with it and it will install the LocalAudioFiles profile automatically. After that you find a Quickstart Guide at the homepage of the profile: Follow the 3 steps and you are done! How does it work? The Site has 4 sibling Tree Branches: genres - artists - albums - songs. Each of them hold child-pages: genre - artist - album - song. The logical relations are nested parent-children ones: a genre hold artists, each artist hold albums, each album hold songs. To support both, slim and fast data relations & the logical hirarchy, the module extends the ProcessWire variable $page with some additions. It uses the addHookProperty mechanism to achieve that. It uses an own caching mechanism for large lists, that can be prebuild when running the importer-shellscript, or it build the cache on demand. Also it comes with a FrontEndHandler class that provides a lot of functionality, for example fully customizable FormSelectFields of all genres, artists or albums. More detailed informations and code examples are collected in a demo section of the site. The extended $page variable together with the LocalAudioFiles-FrontEndHandler gives you comprehensive tools to work with your music collection. Download Modules Directory LocalAudioFiles-SiteProfile_v0.1.5.zip LiveDemo I have uploaded a small LiveDemo with only 7 truncated songs. But it's pretty fine to view all Demos and the additional $page->proterties. demo song page demo album page demo artist page demo genre page Graphical overview Screencast of installation https://youtu.be/-qYyppvEF1k History of origins http://processwire.com/talk/topic/3322-how-to-setup-relations-for-a-mp3-db-with-pw/ http://processwire.com/talk/topic/3462-pages-get-return-nullpage-but-page-exists/

Words of encouragement from the Pub's amateur psychiatrist (Read best in a soft spoken, German accent) Ah, you are here because you have been reading things in this forum about pages that have left you confused, disorientated, befuddled. You thought you knew what a page was - you have been thumbing through them, folding them, studying them, wrapping things up in them and scrolling up and down them for most of your life! A page is this solid item - this great lump of data stuffed with things. But now you have come to Processwire, and everything you thought was true, simply isn't any more. For in Processwire pages are completely different - they are not great gulps of information, but tiny little things, nothing more than a link to the more interesting world of fields and templates; just a little blip of data in your huge fascinating database. Pages in Processwire are used for all kinds of things. They can be used as a marker in your pages list. They can be used as a group parent for other pages. They can be used as categories, tags or lists or users. And they can even be used for simple drop-down selects - just to supply a label and value. It can seem crazy to use such an iconic thing like a page for such a mundane and trivial task! But don't worry and fret, don't lose sleep or pace the floor as you think the reputation of the noble page is being crushed! In Processwire, they are fulfilling their duty to the full - and the more slight the task, the more they bound up to the wall and jump up and down shouting "use me, use me!" And, as a bonus, they can even be used for content - for all that stuff you thought was a page, but in Processwire isn't! So, don't be put off by the Processwire page - use it for everything! it is much smaller than you think, takes up hardly any space at all, is well behaved and only will do its thing when it is called. In fact it is hardly a page at all .... and then again, it is also so much more!! Better now? Joss Freud

I'm new here so have been reading a lot of forum posts and doing small experiments. This is about figuring out flexible ways of working with the PW's ways of delivering content. Sometimes having the PW template file echo out stuff from $page is just right but I wanted to figure out an approach that starts with that and adds complexity as needed. So, here I'll show you the parts of my first working test with MVC, recursive rendering of child pages and a template engine. The PW template file is used as a simple controller to delegate rendering to a view. //By default we'll use PW's template as the view name. $name = $page->template->name; //Load the view file require_once '../iop/views/'.$name.'.php'; //Create the view object $view = new $name($options); //<-- options passed to template are passed to view //Hook it into the PW template object $this->addHook('Page::renderView', $view, 'renderView'); //After page does "renderView" output will be in $view->output $page->renderView(); //spew it out echo $view->output; Learned the hook from http://processwire.com/talk/topic/1510-templatedisplay-mode/ The view file: /* this is a view file: $options passed to template are passed to view $options['params'] would be parameters to use in rendering, such as a different template for rendering as child to another page */ require_once $config->paths->root.'/supp/StampTE.php'; class sb3d_mvc_test { var $templateName = null; var $output = null; var $kidOutput = null; var $options = null; var $depth = null; public function __construct($options = null){ $this->options = $options; $this->templateName = get_class($this); //default is to use same name for all the major parts. No extension. $this->depth = count($this->options['pageStack']); } //Prepares data for the template public function prepare($page){ $msg = 'The '.$page->name.' page.'; if(!empty($this->depth)) $msg .= ' The pageStack count = '.$this->depth; return array('msg'=>$msg); } //Renders child pages public function renderKids($page, $params){ $kids = $page->children; if(!empty($kids)){ $this->kidOutput = array(); foreach($kids as $kid){ $this->kidOutput[] = $kid->render(array('params' => $params)); } } } //This view makes use of the StampTE template engine and makes some content from child pages public function renderView(HookEvent $event) { $page = $event->object; $data = $this->prepare($page); //Limit how far down rendering goes and set parameters for child page. Maybe use callbacks? if($this->depth==0){ //not rendering as a child page $raw = file_get_contents('../iop/templates/'.$this->templateName.'.html'); $params = array('renderMode'=>'Sub'); //child pages use this as template name suffix $this->renderKids($page, $params); } else{ //rendering as a child page $raw = file_get_contents('../iop/templates/'.$this->templateName.$this->options['params']['renderMode'].'.html'); } //Now we play with the template engine. This one's interesting in the way it does cut and paste within a template // We could instead leave stuff in $this->output and let the PW template (our controller) build output with PHP/HTML $t = new StampTE($raw); $t->inject('title', $page->title); $t->inject('msg', $data['msg']); if(!empty($this->kidOutput)){ $kidLayout = $t->get('kid'); //extract little subtemplate ('cut') to use for each message foreach($this->kidOutput as $stuff){ $b = $kidLayout->copy(); //each message is put in a copy of subtemplate $b->injectRaw('kidstuff',$stuff); $t->selfkid->add($b); //completed subtemplate is pasted into master template } } $this->output = $t->getString(); } }//class In this case we use StampTE to render the page with the sb3d_mvc_test.html and render the child pages with sb3d_mvc_testSub.html. It's setup to only render child pages from the top level but we could recurse more deeply (not tested) if there was a need to. More could be done. So far so good. The render hook and the $options used by $page->render are key parts. Lot's more to say/ask about PW but I'll dribble it out in future posts. Thanks.

It's very cool Edit: working perfectly on my localhost. And it even took care of changing the htaccess file name for me!

Yo Willy, Can you also write a book how to grow and style a beard like yours?

I want a hardcover copy!

I guess the pain point for most is that while they are editing text and need for image occur, they click "Image" button on editor (tiny or ckeditor). Then there is no way to upload images in that view. Also that view could have nice little image grid instead of full size photos (this: http://processwire.com/talk/topic/635-thumbnails-of-images-in-tinymce/). Overall I think PW has nailed images & text pretty nicely and in a flexible way. The more you mix the two (images and text), the more mess you have in any scenario (harder to reuse the content on different contexts etc). I try to make nice default image placements (with few variants if needed) and really having to use RTE image placement should be the last resort. For some sites, of course that is impossible or inconvenient.

I don't actually have any experience with IIS, and have only rarely come across it over the years. As a result, I'm not sure how to provide support for it, and that's why I've always kept Apache as a requirement for PW. But I know there are others here successfully running PW under IIS, so it certainly seems possible. The biggest issues will likely be centered around the .htaccess file. If there is something that makes IIS understand an Apache .htaccess file (including especially rewrite rules), that would be desirable for sure. I don't think this could be an IIS-specific issue. Double check that you've installed the new admin theme in /site/templates-admin/ and that it is fully readable by IIS. This also doesn't sound like an IIS-specific issue. Instead, it sounds like the pages might not be set for manual sorting. Either that, or a potential browser issue. What browser/version are you using?

I really prefer to keep images in their own fields, separate from a textarea/TinyMCE field. It's not about any limitations at all. I've just found this to be the most flexible way of managing this over a long period of time. ProcessWire has always been built to what was ultimately most flexible rather than trying to do the same thing as other CMSs. But I do recognize that it's controversial and may seem unfamiliar if one is already used to a different way. I'm not against alternative patterns for this if it helps appeal to more coming from other CMSs, though not at the expense of the current one which I think is the ideal (at least for my needs). So I always try and keep an open mind about it and am open to supporting more options for those that want them in the future.

Thanks k07n, I have applied that update.

It's all about not giving web server (in Ubuntu systems most commonly user "www-data") write access to anything it doesn't strictly speaking need it to. Web server is in direct interaction with outside world and can be tricked to do things on behalf of malicious users. This can be partly avoided simply by not letting it do any more harm locally than is absolutely necessary. Thus it's a good thing that it doesn't have that access by default. If it had (ie. you didn't need to set it during install or right after downloading / cloning install package), I'd be very worried, 'cause that would mean that your web server has full write access not only to /site-default/ but also the directory containing it (and who knows what else.) Obviously locally things are a bit different

Hi roelof, Before you start you should also install ProcessWire and do some stuff with it, e.g. try things out: Create some templates / pages. Try to understand how selectors work. Then you can easily answer the questions yourself. Nevertheless, try to give you some guidance: 1) In home template: $articleBody = $pages->get(ID_FROM_ARTICLE)->body; 2) Not sure here, normaly one page = one article, so assign a body field to the template of that page? 3) Add an 'image Field' to the template. Images uploaded to a page can then also be inserted into richtext. 4) I'd export them from the old database and create a csv file. Then you can use this module from ryan to import them into Pw. Cheers

Symbolic links are roughly the equivalent of shortcuts in Windows environment, if that's what you're more familiar with. They're just pointers to some other location. Having /wire/ as a symlink pointing to another location means that anything you change in that other place is instantly in use anywhere it's linked. This is most likely the easiest way to use one PW core (which, I believe, is what you're trying to achieve here) with multiple directories.. or sharing it with multiple sites in general Creating a symlink is as simple as doing this in your site1 / site2 directory: ln -s /var/www/your/primary/pw/installations/wire wire You'll still need to keep some files (in addition to a /site/ directory) in each subdirectory; most importantly .htaccess and index.php.. though I guess you could make those links to somewhere else too if it really matters.

I have successful hooked new properties to the existing pages (parents: genre|artist|album) and (children: artists|albums|songs), and some more. With the demos I have made some progress, and I have made a graphical overview: Edit: new Mindmap

This is a matter of view, really; textareas hold regular text (even if it's markup) and image / file fields hold images / files (binary data.) It's about separating content by type, even if not necessarily by purpose. Another important thing to note here is that an image isn't limited to one textarea. Current implementation allows one image to be used with as many other fields as necessary -- or none at all if that's preferred. Disagreed. In the context of web content images are never _really_ inline, they're separate entities loosely tied to content (markup) with <img> tags. In some other environments this might make more sense, but not here You're confusing "limitations" with "decisions" here. As always there's more than one way to do it and not doing it "the way most CMS work" doesn't mean it's somehow faulty. Not 100% sure if that's really what you meant here, though that's the message I'm getting. Regarding an actual solution, I'd suggest taking a look at Soma's image manager and perhaps extending on that. I'm certain that contributions would be very much welcome. If it's tags that are bugging you, perhaps this could be tied more strictly with TinyMCE / CKEditor image plugin or something like that? (Sorry, I'm not exactly familiar with this module, so I can't say if that's already something it does.) Edit: after some Googling justboil.me and couple of it's alternatives (TinyMCE image / file upload plugins) popped up. PlugoBrowser seems very nice too, though not free.. but if it's client work you're going to use this for, $20 price tag shouldn't make much of a difference. Perhaps it would make more sense in this case to integrate one of these locally, possibly coupled with a custom plugin / view for selecting images from that location -- unless that plugin already comes with these features, that is. Some plugins for sure do, I even remember using something like that in the past. (Umm.. iBrowser?) Not sure if TinyMCE within PW allows custom modules, but I believe there was an option for it.. haven't really had that need myself

Codemagic is even in the core tinymce plugins in PW. Just have to add it in the field configuration. It even has hightlighting and search replace and autocomplete.

Hi Alessio, good idea! I'm pretty new to processwire (discovered one week ago...still dealing with the default templates) but an italian community would be great! I come from Expression Engine, and I really begin to appreciate the possibilities with this cms. ciao! Marco

renobird, Thanks, I wasn't really expecting such a compreehensive reply. It really helped me to understand the relationship between the pages, templates and url segments. Really put me into the right path. Again, brilliant piece of software, great community. Exciting.

Just build a select form with your section pages in it and send the page id over GET: <select name="section"> <?php foreach($pages->find('template=section') as $s) { echo "<option value='{$s->id}'>{$s->title}</option>"; } ?> </select> Then in the template where you display the events, check if the user has chosen a category if ($input->get->section) { $section = (int) $input->get->section; // Add this to your selector string $selector .= ", section={$section}"; // To make the pagination work, add the section get variable to the whitelist $input->whitelist('section', $section); }

Are you gone crazy? And even with colors!

I think this method will work even if you expand it out. I changed a few things up, but hopefully it makes sense. Product pages use "template product", all other catalog pages use "template catalog". Catalogue -- Men ---- Shoes ------ Product 1 ------ Product 2 ---- Hats ------ Product 1 ------ Product 2 -- Women ---- Shoes ------ Product 1 ------ Product 2 ---- Hats ------ Product 1 ------ Product 2 Categories (these pages only a template with a title field) -- Brands ---- Brand 1 (title only template) ---- Brand 2 (title only template) -- Type ---- Type A (title only template) ---- Type B (title only template) -- Collections ---- Collection A (title only template) ---- Collection B (title only template) catalogue.php template & product.php template (same contents) <?php /* There might be a better way to accomplish this. The only reason to have 2 templates is to give find() a way * to only return the actual product pages, and not all the parent pages as well. * * update: You may want to look into using the alternative template method: * * * With this approach you would create a real file (product.php) for the product template, * catalogue template would have no file associated, but point to product.php under the advanced settings tab. */ include("./site/templates/head.inc"); include("./site/templates/product-view.inc"); include("./site/templates/foot.inc"); product-view.inc <?php $brand = ""; $type = ""; $collection = ""; if ($input->urlSegment1) $brand = ",brand.name=".$input->urlSegment1; if ($input->urlSegment2) $type = ",type.name=".$input->urlSegment2; if ($input->urlSegment3) $collection = ",collection.name=".$input->urlSegment3; if ($input->urlSegment4) { // if Segment 4, then we know what page to get $product = $pages->get("name=$input->urlSegment4"); echo $product->title; } else if ($input->urlSegment1){ // check if we are using URL segments if ($input->urlSegment1 == "all"){ $products = $pages->find("has_parent=$input->urlSegment2, template=product"); } else { $products = $pages->find("has_parent=$page->path, template=product, . $brand . $type . $collection"); } foreach ($products as $p){ echo $p->title; } } else { $products = $pages->find("has_parent=$page->path, template=product"); foreach ($products as $p){ echo $p->title; } } Looking at example URLS to see how the selector would get populated: /catalogue/brand1/ Brand1 is a url->segment1 so the elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1"); /catalogue/brand1/casual/ elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1, type.name=casual"); /catalogue/brand1/casual/trendy/ $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1, type.name=casual, collection.name=trendy"); /catalogue/men/ $products = $pages->find("has_parent=men, template=product"); /catalogue/all/shoes/ $products = $pages->find("has_parent=shoes, template=product"); /catalogue/all/hats/ $products = $pages->find("has_parent=hats, template=product"); /catalogue/men/shoes/ no URL segment here, so the if/elseif are false, so we get: $products = $pages->find("has_parent=/catalogue/men/shoes/, template=product"); /catalogue/men/shoes/brand1/ Brand1 is a url->segment1 so the elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/men/shoes/, template=product, brand.name=brand1"); you get the idea. Again, untested and coded in the browser — but hopefully thought out enough to get you started.

@Diogo, I haven't had time to test the second version. Will do so sometime. Meanwhile, I have been busy playing with the module and here's a taster...a CRUD system for: a db external to PW (see video) PW pages (attached screenshots) Just fooling around at the moment. It is WIP as I learn the ropes of PW. In these examples I am using jTables. Will soon switch this to the great DataTables. Soma has a module of this one in the forums. Here I show how easy it is to implement using your module Many thanks for your awesome module!