Leaderboard

PW Images Manager (beta) Just a weird little screencast trying to show how it works. (out of date a little, tags now use a textfield for easy copy/paste) This module allows you to manage images from one central repository. You create a root page "/images/" where you can then add categories and images as pages. From there the new admin page created "ImagesManager" will show categories and images added in a ajax data table, from where you can see and search/filter all images, upload and create new categories and edit images too. Every image will also show an image tag generated to copy into a textarea. This tag looks like this: {image=/path/to/image/imagename/, width=200}The width=100 is the thumbnail size used to output the image.You can also have additional segment to contain classes: {image=/path/to/image/imagename/, width=100, class=align_left}Or you can enter the id directly: {image=1033, width=100}Once inserted into a textarea field it will get parsed when saved and loaded automaticly. It will store an abstract id tag in Database and convert it back to the image HTML tag. So after first save you'll see the image inserted in a Wysiwyg and be able to resize and place it as usual. Once it's inserted somewhere Images Manager will show a search link with the pages containing the image (you can configure the fields int the module setting). You can change the image or move it to a different category, it will still work and show the correct image. This also works with multi-language fields.You can still also use the regular insert image dialog in TinyMCE and chose image from those pages. And it will start keeping track of those as well (they're the same after all). You can use those central images pages also with page fields to reference them single or even whole categories, search them with API and do what you like. Images Manager will also parse the page render on front-end and replace any found image tags with the HTML code. It will also look for a description on the image and output it as alt tag. If you want to have multi-language description you can add a `image_description` TextLanguage field to the image page template and have images parser use them. Along with this module, you can also install the `PageListImageLabel` module to add thumbnails to the image pages in the tree. To get it working you need to have the basic setup: 1. Create new `image` field with input setting to 1 max image 2. Create new `image` template and add `title` and the `image` field created before 3. Create a 'image-category' template with only title and allow the `image` template and `image-category` as child pages under family settings. 4. Create a `image-root` template with only the title field for the root of the images tree. Allow only `image-category` as child page under family settings. 5. Create the root page with the `image-root` under the home page as "/images/" 6. Done. The structure of the image repository looks like this /images/ /cagetory1/ /imagesxy/ /category2/ /image2/ /image3/ Now you can use the ImagesManager to add categories and images. But you can also still use the page tree to add new stuff as usual. The root path, template names and fields are configurable in the module settings. How to install the module: - Download the contents of this repository and put the folder renamed as "ImagesManager" into your site/modules/ folder - Login in to ProcessWire and got to Modules page and click "Check for new modules". You should see a note that the two new module were found. Install the "ImagesManager" module. - A new admin page "ImagesManager" should appear in the top menu. - You may configure the option on the module screen to suit your needs. Download at github https://github.com/somatonic/ImagesManager Thanks and enjoy.

I would say that the blog profile is not the best place to start. It uses more advanced techniques and was designed to be a demonstration of them– These are techniques I don't even use in my own site development, but felt like we needed a profile that would appeal to those looking for a dedicated MVC strategy. The best place to start really is the basic profile that comes with ProcessWire. When you understand that, you really can build anything. If you are wanting to go further, you might like to look at the skyscrapers profile. But the important thing to remember is that there is no "right" way to build your site in PW. This is why even tutorials can be a mixed blessing when you are learning, because they reflect one approach that may not necessary be the right one for you. Beyond the basic profile, you just need to read $page, $pages, PageArray and about Template files. Ignore everything else, because you may never need it. Don't feel like you need to remember or understand everything on those pages. But read through them and make note of what's there. These pages cover 99% of what you will do in ProcessWire from the code side… and probably a lot you won't ever use too. Once you get going and developing stuff, you'll want to keep the Cheatsheet open, which has sections that cover what's on those links above more succinctly. In ProcessWire, you should be comfortable with HTML markup and CSS. But it's less important that you know PHP. You only need to learn a few basics. You really don't need to know any more than you need to know EE tags. Know how to get in and out of PHP from HTML markup. i.e. <?php ... ?> Know what a $variable is – just a place to store a value. Most ProcessWire API functions return a value. Know how to use an if() statement. In PW, you'd use an if() to test if something had a value you wanted to output. Know how to use a foreach(). In PW, you'd use a foreach() to cycle through a page's children, or the results of a $pages->find(...). Know how to output a value, whether: <?php echo $value; ?> or <?=$value?> …both do the same thing. Know how to use include() to include another file, i.e. "<?php include("./header.inc"); ?> I think that covers all you would have to know to do most things from the PHP side in ProcessWire. Can anyone think of anything major I'm missing? Lastly, when you are developing, enable debug mode in /site/config.php: $config->debug = true; This will ensure that you get helpful error messages rather than ambiguous ones.

Hi, Just pushed a new site up for graphic designer Andrea Innocent: http://www.andreainnocent.com (She's also a talented illustrator and her otoshimono illustration site was one of my first PW sites.) Regards Marty

What it does: turns the content of $page->body into a clickable area and gives the ability to frontend edit the content via tinyMCE Release: In the next days. (my aim is tomorrow evening) finished with v0.0.1 https://github.com/Luis85/PageInlineEdit/

Hi folks. I've been lurking here for a while, trying to figure how things work before I overhaul my site. Anyway, I've no doubt I'll be asking for help at some point(s), so I didn't want to arrive empty handed. MarkupLorenIpsum Module for Processwire This module hooks after Page Render, and replaces any [lorem] tags found with random lorem ipsum text. How to use [lorem<length><format>] <length> (optional) number - sets the length of the output. Default is 5. <format> (optional) char - sets the format of the output, as follows: - 't' - formatted text. Each paragraph begins with a tab char. 'p' - plain text. No tabs or line feeds. 'h' - html. Each paragraph is formatted with <p>...</p>, except the first and last (see below). 'H' - html. Each paragraph is formatted with <p>...</p>. The default format is 'h' unless the length is <= the default, in which case the format is 'p' - useful for headings etc. The [lorem] tag is replaced with the generated text. Note that paragraph length is 100 (this is set in the construtor). Samples: - 'h': lorem ipsum lectus dapibus ... sapien malesuada.</p><p> auctor sapien, arcu inceptos ... consequat metus litora. 'H': <p>lorem ipsum lectus dapibus ... sapien malesuada.</p><p> auctor sapien, arcu inceptos ... consequat metus litora.</p> 't': \tlorem ipsum lectus dapibus ... sapien malesuada.\n\n\t auctor sapien, arcu inceptos ... consequat metus litora. 'p': lorem ipsum lectus dapibus donec sapien malesuada auctor sapien, arcu inceptos aenean consequat metus litora. Examples :- [lorem] - renders 5 words, plain format [loremh] - renders 5 words, html format [lorem20] - renders 20 words, html format [lorem20H] - renders 20 words, html format, wrapped in <p>...</p> [loren20p] - renders 20 words, plain format [loren20t] - renders 20 words, text format The reason for the two html options is that the textarea editor inserts <p> tags itself, so you would get <p><p>lorem...dapibus</p></p>. By default the extra tags are stripped, but this can be overidden if desired. It's built using example2 from the HelloWorld module as a wrapper for Mathew Tinsley's LoremIpsumGenerator class. markuploremipsum.zip

http://www.intercaloninterstates.org/

Ok, starting from the end. Put very roughly, $page represents a single page while $pages represents all pages. The methods from $page http://processwire.com/api/cheatsheet/#page can be applied to any object that represents a single page. $page, when used simply like this, represents the page that called the current template (usually by being viewed in the browser), but the $page methods can be applied to any Page object (other pages, even if they didn't call the current template). How do we get all those pages that are not represented directly by the variable $page? You guessed, using $pages http://processwire.com/api/cheatsheet/#pages $otherPage = $pages->get("/about/"); The get() method of $pages, returns always only one page. Meaning that $otherPage, is now an object equivalent to $page. Because of this, you can apply to it all the methods and call all properties of the object $page: echo $otherPage->id; While get() returns a single page, find() returns an array of pages, to be more precise a PageArray, and to those arrays you can apply any of the PageArray methods and call it's properties http://processwire.com/api/cheatsheet/#wirearray $pagesList = $pages->find("template=basic-page"); $pagesList->shuffle(); //same as: $pagesList = $pages->find("template=basic-page")->shuffle(); and because $pagesList is now a list with lots of $page equivalents inside it, you can go to each one individually and apply the same methods and call the same properties as with $page: foreach($pagesList as $individualPage){ echo $individualPage->id; } Disclaimers: I did an over simplification of the terms (same as in the cheatsheet). To make it clear: $page is a variable that holds a Page object that represents the current page. The methods I keep referring and that are on the cheatsheet, are in reality methods of Page objects, and not $page itself. The same applies to $pages and Pages. I must have some errors there because I'm far from a PHP specialist (even less concerning OOP). edit: Ryan, I saw that you answered before me, but I think to the first part. I will read now

Not sure. I consider myself to be not very firm with PHP, either. In fact, I have stated on numerous occasions that my PHP knowledge resembles the faculty of speech of a toddler. I never bothered to check out out said profiles/tutorials (because they didn't exist when I first checked out PW), I just started to build an older, smaller site. Maybe it helps that I'm firm with jQuery, after which the PW API is tailored. Along the way, I searched the forums, the API docs and asked very stupid questions. That's how I got to know the basic solutions, the “how to do XY in PW”s, if you will. You definitely do not need to be a PHP wizard to build (basic, at least) sites with PW. Sounds as if you're trying to take on too many things at a time. Try to relax and address one issue at a time. Don't hesitate to ask questions here – as long as you've searched forums and API docs and tried to understand it, no one here will bite your head off for asking questions. Most important of all: it is fun to work with PW. Try to have some fun. Well, very basically said, $page is the “currently addressed” page, and $pages is an array (something similar to a list) of pages in your site. You can “modify” that list of pages by using selectors to “limit” the selection of pages you would like to work with.

Here you go (I just added this page now): http://processwire.com/api/fieldtypes/images/

http://www.bestvendor.com/apps/cms/processwire

Hi guys, I've been spending the past couple days trying to get myself acquainted with PW... and I find myself swaying between excitement and discouragement. I'm excited because I'm really loving the way PW works but discouraged because I can't help but feel that I'm in way over my head. I'm not sure if this is in part because I still haven't reached the "AHA!" moment, but I'm also just very frustrated with my own lack of PHP knowledge (it's even less than I originally thought - at this moment, I think I'm completely PHP illiterate). Now, I really don't want to give up on PW, so I come here in hopes that someone can help point me towards the best way to approach "learning beyond the basics". I've gone through the various tutorials in the wiki and followed the Basic Website Tutorial as well, felt like I have a decent general grasp of things. Then I decided to upload and take a look at the blog profile. It had a lot of features I'm looking to implement, so I thought it would be good to see how things are done and make changes where necessary... except I think I ended up getting overwhelmed by it. Simply put, I can't make heads or tails out of a lot (most) of the PHP coding I see in the template files - never mind adapt it to the site I want to build! So, I've got a few questions. For someone who isn't a developer, would you say that jumping in and trying to take the Blog Profile apart is a bad idea? Is that considered advanced territory? Should I have just tried to build everything from scratch and add in the extra features step by step? Though, I'm not even sure how I would go about doing that, to be honest. I'm just lost. The basic stuff, I can grasp... like if I were to build a "static" site with various sections and some content, I can do that with PW at this point. The problem is, I think, the more advanced parts - as in, where and how to grow from the basics. I don't know where to even begin to tackle things, especially when it comes to specific customization. For example, I could probably copy and paste code for implementing comments... but then because I can't even understand what I'm copying or how to code PHP, I don't know how to make little changes, like say if I want to make it so that admin comments are styled differently, or if I want to load up Gravatar if one exists and if not then a default avatar, etc. Stuff like that. I'm sorry if this sounds like I'm just rambling randomly... it's just that I think I'm stuck at that point between being able to do the basic stuff but not having a single idea as to how to grow beyond that - short of going off to take some intensive PHP courses or something. So I guess my bottom line question is, how doable is PW for someone who doesn't know any PHP (and isn't just going to build a basic site with some content)? Am I better off not jumping into the deep end without at least knowing some PHP first? I've mostly built sites on ExpressionEngine and a bit of Textpattern in the past, so landing in pages of PHP code makes me feel like a foreigner in a strange country. And while I'm here, may I just quickly ask what the difference between $page and $pages is? The Basic Website Tutorial mentioned it a bit, but I'm not sure I truly understand when to use which... and what it means when pulling content from the page or another page? I sincerely apologize for my newbie whining...

I was late at night finishing a new website. It's for a Portuguese poet/painter/musician that is not very known. The website uses some Flash, but PW is still taking care of some stuff. Any suggestions are welcome, since I didn't have lots of time to make this one. Hope you guys like it http://www.joaovidei...osartes.web.pt/

@Grays sorry it took so long, but I was up to something that might solve some problems with sharing images. I create ImagesManager for these cases where you have lots of images shared on different pages. If you're still into the boat this might be interesting. http://processwire.com/talk/topic/3219-images-manager-alpha/

see this post and the following 5-6 for some pros and cons you shouldn't hesitate, have a look to some of the old foxes and younger (but also well known) foxes around here.

Grays I went through the same cycle as you and in case it helps at all all I will say is that using the default site that PW comes with and reading this forum and the links the others here have posted gradually got my PHP+PW engine started and even though it's only a low capacity engine (to stretch a metaphor) it is a very happy and productive one. That is to say I am *extremely* glad I found and persevered with PW and PHP because with the help of the generous people here and the great product PW is, I have been able to fly up and away from my old 'stuck' CMS to where I am now where I feel I could tackle almost anything with a little planning and QnA on the forum. So I'm sorry this post of mine won't help you practically but I hope it helps you feel that you will be able to do as I have (and likely more and better) and end up having a superb tool in your tool belt for future website work.

before pw code intercal.i did most wished pw.was code in intercal i have many time now.intercals on interstates i.am home

I'd love to trust Google in this matter, but what I've read so far seems to support the views expressed above: Google is actually making webmasters pay for their "unnatural link profiles", which could theoretically be a result of actions by people they have no way to influence.. although they do also offer a way to contact them regarding this very issue. How common this is and how much (and in what ways) it really affects individual sites seems to be up to debate even (and perhaps especially) within SEO expert community. Taking all things into consideration I wouldn't worry too much about this issue, though it would seem that unless Google decides to alter this behavior "powered by" links are not as good a strategy as they used to be anymore. @OllieMackJames: problem with this proposal is that ProcessWire generally stays out of markup generation and doesn't know what your site looks like or what kind of elements it contains. It doesn't even know if you're creating a website or something entirely different. This module could, of course, work while installed on the default site profile, but as Ryan pointed out above that's probably not a very common situation with live sites and thus doesn't do much good. On the other hand, some kind of slogan / metatag / badge generator would be at least fun but perhaps even useful. I'm thinking something along the lines of HTML5 logo thingy, though enhanced with (random?) slogan generator for couple of different use cases (Personally I'd love to see a WillyC slogan generator. That'd be awesome.)

There's more than one way to achieve this and you can find more comprehensive examples around the forum, but this is roughly the concept I've been using (simplified a lot for this example.) Let's say that you put this in your home template (/site/templates/home.php): <?php // this is your template file, or a controller if you will: $view = new TemplateFile(); $view->some_param = "PW"; $view->filename = $config->paths->templates."views/{$page->template}.php"; echo $view->render(); Then you add a view file corresponding to filename you've defined at controller (in this case /site/templates/views/home.php): <?php // this is your view file: echo "<h1>I'm view for {$page->template} and title is {$page->title}!<h1>"; echo "<h3>{$this->some_param} rocks!</h3>"; echo $page->body; This should be a working example, though not very useful yet. You could expand it by having your view files (or templates themselves) include other files ("partials" or just "include files" depending on terminology, for a global header and footer etc.) or have multiple view files for each template.. and so on. Of course you could also achieve similar results with includes instead of TemplateFile object, though I personally like how this method separates controller from view layer. As always, with ProcessWire imagination is your only limit

look well on the second link echo $users->get(123)->email; //or echo $users->get("username")->email;

Not a direct answer to your question but this seems like a really inefficient structure you got there. You could do something like this instead. /stores/ /store-1/ /store-12/ /store-13/ /cities/ /berlin/ /munich/ /cologne/ /categories/ /cat1/ /cat2/ /cat3/ and then enable URL segments on the category template, allowing for further filtering by city. So it works like: /categories/cat1/ ---> show all store that have this cat. /categories/cat1/berlin ---> show all stores that have cat1 and are located in berlin In this case berlin would be urlsegment1 (not an actual page). If you don't know already some info is to be found for example in this thread. In your case, a store can probably only be in 1 city, so you could even further structure it like: cities -city --store

Just wanted to share what I recently used to create forms in modules and in frontend using the API and Inputfield modules PW provides and uses on its own. I think many newcomers or also advanced user aren't aware what is already possible in templates with some simple and flexible code. Learning this can greatly help in any aspect when you develop with PW. It's not as easy and powerful as FormBuilder but a great example of what can be archieved within PW. Really? Tell me more The output markup generated with something like echo $form->render(); will be a like the one you get with FormBuilder or admin forms in backend. It's what PW is made of. Now since 2.2.5~ somewhere, the "required" option is possible for all fields (previous not) and that makes it easier a lot for validation and also it renders inline errors already nicely (due to Ryan FormBuilder yah!). For example the Password inputfield already provides two field to confirm the password and will validate it. De- and encryption method also exists. Or you can also use columns width setting for a field, which was added not so long ago. Some fields like Asm MultiSelect would require to also include their css and js to work but haven't tried. Also file uploads isn't there, but maybe at some point there will be more options. It would be still possible to code your own uploader when the form is submitted. Validation? If you understand a little more how PW works with forms and inputfields you can simply add you own validation, do hooks and lots of magic with very easy code to read and maintain. You can also use the processInput($input->post) method of a form that PW uses itself to validate a form. So getting to see if there was any errors is simply checking for $form->getErrors();. Also the $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automaticly. It's also worth noting that processInput() will work also with an array (key=>value) of data it doesn't have to be the one from $input->post. Styling? It works well if you take your own CSS or just pick the inputfields.css from the templates-admin folder as a start. Also the CSS file from the wire/modules/InputfieldRadios module can be helpful to add. And that's it. It's not very hard to get it display nicely. Here an code example of a simple form. <?php $out = ''; // create a new form field (also field wrapper) $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name",'subscribe-form'); // create a text input $field = $modules->get("InputfieldText"); $field->label = "Name"; $field->attr('id+name','name'); $field->required = 1; $form->append($field); // append the field to the form // create email field $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $form->append($field); // append the field // you get the idea $field = $modules->get("InputfieldPassword"); $field->label = "Passwort"; $field->attr("id+name","pass"); $field->required = 1; $form->append($field); // oh a submit button! $submit = $modules->get("InputfieldSubmit"); $submit->attr("value","Subscribe"); $submit->attr("id+name","submit"); $form->append($submit); // form was submitted so we process the form if($input->post->submit) { // user submitted the form, process it and check for errors $form->processInput($input->post); // here is a good point for extra/custom validation and manipulate fields $email = $form->get("email"); if($email && (strpos($email->value,'@hotmail') !== FALSE)){ // attach an error to the field // and it will get displayed along the field $email->error("Sorry we don't accept hotmail addresses for now."); } if($form->getErrors()) { // the form is processed and populated // but contains errors $out .= $form->render(); } else { // do with the form what you like, create and save it as page // or send emails. to get the values you can use // $email = $form->get("email")->value; // $name = $form->get("name")->value; // $pass = $form->get("pass")->value; // // to sanitize input // $name = $sanitizer->text($input->post->name); // $email = $sanitizer->email($form->get("email")->value); $out .= "<p>Thanks! Your submission was successful."; } } else { // render out form without processing $out .= $form->render(); } include("./head.inc"); echo $out; include("./foot.inc"); Here the code snippet as gist github: https://gist.github.com/4027908 Maybe there's something I'm not aware of yet, so if there something to still care about just let me know. Maybe some example of hooks could be appended here too. Thanks Edit March 2017: This code still works in PW2.8 and PW3.

How about a Dutch landing page for ProcessWire, like the German version? Would be kind of cool. Any plans for that? I'm willing to do my part

<ul id="gallery1"> <?php $thumb = $page->thumbnail->size(220, 200);//outside of the foreach so it only runs once foreach($page->images as $img) { $thumbImg = $img === $page->images->first() ? "<img src='{$thumb->url}' alt='{$thumb->description}' width='{$thumb->width}' height='{$thumb->height}' />" : ""; //if this is the first image $thumbImg gets the content. If not, it's empty. echo "<li><a href='{$img->url}' rel='prettyPhoto[gallery1]'>{$thumbImg}</a></li>"; }?> </ul> edit: The code above will throw an error if you don't have any image uploaded in the thumbnail field. You should also prevent that error by checking for it.

Hi Teppo, great link you posted http://www.seomoz.org/blog/googles-unnatural-links-warnings Ryan, I think if you read that article, you will be up to date pretty much, there is much more of course, but this gives good pointers. Also do please read the comments below on that page, because what happened to seomoz is not really what happens to smaller sites. SEOMOZ already had lots of back links and also has and had a very active sydication strategy of their content, so they are harder to take down. Regarding your attribution text suggestion, I would just take that as one of the options, nowadays g seems to recognize use of brandnames as well and gives the brand name owner credit for that as well. This whole seo field is a bit of a mine field, and I am hopeful g will try to correct the spam-your-competitor-possibilities, but I am not holding my breath... I would not hesitate to use attribution links as I proposed, and if you build an option in it to change all links to attribution text only upon an update of the module, you are covered all ways. Now one final remark here, regarding seo smarts, g now heavily seems to look at the environment where the link exists. It used to just be enough to have a link with the anchor text that you wanted to rank for and spammers apparently spammed the living daylights out of this, then g wisened up and started looking more at the text around the link, so spammers found that out as well and put links in text snippets about the topic. Then the link networks jumped in, allowing people to post articles about certain topics that were then posted to many sites, and we have all seen thoses sites I suppose, they add no value whatsoever and can be recognized a mile away. Of course g wrote an algo that recognizes those sites. Then also the panda algo came aroud, focusing on bounce rate, time on site, etc. etc. GREAT! this helps people who have great sites that help people with great content that people want so much that they stay around. The penguin update was all about over optimisation, either on page, or intra-site-linking, and outside back-links. Now one final thing about outside links: it gets more and more important that links come from sites that are related to your topic. So with that in mind, maybe - next to the module above - ask developers/designers to link to your site with an explanation on a page where they write a review about processwire and why they use it, and have them put a link in that article to processwire. But the best ambassador should always be processwire itself. If someone wants to develop a module, I would be happy to think along and help with the concept and testing, great to hear that the markup module apparently can be of service there. Wishing you all happy PW-ing!

Ah, I've generally learned best/fastest from examples, deciphering the bits and such, hence me trying to pick apart the Blog Profile. Seems I was trying to fly before knowing how to walk! I shall revert back to the basic site and go from there once more as you have advised. Having "no right way" to build a site is actually one of the reasons I like PW, because I enjoy the freedom of being able to build sites the way I designed them (which was also one of the reasons why I was drawn to EE back in the days). So I do take the tutorials as they're meant to be taken... which, I think, is what led me here. I find myself stuck trying to take things "out of the box" so to speak because I don't know how to code any of it. I hope I'm making sense... But, Ryan, thank you so much for listing all those things I should take a look at. It's exactly what I need at this point - a direction to head towards, because I didn't even know where to begin and how much I'm supposed to "know" in regards to PHP. Looks like I'll be doing lots of reading shortly. By the way, in your example for outputting a value, is it generally more recommended to use the shorthand (is that the right term?) of coding or the full <?php echo $value; ?> and so on? I think I've been seeing bits of both throughout the forum and code bits, so it was something I was curious about. I figured it was just a shorter way to code the same thing, but are there any pros/cons of using one or the other and can the shorthand(?) be used everywhere? Just want to make sure I adopt the best practice right from the start! You may be right. As mentioned to Ryan above, I'm likely trying to fly before knowing how to walk properly. Part of the reason is because I'm also currently trying to convert a site built on EE over to PW, so I keep thinking ahead even though I really should be going at it slower instead of stressing myself out. I do have to admit that I'm hesitant to ask stuff in the forum right now, because I feel a bit like a headless chicken running around. I'd either be asking about every single little stupid thing or it'd be a case of not even knowing where to begin searching for what I need. I tend to try and work things out myself, so this is a point of frustration for me because I feel like I'm so stuck right now and not even knowing what specific thing to ask to get unsuck. Oh and thanks for the explanation in regards to page/pages. And to diogo too. I think I'll be heading over to the areas Ryan pointed out to familiarize myself a bit more on what I need to know and perhaps things will start to click in place. (Btw, yellowled, I actually know more PHP than I do JQuery, so that might tell you something about how lost I am...) Thanks all! I'm feeling a bit more, err, pumped up about jumping back in. You guys are awesome. EDIT: Holy, just saw that there were more replies. Will go read them and reply accordingly in a bit. EDIT 2: Um, I meant "to get unstuck"... and not unsuck. But I suppose unsuck works too.

What Ryan says is completely true, my knowledge of PHP is simple, but i've built some interesting/complex things using only the basics listed, and the fact that you can build almost anything using only those basics and the cheatsheet is the strength of it's underlying design. With PW, i think it's more about how you can visualize the relationship between your content in the backend and how you will output that in the front..so more like creative thinking, problem solving... it is for this reason that processwire is so much fun as @yellowled points out, because you find yourself being inventive and coming up with cool ideas that no other CMS would 'provoke'... it's nice to finally be able to say to clients "yes that can be done"

Much is already said here by pro´s. All I can add to it is that you should stick to PW even if all the api and php can be intimidating and make you look back for a more easy cms. Why you should stick to PW ? Because it will pay off in having total freedom to make a website in any way you want or see fit for you needs. You don´t want to go back anymore to an easy out of the box cms but with all it´s limitations. I have repeated Joss tutorial basic website many times only to get familiar replacing content between html tags with php tags and api calls. After that you start experimenting making your own template files with your own php code and api calls. A good way is to make first a general html page with a top navigation bar, some text, pictures, and a footer, all with plane html, js and css. Then you replicate this page with a template file and fields in PW and start replacing content between html tags with php and api calls. That´s how I learn my self deeper into PW. One very important thing that I haven´t found much about yet is how to make PW´s front end (the fields ?) very easy for clients. Clients want to edit/update their website as easy as possible. It´s funny but almost all cms'es start with explaining how you can do a-b-c- and x-y-z but never they start first explaining how easy the front end is and how clients and end users can do a-b-c and x-y-z on the frontend to update their website. And yet clients are king and not us who make websites for them. First thing I would like to know is how to make "setup" - "modules" - "access" disappear in the frontend but keep it on the backend. Same with making disappear for pages "view" - "new" - "move" - "delete" - "copy" on the frontend but keep it on the backend.

Better to participate now than to complain later https://docs.google.com/forms/d/1GPDA30gLd-5S8AAlZmwElS6RurOfQuWSAKqN7qMf-Io/viewform

Makes sense to me. I will get this in the dev branch soon.

Certain settings for fields can be changed on a per-template basis; ie. the label of your "title" field for template "person" could be "name" instead of "title". When used properly this helps keep code between templates similar, fields reusable and things in admin interface logical

Debug mode shouldn't make any difference in that respect. Since browsers render output as a big chunk, you don't ever get to see HTML elements rendered individually one-by-one (except for images and ajax). At least not in a situation like this. As a result, if there is a perceptible delay between rendering of adjacent HTML elements, that has something to do with CSS or JS (more likely JS). Whereas if there is a perceptible delay before you see anything rendered in your browser, that can be at the server side or the client side.

Thanks for guiding my through! I learned a lot! Here is the working code for what I wanted to achieve: <?php echo $users->get("$page->created_users_id")->name; ?>

Sure, Pete, I can name the checkbox "hidden from menus" and turn the logic around, no biggie. And Ryan, thank you for letting me know the reasoning behind this.

Hi Ryan, Sure, more than happy to discuss this topic. Just hope it helps. This is one thing I have been studying a bit over the years, I am not a programmer and can not give back anything regarding programming or modules, but my intention is to give back something to the pw community and this is a bit of my expertise so that is why i jumped in. You said: "Another thing to consider is that your site can't be penalized for who links to you, or in what quantity. Only those linking to you, and the value of the links [to you] can be penalized." This I hear so often, but it just is not what I see back in facts that I have studied. In principle your statement is valid as in this is how it should be, but there is a difference in how things should be and how they are. Exactly because other people now can damage your site by throwing thousands of useless links at your site, big ole g finally opened a link disavow tool in the webmaster area, and the sheer existence of the link disavow tool to me proves that links can and do hurt your rankings, but let me go another way to see if I can help a bit 'forward wise' with developing vision for processwire seo street smarts. I still am totally in favor of first giving vistors what they are looking for, always have been and will be because they butter the bread. My main focus is all on building sites so smart that they are a honey pot to visitors, so they stay around etc. and share etc. etc. And for PW the best thing of course is people talking about it and sharing the greatness of it as a tool, and at the end and the beginning of the day that will take you the furthest, and there your brilliance and processwire's community's brilliance already really shines! OK, what would I propose to do? I would do something along the folllowing lines: - make a module that does the following (I would have to hire someone to do this, but hey, I would do it like this): * upon going live with a site, and upon handing over the site: ask people if they want to show the world one time on their whole site that they use processwire under the hood * then I would ask people as well to simply choose what attracts them the most in this cms: = ease of use ==> anchor text: processwire used here because we love this easy cms = search engine optimisation simplicity ==> anchor text: we chose processwire, the seo cms number 1 = it was the choice of our designer ==> anchore text: processwire, the cms of choice of designers = Etc. Etc. whichever you think would be the reasons people can go for pw = other: open ended anchor text. The last option in the module would then be, where they wanted to share this link JUST ONE TIME ON ONE PAGE: home page footer, about us page, sitemap, whatever. I would try to stay away from sitewide footer or sidebar links, because that is not healthy. It is much better to have IP diversity in the back links and have anchor text variety. This way processwire would get the best of many worlds: - marketing information regarding what makes people choose or like about processwire - VERY VALUABLE - good ip variety of sites linking back - anchor text variety of backlinks Thanks again!

I'll gladly accept it and help the community whenever I can. As said before, you can find me at #processwire at irc.freenode.net

I found the information I was asking for: http://processwire.com/talk/topic/2287-image-size-configuration-questions/?p=22535 Maybe it would be fine to have all available options somewhere available at one place - the thread above would be a nice place to collect them ;-)

Let's see if I understood you right. "1010" does not look like a title, but more like an id, so I'm assuming you've got a structure like this: /cities/ /munich/ /berlin/ /stores/ /store-1/ /store-7/ /store-12/ /store-17/ /store-22/ Every store-nn page is using template "store" which has a Page field called "city", allowing you to choose a city for this store. Now if this was the structure and you were on page /berlin/, you'd like to find two random children of /stores/ where you've chosen "city" to be Berlin. This should do it (not tested though): $children = $pages->find("parent=/stores/, city=$page, location_category=1065, sort=random, limit=2"); foreach($children as $child) { // ... } And if "city" really was a text field but otherwise I got your intentions about right, you only need to change "city=$page" to "city=$page->title" in the selector.Probably this isn't exactly what you're after, but hopefully it helps you to get there.

If you let me know a little more about how these images are gonna used on the pages I could help provide a image system thats gonna work. I.e. Do you need to insert images in the body text inline. Or will they have a predefined place. Will they be just single images or galleries?

Ryan, thanks for the prompt reply. It seems both of us are right. From a ProcessWire codebase point-of-view, you are right: almost all the code written (added/removed) on those 11 missing commits is already on dev. I say almost because there are 3 lines of code introduced in master that are still missing in dev, as you can see below. $ git diff dev...master diff --git a/wire/modules/Fieldtype/FieldtypePage.module b/wire/modules/Fieldtype/FieldtypePage.module index 06e0f65..c5e2669 100644 --- a/wire/modules/Fieldtype/FieldtypePage.module +++ b/wire/modules/Fieldtype/FieldtypePage.module @@ -254,6 +254,9 @@ class FieldtypePage extends FieldtypeMulti { } else if(ctype_digit("$value")) { // page ID $result = $this->pages->get("id=" . $value); + + } else if(strpos($value, '|') !== false && ctype_digit(str_replace('|', '', $value))) { + $result = $this->pages->getById(explode('|', $value)); } else if(strpos($value, '|') !== false && ctype_digit(str_replace('|', '', $value))) { // CSV string separated by '|' characters So, again, you are correct: at some point, probably by copy-pasting chunks of code, you introduced into dev the pieces of code (the changes) on those 11 commits. A proof of that is that the changes introduced in commit 9b3039d (an atomic change, only present in master) are also part of commit 7dab612, which is a huge commit in dev. It's almost as if you cherry-picked (see git cherry-pick) but in a manual, human, untidy way. So far, so good. And the only changes you missed to move manually are those shown on the git diff output above. From a Git point-of-view, I'm right: 11 commits done in master aren't part of the dev branch. Even Github shows that same info here (dev is 11 commits behind and 4 ahead of master) and here (comparing both branches, it shows the same diff as above). Technically speaking, from a Git point-of-view, master and dev have diverged. So, now that we all have a better understanding of what happened and what is missing from dev branch (just 3 lines of code), let me suggest what would have been better options to bring the changes from those 11 commits in master branch back to dev branch. As said, Ryan, you did it manually, but that's prone to (human) errors, as changes could be missed and/or introduced with errors. First (best) option: as suggested on previous post, just merging master (righ now, or back at the time when you did those 9 commits now known as "2.2.9.final") back to dev is all that's needed. Right now, that action will just bring to dev those 3 lines of code missing, by creating a merge commit. In the graph, it will clearly show that those commits are part of dev and there won't be any doubt. Back at that time, that action would have bring the many lines of code missing, releasing you from the task (human & prone to errors) of manually having to copy-paste them. Second option: git cherry-pick. Right now, this option won't make sense, as you already "cherry-picked" the changes from master back to dev in a human fashion. Back at that time, if for some reason (I can't think of one) you couldn't merge master back to dev, git cherry-pick would have been the best option, as it lets you manually pick which commits from master you would like to re-apply to dev. Take into consideration that cherry-picking commits from a branch (ie. master) creates new commit objects on the destination branch (ie. dev). A commit created by a cherry-pick will have a different hash than the original commit (the one cherry-picked), but it will introduce the same exact set of changes (ie. the same +/- patches). Bottom line: while standing on dev branch run "git merge master" and call it a day. Mmmmm. Personally, I'll suggest to stay with the "dev" name for the development branch. Something you could do is that, after some release (ie. 2.3.0), on the next commit, on some project file (ie. readme.txt, or changes.txt, or version or whatever you use) you rename the version to 2.3.1-dev. In this example, it's important to get that "2.3.1-dev" means "the development done for next 2.3.1 version", and not "the development done after 2.3.1 release". Then, on some place of the PW admin, you could print "ProcessWire (2.3.1-dev)". But the question remains: at which exact commit of the many commits that may correspond to the development of 2.3.1 is this PW installation standing at? I'm not sure what's the answer for this, but Git may be helpful here. There is the git describe with "shows the most recent tag that is reachable from a commit". For example, if in your PW repo you run: $ git describe master You will get this output: 2.2.9.final-174-ga8024bb Which means that master branch is 174 commits above the "2.2.9.final" tag, more precisely in the commit a8024bb. The "g" is just a prefix to indicate that is a commit done in Git. So, as you can see, there is a good way to describe where is standing someone in relation to last tagged version. Ryan, 2 last things: First, as you are the BDFL and main commiter of ProcessWire, I'd suggest you to begin using annotated tags: http://git-scm.com/book/en/Git-Basics-Tagging#Annotated-Tags Second, I'd suggest taking a peek at this Git branching model: http://nvie.com/posts/a-successful-git-branching-model/ It's a pretty popular one, and it may fit into the way PW is currently being developed. Even if you don't want to follow that (or any other) particular branching model, the article is pretty good to clear up some concepts. That's all by now, thanks for reading.

You should totally stop by at Bratislava… after all, it's like 50km from Vienna

Actually it has support now, and it's there in 2.3. But it's considered "beta", so I don't recommend using it on production sites until I'm at least using it on a production site (which should be about a month from now). But I think it's perfectly fine to go ahead and work with it now for testing and/or development.

@Samuel: what you're describing here sounds fascinating, at least in theory, though I'm not really sure how it would work in the context of ProcessWire. Which parts of current system would you imagine being useful for this new workflow -- would you still edit content with current admin tools and on page save rebuild site as static version and commit + push it to GitHub or am I completely misunderstanding something here? Isn't that pretty much how Jekyll works, by the way? Anyway, you may want to take a look at this thread, where somewhat similar idea (converting site to static HTML) is already being discussed.

UPDATE I have updated the Bootwire Starter Profile to version 0.5 This version included a functions.inc file that is included into the head.inc file. This file has demo functions of various Bootstrap functionality that can either be used immediately, or (more properly) used as a starting point for your own functionality. These versions are kept very basic. Functions include: Carousel Collapse (accordion) Tabs Button Dropdown Thumbnails used as a gallery The functions are fully commented with instructions as to which fields were used or need to be created. I have also added a bootwire.js file that includes a couple of bits of JQuery to correct some issues with thumbnail and div alignment over multiple rows. Read the instructions to see how to use this code. Hopefully, this profile is now very functional as a base starting point. Any feedback from testing would be appreciated. Joss Note: I have temporarily removed the link to the demo profile while I update it with the new functionality

It's easier to read. But my opinion is that it's also difficult to understand where it could lead. With GPL you know you are protected from some big corporation coming in and taking over. It keeps others from exploiting ProcessWire's core in ways we can't predict. Profit motives are limited to what you create with or for ProcessWire, rather than what you do to it. ProcessWire's core remains protected. I'm not saying I'm against MIT, and always think that going "more open" is good and worth considering. I'd love to talk to the Concrete5 folks to gain insight on their choice. But we should never be motivated to change the license because someone misunderstands ProcessWire. We should only be motivated by what's ultimately best for the project and users. Currently I think GPL is a great and safe fit for us. Though I also understand the GPL always opens questions wherever you take it. So it's important for project leadership to answer those questions and be clear so that there is no grey area. I think that's what we've done. Though I always invite more questions.

If you have a robots.txt, I would use it to specify what directories you want to exclude, not include. In a default ProcessWire installation, you do not need to have a robots.txt at all. It doesn't open up anything to crawlers that isn't public. You don't need to exclude your admin URL because the admin templates already have a robots meta tag telling them to go away. In fact, you usually wouldn't want to have your admin URL in a robots file because that would be revealing something about your site that you may not want people to know. The information in robots.txt IS public and accessible to all. So use a robots.txt only if you have specific things you need to exclude for one reason or another. And consider whether your security might benefit more from a robots <meta> tag in those places instead. As for telling crawlers what to include: just use a good link structure. So long as crawlers can traverse it, you are good. A sitemap.xml might help things along too in some cases, but it's not technically necessary. In most cases, I don't think it matters to the big picture. I don't use a sitemap.xml unless a client specifically asks for it. It's never made any difference one way or the other. Though others may have a different experience.

Joshuag You might want to look at what I have done (er, am doing) with a bootstrap profile http://processwire.com/talk/topic/2411-bootwire-basic-twitter-bootstrap-profile/ Basically I am creating two - one that has bootstrap installed and then demonstration pages showing how some of the bootstrap elements work in this environment (which is actually straight out of the box, but it is nice to show it anyway) Then the second is the same things with just about everything removed - almost no fields, only a couple of template files, no content, just ready to go and put together so that more up-to-date bootstrap versions can be just dropped in place. The only extras in there is the standard Bootstrap menu system wired into PW and basic demo carousel and accordion files to save people having to mess around with these. So, that is the profile that is really useful to people - the first is just a reference. Joss

Joshua, I'd actually like to do a full HTML Kickstart profile for ProcessWire, if that'd be alright with you. Maybe we could collaborate on it sometime?

I wish that I had seen this earlier to respond. Awesome explanation and example Ryan! @siulynot - thanks for using HTML KickStart. Hope it saves you some time.

You're doing great jobs over here Jos. I'm glad you joint the community. Just want to shout out my opinion about styling the back-end tinyMCE Setting a site style to tinyMCE is my opinion a bad idea. To mimic it al to almost the same as in the front, can confuse customers who are working with tinyMCE. They aspect the output on the front exactly the same as on the front. If you don't style and leave as it is standard, those expectations won't be there & saves you a lot of time. Proper use of HTML tags is in more important then eye-candy.

whoa lucky there was talk about revoking your processwire membership for a while there... ha ha where did you dig that one up, its a beauty.