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

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."

Wow. I did not expect this much response. I think it says a lot for the community and the passion behind Pw. As I mentioned, I am very new to Pw so it is possible that once I get to know it better I will agree that a template language is completely unnecessary. Also, I have no problems with it being a module that can be loaded if needed. I certainly don't think it needs to be in the core. So, if there are modules that already exist then I am satisfied. For example, I hate TinyMCE is totally screws up my code. So, I don't use it, but it is there for those that want to. That is one of the things that I see with Pw that I like. Thanks for all the feedback and comments! Now, for my own enlightenment, I am interested in where you all draw the line between Design and Development. In my current situation, my designer knows HTML and CSS (he obviously knows design too). So, in my thinking, that is the demarkation point. I should not need a copy of Photoshop to develop and he should not need to load debugging tools, etc to design. He provides clean HTML/CSS and I fill the templates with data. That is why I feel it is important that the designer can modify the templates and not just hand them off to me to implement. The user is expected to handle the data so why are we keeping the designer away? Is this not a 3-way partnership? I know that some of you are one-man shops and totally capable of doing it all, but I am trying to understand this from a small team perspective. I have done the last few sites in MODX Revolution and the designer was fine with being able to modify the templates and leave all PHP to me. If he needed something specific, he could ask and the same for me. The user just entered the content. It seemed to work well and balance out the work. My musings... I will probably look back on this message and laugh at my Pw naivety. It's all good and thanks again for being so responsive and open. Anthony

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

Hi, kawaramono.cz is little presentation web for my friend made with PW. Pretty simple solution with full content administration, zurb foundation framework and colorbox.

I can't seem to get it working on my local linux test box. Pretty much default installation. Templates and field selections are empty. "Enable for these fields" field first allowed for selections, but after revisiting the module page those selections were gone and nothing could be selected anymore. "Enable for these templates" was always empty. Fieldtype selection has these options available and nothing selected: FieldtypeFieldsetClose FieldtypeFieldsetOpen FieldtypeFieldsetTabOpen Both database tables remain empty.

Fresh install of 2.2.15, everything OK. Only one minor thing seems a bit off, and that's not really related to "technical" aspect of installation: After installing there's this list of important steps to take. Is it just me or does it signal that "this is nothing you should worry about", you know, with light green backgrounds and check marks and all? This was second time ever I've ran the PW installer (usually we do it by duplicating old sites, for various reasons) and I nearly failed to notice that there's still something (rather important) to do.. Apache 2.2.22 PHP 5.3.10-1ubuntu3.5 (Suhosin v0.9.33) MySQL 5.5.29

Yes, I think this makes sense. I'll duplicate them there.

Martijn, In the moment I'm my own boss so this is possible Go ask yours, just mention that you have the best ideas while drinking beer! What did he say?

@wanze, You drink & develop on the same time ? If it pleases you, maybe I'll ask my boss if I could do the same.

Great module Wanze! Thanks for making this. Definitely going to come in handy.

Teppo, this is really a fantastic proof of concept! Very well put together and seems very much fully-functional to me. Worked great in my testing here. It actually seems like much more than just proof of concept--it's quite stable! Thanks for your great work here. I look forward to seeing this evolve. Let me know anything I can do to help. This is a great addition and perhaps something that should find it's way into the core. A couple of minor optimizations to mention, at line 263 of the main module: // $page = $this->pages->get((int) $this->input->get->id); $page = $this->page->process->getPage(); // if (!$page || !in_array($page->template->id, $this->enabled_templates)) return; if(!$page || !$page->id || !in_array($page->template->id, $this->enabled_templates)) return;

Just updated Pw from 2.2.2 > 2.2.13. No problems, no errors, everything works as expected. Point 6: Having a beer now, cheers

ProcessWire is actually the first iteration of this CMS that doesn't rely on a template engine. And Dictator CMS (the grandaddy of ProcessWire) was entirely template engine based, with no PHP API or PHP support at all. I'm no stranger to template engines. While there are benefits to template engines, my own experience has been that the benefits are largely perceived rather than experienced. There are also some tangible benefits too. But how many of those tangible benefits apply varies greatly from system to system. ProcessWire has a nice API, but most CMSs do not. For many of those CMSs, the template engine is what makes the system accessible (or at least, more accessible). Expression Engine is an example. In those systems, template engines are providing a huge benefit by isolating the developer from having to use a complex or crappy API. Nobody would use these systems without the template engine. But in a system like ProcessWire, a template engine is redundant, less capable, and ultimately more complex layer of overhead. Most of the time, we do not want that kind of extra overhead in ProcessWire. In our context, the only real benefits of a template engine are if you have some kind of syntax preferences (PHP is not always the prettiest syntax) or if you want to have a jail. There are some valid reasons to have a jail, as pointed out earlier… but I prefer education to jail. Still, I understand the reasoning and can't say it's always wrong. Just that it's wrong for a core default. There's also that benefit of perception. If one perceives there are some other benefits to a template engine, they will seek out systems that have them, even if perception isn't always reality. I believe strongly in the benefits of our current approach and API. I feel these benefits are far greater than what comes from any template engine. And I've discussed them at length many times in many places, so I won't rehash that all here. But I've always wanted ProcessWire to support template engines, just not to require one. So I like what I see with the Twig and Smarty modules. Actually, the Smarty module seems like it would be especially simple to work with, since it bolts in so quickly and easily. I hope to see more in this area and am always willing to do whatever it takes to support add-on template engines (we even added a hook or two to support the Twig module). While I personally don't need these template engines and sometimes question their value, I also very much support them in ProcessWire as modules. Perception is powerful, and we're trying to grow our audience. Likewise, there may be some that have template engine preferences beyond just perception. Anything that opens a door for more people is a good thing. While ProcessWire's core isn't and won't be built around a template engine dependency, we fully support use and implementation of them as modules. And I'm also willing to add any new core hooks or capabilities necessary to support the development of such modules.

Ryan I did this Well I double-check my copy paste ninja skills tomorrow and give it a New try

Hi luzox, not sure where's the problem? You can e.g. use the Markup Simple Navigation module. There you have a lot of config options. Create a navigation.inc (simple example of a site I build). Take a look at the docs of the module for the options. <?php $treeMenu = $modules->get("MarkupSimpleNavigation"); // load the module $options = array( 'current_class' => '', // string (default 'current') overwrite current class 'max_levels' => 1, // int (default null) set the max level rendered 'outer_tpl' => '<ul id="navi">||</ul>', // template string for the outer most wrapper. || will contain entries 'item_current_tpl' => '<strong>{title}</strong>' // template string for the current active inner items ); echo $treeMenu->render($options); // render menu ?> Then put something like this in the place, where you need your navigation to be: <?php include("./navigation.inc"); ?> Make a first try without options, to see what the modules output looks like. Then fine tune your options.

I used to use a shopping cart software and I thought if I give you some of the set up options from that, it might help you configure a module for PW. First see attached document that shows the basic tax set up for that software. Some of the main set up selections are listed below: TAX MODE Simple or Advanced (select one) SIMPLE TAX Enter a description e.g VAT Enter a message e.g VAT payable on all UK orders Enter a % Rate e.g 20.00 ADVANCED Product Prices Entered Price inclusive of tax or Price exclusive of tax (Select one) Taxes Enter name e.g VAT Tax Rounding Level - Line Item Order (select one) Tax Rounding Method - Truncate, Round Half Down, Standard, Round Up, Banker's Rounding (select one) Tax By Location Always apply taxes, Tax by delivery address, Tax by Invoice address (select one) Tax Zones Add a Zone (you can add multiple zones) - Enter name e.g UK, select countries to be included in that zone e.g England, Scotland, Wales, Northern Ireland and save it. Then in Shipping and Handling section you would select shipping charges made - yes or no. If yes, choose the Tax Rate e.g VAT (as defined in Taxes above, Zero Rated, Exempt, Custom. If custom is selected enter custom rate. Select if handling charges are made. If yes, select Tax Rate (same as for Shipping selection). Then we get into Shipping configuration e.g Simple or By Zone and Class. That's a bit more complicated e.g Simple is a fixed charge e.g. 5.00EUR, By Zone and Class uses various methods like by weight classes and you can set up different postal charges e.g UK - First Class UK - Second Class UK - Standard Parcel etc. There's more info here I hope that helps. Let me know if you need any clarification. tax_set_up.doc

Haha, i've got no probs with batcher....just joking...most important thing is what it does Other options: PW_BulkEdit PW_Bulker PW_MassEdit

Thanks guys, let me know what you think and how I could improve the module. Some possible actions to add: - Change User - Change Created-date @SiNNut To be honest, I knew that modx had a Tool called Batcher. I was thinking some time of a good name and finally decided to name it Batcher too, not very creative I know Batchman was another idea, based on Anti's Trashman. My concern is that if someone sees the modules title or searches for it, the current name is more suitable than badger? But I'm open for every suggestion, so maybe we can collect some ideas and make a poll?

Mr. Log is on fire!

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

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.

Badger or batcher?

Thanks Ryan - I think i will use the redirect template idea for some things..Right now there are no multiple URLs, everything is well organized in the page tree, diescrreet now you're giving me some ideas about how to improve this – right now the products are arranged heirarchially under one parent, and then 4 'categories' with all of the products under each of those; But now i'm thinking that ALL of the products should have the same parent, i think this will make it more flexible to show search results.. then i guess i'll use URL segments for the product category, application, name etc...if i do it this way, there will be multiple URLs to the same page, but i could then use canonical URLs;

I have a 2006 Mac Pro that still is chugging along just fine as a primary. A dual xeon running 6TB with a 512 SSD for boot and apps. Has 16GB and I upgraded the video for the Apple 30" and 24" . Both need to be replaced now the colors are shifting and not accurate enough anymore. Good work space though. Have a 17 MBP for mobile. Have considered getting a new 15, and running dual 27's via thunderbolt but can't make up my mind between that and waiting for the new MacPros due this year. Regarding a raid array, while you can have redundant storage in a raid box, you need to have a redundant backup of whatever your primary storage is (think theft or natural disaster). I archive off an external raid array out to 2TB drives that go off site. Hot files are backed up to the cloud. Why so much data? I have alot of media (raw image files from photography and video) that needs to be archived long term. I grew up on Unix (BSD and Solaris) so when OS X was released I moved my personal computing over from MS platforms. Now I have my cake (unix under the hood) and can eat it too (apps).

A simple rule to remember is: Any data input from the user needs to be entity encoded before outputting it back to a browser. What is entity encoding? It means taking some special characters and converting them to a format that isn't interpreted by the browser as anything but text. We care primarily about characters used for tags, like "<" and ">", characters used for single or double quotes (especially when values might end up in HTML tag attributes), and ampersands "&". These are the characters that can mean something more than just text to a web browser. But you don't even have to think about this if you just remember to entity encode any output. There are cases where you don't have to entity encode, like if you've already typecast something as an integer, or already run it through one of PW's filtering functions that removes special characters... $sanitizer->pageName() is a good example. But if you want to play it safe, just entity encode everything you are outputting back to the user... there's no harm in it. One way to tell if entity encoding is working is to enter a value like "<b>test</b>" in your form field. When you get it back, if it reads as test rather than <b>test</b>, then you've got a problem. No. $sanitizer->text() filters input for storage, not for output. It limits length and prevents linebreaks, among other things. While it strips tags (unless you tell it not to) it doesn't entity-encode any characters. The reason is that you don't usually want to store entity encoded text, unless it's meant to be stored as markup, like TinyMCE (in which case, none of this applies). So ideally, your sanitization would go something like this: // these values are for API use or storage $firstName = $sanitizer->text($input->post->first_name); $lastName = $sanitizer->text($input->post->last_name); // these values are for output back to the user $outFirstName = $sanitizer->entities($firstName); $outLastName = $sanitizer->entities($lastName); // you might prefer to bundle these into an array When it comes to outputting values that came from the user, the $sanitizer->text(); is certainly a good idea, but it's not required. It's not going to make the text any safer for output than $sanitizer->entities(); will on it's own.

With Processwire there are no directories in the admin. It is all pages. Pages can be used for anything (not just a page full of information). They can be used as a placeholder, or an option for a select (using the page field), or as an actual container for data. Your articles are pages, your categories are pages, your tabs are pages. What makes them different is that you would use a particular template to reflect what that page needs to achieve. Those templates may not have a template file associated with them - you only need to do that if you are formatting the data held in that page AND calling the page directly. (You can get information from another page by using $pages rather than $page) All pages do have relationships to parents and children, and using their template, you can dictate how that relationship works. For instance if you had a hidden page called "Posts" under home, and it had a template called "Post-Placeholder" which had no fields other than the title field, then you can set the template so that any children of "Posts" had to have a particular template - your "news" template, for instance. So you can limit the choices to make the system more manageable. It is up to you what a page is pretending to be, if you like! Just play with multiple pages and templates and you will soon see how you can relate them together and therefore how you can design just about any structure you need.

Since Yellowled also knows MODX very well (hi btw ) I just want to give my two cents to the topic with some MODX comparisons. In MODX you usually have snippets which do the logic an chunks which do the presentation. In PW you either define the logic yourself (often foreach over a set of pages) or have modules which do that for you. For the markup there seem to be several approaches. Soma showed two of them, echoing the markup right in the template and rendering external templates. While I don't like the "echo"-approach (it just looks ugly) the render() afaik can only render page templates. So I tried something different and to my surprise (well, not really) it works well. You just can organize yourself like in MODX. I even called my folder for mini templates "chunks". For example in my current project (my portfolio) I have a list of client work stored in a folder with an own template (for assigning the fields). This reference template has no own .php file, because they are not shown on a single page (it is a one pager). I have a overview list with some thumbs and then more details on every item later: <section id="references"> <article class="overview ref active"> <?php $refs = $pages->get("/referenzen/")->children; $count = 0; foreach($refs as $ref) include("./tpl/overview.inc"); ?> </article> <?php $count = 0; foreach($refs as $ref) include("./tpl/ref.inc"); ?> So basically I just loop over my references and "oldschool" include my chunk which looks like this: <? if($count != 0){ ?> <div class="screenOverview imgContainer ref<?= $count ?>"> <picture class="c" data-nr="<?= $count ?>" alt="Screenshot von <?= $ref->title ?>"> <!-- <source src="<?= $ref->image_c->width(384)->url ?>"> --> <source src="<?= $ref->image_c->width(384)->url ?>"> <!-- <source src="<?= $ref->image_c->width(550)->url ?>" media="(min-width: 1000px)"> --> <source src="<?= $ref->image_c->width(550)->url ?>" media="(min-width: 1000px)"> <!-- <source src="<?= $ref->image_c->width(650)->url ?>" media="(min-width: 1280px)"> --> <source src="<?= $ref->image_c->width(650)->url ?>" media="(min-width: 1280px)"> <!-- Fallback content for non-JS browsers. Same src as the initial source element. --> <noscript><img src="<?= $ref->image_c->width(550)->url ?>" alt="<?= $ref->title ?>"></noscript> </picture> </div> <? } $count++ ?> (using the picture polyfill in this case). So this means: you can just include any file and stay better organized. The variables are assigned and you even can reuse these "chunks". In the second loop I iterate again over the references and build something different (with description and such) with a different "chunk". Works pretty well and lets you keep well organized.