Leaderboard

Hi everyone! With Batcher you can batch-edit and create Pages in the Pw Admin. If you install this module, you get a new Page "Batcher" under Setup. Modules page: http://modules.processwire.com/modules/process-batcher/ Github: https://github.com/wanze/ProcessBatcher Editing How does it work? Search your pages with a selector. You can check if you want to include also hidden/unpublished pages with the filters. Select the pages you want to execute an action (the action only gets executed on "checked" pages). Select the action and if necessary, additional data like the new parent or the new template. Execute. Supported actions: Publish/Unpublish Pages Hide/Unhide Pages Lock/Unlock Pages Trash Pages Delete Pages Change Parent Change Template Batcher does the following permission checkings for the current user: Don't display pages that are not editable Remove Actions if the user doesn't have the permissions (page-delete, page-move, page-template, page-lock) Important notes: When changing a template, data in fields of the old template which are not assigned to the new template gets deleted. When changing the parent, the template of the new parent must accept the pages template as children. This is a setting in the template under "family". Creating How does it work? Select a parent where your new pages will be added as children Add as many pages as you want by clicking "add Page" Click "Create Pages" You must enter a title and choose a template. The name is optional: If left empty, Pw will generate this for you. Includes permission checking and Family template restrictions. This means in detail: The selected parent must accept children and their template The pages template must accept the parents template User needs the permission to add children to the selected parents template User needs the permission to create Pages for the chosen Template Batch-creating tips The chosen template and the statuses are always cloned from the last row. So if you need to add 30 pages with the same template, define it first and the click "add Page" - it'll make your life easier ;-) You can drag & drop the table rows should you want to change the order. The dragging looks ugly but it works. For the lazy dogs and keybord hackers among us, you can add a new row by pressing "ctrl+n". This works (at least in firefox) only if no input has focus. After adding a new row, the title input gets the focus. By pressing 3 times tab you arrive at the published-checkbox, here the short-cut works. Restrict Batcher for a user to only allow editing or creating Create permissions "batcher-edit" and/or "batcher-add". As soon those exists, the module checks if the current user has the permissions. If you only need batch creating, check out the following module by Soma: http://processwire.com/talk/topic/2138-process-tools-create-pages-wip/ Cheers

Originally inspired by a comment by Pete on Process Changelog thread, I've been playing with (and just pushed to GitHub) an experimental version control module for text based fields, which does some of the things discussed here. Somewhat coincidentally it also bears quite a bit of resemblance with the mockup Ryan posted above UI wise.. It's not production ready, only supports storing content to database (though adding another mechanism for storing the bulk of content wouldn't require much work and most likely will get added soon) and currently only supports Text and Textarea fields. I'm looking into this subject more closely once I find some free time for it, but in the meanwhile anyone interested can check it out, use it, fork it etc. as long as you're aware of the fact that it's more of a proof-of-concept than anything else and that it's far from a perfect solution in more than one way. Regarding Drupal 7 diff module posted above by @ceberlin, this module doesn't provide that kind of features at the moment, though it does store all necessary data (and a bit more) to enable those at some later point. I was originally planning to only store diff data, but since PHP doesn't have native method for doing that I ended up storing full content on each edit. Not very efficient, but for small-scale use (or proper limits, to be added later..) it should be good enough (for now.) I've also omitted many other features, such as those mentioned by Ryan above (modals etc.), for the sake of simplicity and feasibility. Anyway, if anyone is interested to try it out I'd be very happy to hear any comments on this one

Badger or batcher?

That's not far off from what I'd been working on with versioning, which was to store page versions in flat JSON encoded strings in a DB table (though could just as easily be stored as text files). Any ProcessWire page can be reduced to a PHP array of basic types (strings, integers, floats, arrays), which means it can be reduced to a JSON string really easily. This lends itself well to version storage, except for assets where only references are encoded (like files and page references). But I have to admit that the more I think about Antti's proposal to store this at the field-level, the more Iike it. I would create another interface that could optionally be added to a Fieldtype's implements section in the class definition (FieldtypeWithVersions or something like that), and give the individual fieldtypes responsibility for if, how and where they store their versions. That would enable us to get up and running with versions quickly (for text fields at least). It would also seem to provide a nicer level of control to the user, as you don't have to keep track of what is changing in multiple fields at once. And, it would let you to enable versions on fields that you want it, omitting on field where you don't, making things more efficient. Lastly, it would leave the page-structure out of versions completely (where the page lives in the tree), which struck me as a potentially dangerous problem with versions. It could work something roughly like this: You hover over the revisions label and get a summary of recent revisions. You click on one, it could pop up a modal showing you the revision (maybe with a compare tool) and a button to revert to it or cancel. It just seems like a really easy-to-use solution for the user.

Hello, this module is a little compilation of things you need to use ProcessWire to write a blog. It'll create: Templates blog_admin blog_article blog_category Fields tags (using the "TextboxList" fieldtype) category (using the "Page" fieldtype) Pages (hidden, using the "blog_admin" template) article (you should create a subpage using the "blog_article" template for each article) page (same like article or you could create a "blog_page" template if you want) category (you should create a page using the "blog_category" for each category and if you want you can also create subcategories) It requires the "FieldtypeTextboxList" module (I placed it in the "BundleBlog" folder, too). For comments you can use the built-in "ProcessComments" module. If you have any wishes please let me know. Download P.S.: I'll also add my preview module in a further version.

Hi, I am web designer and I want to learn PW by create simple e-commerce website. I've been search around to find solution, comparing every option & weight both it's advantage/disadvantage, I think most solutions out there is too complex or they already make lot of assumption, not to mention the more code means heavier page load. That's why I finally get conclusion that PW is the right answer. Well, the solution not answered yet, but I sense PW have the power to be there. Let say example, Ms. Turner is local bakery which have 50 product under 5 category. She don't need complex shipping since order could be pickup at store or using private delivery courier and of course She don't need sophisticated payment system or any other crap feature. Yes, there is customer for that kind solution, but not for Ms. Turner and hundred millions people out there. All she want is just simple website to accept order. I do aware that there's already tutorial out there, but it's just answer for specific solution. Not to mention how hard it's gonna be when this forum already have ton of pages. If You're not mind, I create this thread so everyone could learn from beginning especially for newbie or copy paste guy just like me to feel the power of PW. This thread would be tutorial creating e-commerce from scratch and the final goal is free theme both front page and admin page specially designed for Ms. Turner and hundred millions small business right there. Apeisa already make awesome module for PW and I already tested it, its work so wonderful so let's complement it. For starting point, let's start from designing the homepage. The content would be: Home - Header (logo, cart toolbar, search) Content - 3 Image Main slider - 6 Featured product -Footer - Quick Link - Social Network Link - Twitter Widget - Newsletter Subscribe What is the best practice from code perspective?

Or Swissknife

Not really sure if it's exactly what you looking for but these should get you there. // recursively get all children from current page function getChildCategories($page=null, $level=0) { if(!$page) $page = wire('page'); $level++; $out = ''; $out .= "\n\t<li><a href='{$page->url}'>{$page->title}</a>"; if($page->children->count()){ $out .= "\n\t<ul>"; foreach($page->children as $child){ $out .= str_replace("\n\t", "\n\t\t", getChildCategories($child, $level)); } $out .= "\n\t</ul>\n\t"; } $out .= "</li>"; if($level == 1) return "<div><ul>$out\n</ul>\n</div>"; else return $out; } echo getChildCategories(); And from your point 3. "has_parent" is the key here I think to find all children recursively from a certain page, then get all posts that has at least one of those selected // get all children categories of a parent and get most recent posts from all those function getChildCategoriesPosts($page=null) { if(!$page) $page = wire('page'); $out = ''; $categories = wire("pages")->find("has_parent=$page,template=category"); $posts = wire("pages")->find("category=$categories, sort=-modified, limit=10"); if($posts->count()){ foreach($page->children as $child) $out .= "<li><a href='{$child->url}'>{$child->title}</a></li>"; } else { return "<li>No Posts found/p>"; } return "<div><ul>$out</ul></div>"; } echo getChildCategoriesPosts();

Mr. Log is on fire!

Herr Luis! Strange you should say this. My company: http://www.dancingbear.co.uk (Warning, NEVER go to the dot com. It used to be owned by a lady who sold knitting patterns, but then it got bought by a porn company. Damn it!)

Looks like we will see you in the recall Joss, pretty Good performed. You just have to work on your Dancing skills.

"Do the ProcessWire And get your Profits higher Do the ProcessWire Do the ProcessWire "Your coding's on fire With ProcessWire Do the ProcessWire Do the ProcessWire"

Looks awesome, thanks @Wanze! This'll come in handy especially for some of our bigger sites, I'm sure @Luis: some things can't be unseen. Going to have difficult time maintaining serious expression while introducing this module to coworkers or clients, simultaneously avoiding this image of dancing badgers..

Hello there, @artaylor, and welcome to the forum! Just like Pete above, I've got absolutely no problem with template engines - as long as they stay out of my way What I do have to disagree with is the general idea that template languages makes things simple and programming languages difficult. Template languages generally start with a good idea ("separate code / logic from markup / view") but eventually end up re-creating much of native functionality and only making things more complicated for everyone. Designers still need to learn new (template) language and developers not previously acquainted with that particular template engine have to do the same just to keep up and provide often necessary support. Just take Twig as an example; it's really quite amazing how complicated structures any moderately resourceful designer can create with relatively simple tools like macros, conditional logic, variables - especially when combined with template inheritance and horizontal reuse. I also strongly disagree with your notion that designers would need to know and understand "a full programming language" simply to create HTML template with some variables. Exactly why would they need to do that, if all they need is echo and some simple control structures? How would this part be so different when using a template language instead of PHP? Based on what you've said there some template languages seem to be pretty fault tolerant, but I can't help wondering if that's really a good thing - I mean, why shouldn't there be an error if something is clearly broken? What if it causes misleading information to be spread out, UI to be broken or any number of other problems? One thing I do see value in is sandboxing, though. Like you pointed out, sometimes it's necessary to set limits for the amount of damage an inexperienced designer (or developer) can unintentionally cause. This is a good argument for template languages, though I'd still argue that most of these issues can be avoided altogether. Pete and others have already provided valid solutions above. Another important thing is to never make changes on live environment. That's just plain wrong and will definitely cause problems eventually, no matter how skilled folks you've got. You can also provide designers with a simple checklist of things to a) do, b) not do and c) be careful about. IMHO that's much better than making everyone learn yet another language. All that said, there's clearly a lot of interest in template engines around here nowadays, so you can be sure that eventually you won't have to teach another row of PHP to a designer. I still honestly wish that more designers could get over their phobia of these evil programming languages and realize that they're not that bad after all. This is one of the reasons why I won't ever advocate disguising or wrapping PHP (or any other "programming language") with something that's ultimately just another layer of complexity Edit: even though this post is already horribly long, I just had to add that the way I see it such things as "pure" programmers, front-end guys or designers rarely exist in the world of modern web development - and that's a good thing. Learning what others do and how they do it, even if it's just the basics, can benefit everyone. No one benefits from tightly set roles, such as "designer can't write PHP, period."

If it is any help, this is what I am doing at the moment. I have decided to use a product tree like this: The following I call sections and all these three levels have the same template detailed below called product_section_list: Products -Girls -Girls Nightware <?php // product_section_list if($page->children) { $sections = $page->children; foreach ($sections as $section) { $firstimage = $section->product_images->first(); echo "<div class='product_section'> <div class='img_ctr'><a href='{$section->url}'><img src='{$firstimage->url}' alt='{$firstimage->description}'></a></div> <h3><a href='{$section->url}'>{$section->title}</a></h3> <!--<p style='text-align:center;font-size:90%;'><span class='product_attribute_label' style='margin-left:1em;'>Price:</span> £{$section->sc_price}</p>--> </div>"; }} ?> What this does is create a top-level product section list that links to each child of the section. So a view of the products page would be something like this (images are just for testing purposes): If you then view the section called Girls you get this: The section Girls Bedding uses a different template called product_item_list see below: <?php // product_item_list $currentpage = $page->categories; $prods = $pages->find("template=product_item, categories=$currentpage"); if (count($prods)) { foreach ($prods as $product) { $priceraw = $product->sc_price; $price = number_format($priceraw, 2, '.', ','); $firstimage = $product->product_images->first(); echo "<div class='product_section'> <div class='img_ctr'><a href='{$product->url}'><img src='{$firstimage->url}' alt='{$firstimage->description}'></a></div> <h3><a href='{$product->url}'>{$product->product_name}</a></h3>"; if("$product->product_size") { echo "<p style='text-align:center;font-size:90%;'><span class='product_attribute_label'>Size: </span>{$product->product_size}<span class='product_attribute_label' style='margin-left:1em;'>Price:</span> £{$price}</p>"; } else { echo "<p style='text-align:center;font-size:90%;'><span class='product_attribute_label' style='margin-left:1em;'>Price:</span> £{$price}</p>"; } if ($user->isLoggedin()) { echo "<p style='text-align:center;color:#c00;font-size:80%;'>Hierachy: {$product->product_hierachy}</p> <p style='text-align:center;color:#c00;font-size:80%;'>Category: {$product->categories->title} ({$product->categories})</p>"; } echo "</div>"; }} ?> This displays a list of the individual products under that section as below: The fields called Hierachy and Category in red on the page are only displayed if a user is logged in for admin purposes. That's the part of the code starting if ($user->isLoggedin()). Each individual product is displayed using a template called product_item. <?php //product_item $firstimage = $page->product_images->first(); $priceraw = $page->get("sc_price"); $price = number_format($priceraw, 2, '.', ','); echo "<div class='product'> <div class='col_1'>"; if ("$page->product_images") { echo "<img id='image1' src='{$firstimage->url}' alt='{$firstimage->description}' /> <p>Rollover image to zoom</p>"; } else { echo "<img src='{$config->urls->templates}images/products/image_placeholder.jpg' alt='No image available' />"; } echo "<!-- end .col_1--></div> <div class='col_2'> <div class='product_title'> <h1>{$page->product_name}</h1> <p><span class='product_attribute_label'>Price:</span> £{$price}</p>"; if("$page->product_size") { echo "<p><span class='product_attribute_label'>Size:</span> {$page->product_size}</p>"; } echo "<p class='product_code'>Product code: {$page->product_code}</p> <!-- end .product_title--></div> <p class='product_description'>{$page->product_description}</p> <div class='add_to_cart'>{$modules->get('ShoppingCart')->renderAddToCart($page)}</div> <!-- end .col_2--></div> <!-- end .product--></div> <div class='separator'></div> "; ?> Which give the following layout: And BTW I am using Apeisa's Shopping Cart Module (Thanks Apeisa) There are two main reasons I did it this way: 1. To give the client a product structure they can visually see. 2. I used to run an ecommerce site using Actinic and this is how it's product sections were structured. Whether this is a good or bad way of doing it I don't know but it works for me.

echo $pages->get("myrepeater.field2=bar")->myrepeater->get("field2=bar")->field1; we should make a compilation of soma's one-liners to rival with this https://www.youtube.com/watch?v=GeeyWvo1rNg

The only thing I would add to this idea is that, whilst it's possible to achieve, if you were aiming fir millions of users and many page relationships you would soon rack up a large database so would need to make sure that your PW selectors are well optimised and that your server can handle the traffic. Technically it is possible but if it takes off and you're aiming at tens of thousands of users or above there are some other considerations is all I'm saying

In my huge team of one, I work like Pete - I design away from the final environment, even if that means pencil and paper. The results of that I put into the system. But in reality, just like my proper job of a composer/sound engineer/producer, the system has become very blurred with creative people doing technical jobs and technicians doing creative jobs. When I first started in the seventies, this was only just happening really - there were still the sound engineers who got fussy about non-engineers touching the faders (especially in the BBC which was stuffed with idiotic union members who were not even good sound engineers). But the technology changed this with the result that a lot of professional music is composed at home by untrained engineers - and it is good stuff too! The whole point about languages like PHP is that as natural languages they are meant to be easy to use by non technical users. They are intentionally designed to blur the boundaries to make the design process more coherent. Now, obviously keeping some separation makes debugging much easier and allows for redesign without changing the mechanics, but I don;t think that means there should be no trespassing at all on each others territory. Personally, I don't see a problem with that as long as the end product goes through some QC and fulfils the brief. Also, on a purely selfish note, I am only just beginning to get my head around PW as it is - without learning yet another syntax! (Old brain does not absorb stuff as easily as it used to) Joss

+1 for ProcessBadger (Batcher reminds me too much of he MODx counterpart http://rtfm.modx.com/display/ADDON/Batcher )

if you only have to find THE ONE value on one page you could do this. And this is lovely about PW echo $pages->get("myrepeater.field2=bar")->myrepeater->get("field2=bar")->field1; gn8

I haven't done so much with repeater but this gave me the value I needed. // find pages with a certain value in one of the fields of a repeater item. $found = $pages->find("myrepeater.field2=foo"); echo "found: ".count($found); foreach($found as $f){ // find the repeater item field2 with value foo $r = $f->myrepeater->find("field2=foo")->first(); echo $r->field1; } Depends what field values and type you have, but this does work.

Pete, any chance of a new "like" button. Basically, I want one that says: "I like this. I don't understand a bloody word of it and I cant get it to work, but I do like it." I have needed that a couple of times today.....

Hi Radek, yes you are right, that was needed I has to comment out the line: # RewriteBase / and also my Apache httpd.conf wasn't set right In the FAQ I have found a Thread about how to test for that: http://processwire.com/talk/topic/1-what-is-the-admin-login-url/#entry24096 And yes, I've better should used the search-function before posting this thing Horst

I have nice module to share to make users list more manageable with 1000+ users. I don't remember if I have released it yet though (and on mobile now).

Luis makes it sound easier than it is , but if you have the time it's certainly possible. Here are two examples of how to implement "adding friends" and "articles wall" just to give you an idea (written in the browser from my mind and very very very over simplified): //adding a friend $new_friend = $pages->get("template=user, name=$input->post->new_friend"); //assumes that a friends field of page type with all other users was already added to the users template $user->friends = $new_friend; $user->save; //outputing a wall of articles only from the user and his friends //creating a string with all the friends separated by a pipe character (OR) to put in the selector $friends = ""; foreach($user->friends as $f){ $friends .= "|" . $f; } //find the articles from the user ($user) and his friends ($friends) and render them echo "<div id='wall'>"; foreach($pages->find("template=article, created_users_id=$user$friends") as $a){ $a->render(); } echo "</div>"; edit: modified the second example to use the buit in selector "created_users_id".

I am also in a need for a feature like that to convince a customer to do the switch. I got used to it with Drupal 7 ("diff"-module) and did not experience it slowing down things, or to be über-complex. http://drupal.org/project/diff Cool stuff. It wasn't too complicated so, a.f.a.i.k. it is limited on node text and title fields. You could easily navigate the versions, see all (text) differences highlighted and could roll back (which means that a new version is created with the content of the selected older version, so you could even revert that change later). Anyone knowing this module? Maybe this is a route a processwire module could go as well.

Currently there isn't a way (that I know of) to have different user types. Meaning, whatever fields you add to your 'user' template are going to be present for all users. However, you could always create other templates with whatever fields you need, and then relate them to the users via Page references. You could also use tabs or collapsed fieldsets to hide sections that aren't applicable to all users. In terms of navigating in the admin: ProcessWire admin is nothing more than a website written in ProcessWire. If you think of it that way, you can swap out of any of it's components (Process modules) or make your own templates that display exactly what you need. You can add a new page in the admin just as easily as you can add a new page on the front-end of your site.