SteveB

I'm thinking of using this. Can anyone suggest a fairly representative and recent blog site based on it which I can show my client? I realize the best answer is probably to spin up a new site but something real might make more sense to them. Thanks!

What's grab.pw?

Hey mrkahn, I ended up needing the kind of thing you're talking about for a simple image gallery. Each image is a page and this code goes in the PW template file rendering the page the images are parented to. function albumRows($pages, $perRow){ $out = ''; $rowCt = ceil($pages->count() / $perRow); for($i = 0; $i < $rowCt; $i++){ $out .= PHP_EOL.'<div class="block-group album-row">'.PHP_EOL; $out .= albumRowItems($pages, $i, $perRow); $out .= '</div>'.PHP_EOL; } return $out; } function albumRowItems($pages, $rowIndex, $perRow){ $out = ''; $index = $rowIndex * $perRow; $row = $pages->slice($index, $perRow); $i = 0; foreach($row as $page){ $img = $page->image->size(110,110); $out .= ' <div class="b'.++$i.' block">'.PHP_EOL; $out .= ' <a href="'.$page->url.'"><img src="'.$img->url.'"></a>'.PHP_EOL; $out .= ' </div>'.PHP_EOL; } return $out; } if($page->hasChildren){ $content .= albumRows($page->children, 5); } Along with that I'm using Pocketgrid.css (just great, look it up) with these few additions: .block > a > img { border:1px solid #AAA; } .block > a { border:none; } /*five per row*/ .b1, .b2, .b3, .b4, .b5 { width: 20%; } /*tweak the grid spacing*/ .album-row { width:600px; line-height:1.5em; } Hope that helps.

Sometimes during a migration people have second thoughts and want to make some adjustments after redirects are in place. How about an option to redirect as 302 for a while (think of it as a probationary period) before automatically converting to 301 (so we don't forget).

Excuse me for butting in... Whenever I see that I imagine what a client would make of that answer. Eventually I'll have to solve this for an existing client with very specific ideas about how keywords should work. The current site (not PW) gives power users a choice of searching based on whole words, partial words, or phrases, and ignores certain punctuation characters (there's a whole list of things, some more idiosyncratic than others). The code builds some pretty ugly looking queries but it's not a high traffic site and performance is fine. I'm hoping to find some kind of API friendly way to add support for options like that. If anybody has any thoughts about this (or more ambitious things such as stemming) please send me a message or post here if relevant to Davo's question. Thanks.

I was making a point about letting the unwinding of nested function calls help with your tag closures but you don't have to take it to extremes. Take your example of HTML that works and indent it to see structure/repetition much more easily (see below). Where there is a lot of repetition there is more of a case for using a function. Looking at the indented code, I'd start with two functions. You get the stuff to display as a PageArray using: $children=$pages->find("template=product,product_cat=1014,show_main>0"); The thing I see being repeated a lot is for each product-block. Markup to display one product's attributes. Each grouping of those has a simple wrapper surrounding it which is a couple nested divs (item and row). Make a function to do the item and row divs. Pass it $children and since you want to do products in groups of four pass it an index and a quantity (4). It can test that to tell whether it should use the "active" class and it can use the index and quantity to pick pages to be displayed from of the $children PageArray. It will use another function multiple times to produce the items and then it will close the item and row divs it started. Make a second function for the first function to pass a product page to. This will make the markup for that one product, starting with div class="span3 product-block" inserting the data from the product page, and closing the divs for the product block before returning. Your foreach loop can then call the first function, incrementing the index, until it runs out of pages. You could have the first function help out by returning either the next index to use or false if there are no more products and it's time to stop. I left out making the "carousel" markup around each "row" but it's just more of the same idea. <div class="carousel-inner "> <!-- repeat --> <div class="item active"> <div class="row-fluid box-product"> <div class="span3 product-block"><div class="product-inner"> <div class="image"> <a href="#"><img alt="Loves or pursues" src="products/image-4.jpg"></a> </div> <div class="wrap-infor"> <div class="name"><a href="#">Loves or pursues</a></div> <div class="description">Samsung Galaxy Tab 10.1, is the world's thinnest tablet, m...</div> </div> </div> </div> <div class="span3 product-block"><div class="product-inner"> <div class="image"> <a href="#"><img alt="Loves or pursues" src="products/image-5.jpg"></a> </div> <div class="wrap-infor"> <div class="name"><a href="#">Loves or pursues</a></div> <div class="description">Samsung Galaxy Tab 10.1, is the world's thinnest tablet, m...</div> </div> </div> </div> <div class="span3 product-block"><div class="product-inner"> <div class="image"> <a href="#"><img alt="Loves or pursues" src="products/image-6.jpg"></a> </div> <div class="wrap-infor"> <div class="name"><a href="#">Loves or pursues</a></div> <div class="description">Samsung Galaxy Tab 10.1, is the world's thinnest tablet, m...</div> </div> </div> </div> <div class="span3 product-block"><div class="product-inner"> <div class="image"> <a href="#"><img alt="Loves or pursues" src="products/image-7.jpg"></a> </div> <div class="wrap-infor"> <div class="name"><a href="#">Loves or pursues</a></div> <div class="description">Samsung Galaxy Tab 10.1, is the world's thinnest tablet, m...</div> </div> </div> </div> </div> </div> <!-- repeat --> </div>

Just for your own sanity break the code into functions where each one is responsible for opening and closing a tag it creates. Pass info to outermost one, it starts a DIV (whatever) and passes info to another function (drilling down in a nested way) then closes the DIV it started. All the opening/closing of the tags works out by itself as the functions return. It's easier to test. Each function handles one level of the nesting and has the tests (logic) and tags (markup) that happen at that level.

Maybe I'm overreacting but a few of Woop's comments seem to value seductive sales/outreach style of presentation over efficient transfer of information. We need both but they are not interchangeable. readme.md - "Not a very welcoming start" I don't see it that way at all. When I see a readme file that traces back to a version control repository I feel pretty confident that I'm looking at up to date info that's actively maintained, probably by someone with first hand knowledge of the content. Also, one page of clearly organized text is so much more accessible and easy to grasp than having to slog through whitespace, logos and blather like "we create something beautiful together" to find kernals of truth for my project notes. The thing about all of this documentation and user interface stuff is that it's a huge amount of work to communicate effectively to different audiences and keep it up to date and error free. I hope we can create an environment where glimpses of underlying complexity or unfamiliar terms is not off putting to new or not very technical users and they have the tools to find out what they don't already know. Reference and how-to information about Processwire exists but the fact that it's scattered in different places (including this forum) makes finding it a little tricky. Wouldn't it be great to have a Processwire powered knowledge base kind of thing that we could throw all that into? We already have the API cheatsheet. That kind of drill down treatment could be applied to tutorials and snippets too. Maybe we could work out a clever bot to mine the forum posts and link some of that content in as well. Hard to know where to begin (or end) with that kind of thing.

The devil is in the details. To make something complete and ready to use it has to come along with a lot of baggage which can actually make it harder to figure out what's going on. You cant easily tell the essential stuff that makes the gallery or whatever special apart from the stuff that's just there to make it a complete example. There are tools though which are getting better all the time and will make it easier to have your cake and eat it too. The ProcessMigrator module "Allows automated migration and sharing of page tree content along with their templates and fields via JSON files. These JSON files can be imported into another PW installation to recreate the entire structure and content, including files and images." The Upgrade tool Ryan's put out very recently will also be a help to new users. Currently people are pretty good about supplying some cut and paste code you can use to do a quick test. That's fine if you're comfortable with PHP and the DIY aspect. I'm picturing a near future where people publish a module and provide the ready to use examples you want as content you install with the migrator or something like that.

Thanks Horst. I found 2 small but important goofs and it's all fixed now. I need to test a bit more and decide about features that are not in the base class. As has been pointed out already that could get messy as these modules proliferate. As far as Cc and Bcc, this one is like WireMail in that it passes the list of email addreses to SendGrid which sends each recipient a separate email so the recipient won't see anyone else's email address.

I'm working on a WireMailSendgrid module to send mail out through sendgrid.com. The module has settings for the Sendgrid credentials and a path pointing to some handy PHP code provided by Sendgrid (their "sendgrid-php" library for working with the API). I still have some features to build out but it works when I use it like this: $mail = new WireMailSendgrid(); $result = $mail->to('steve@foo.com')->from('test@foo.com')->subject('WireMailSendgrid test message')->body('Message Body')->send(); Okay, those aren't the real email address but with real ones it works just fine. Q: I've read in the first post: "give it no arguments, and it'll return whatever WireMail module is installed." How does that happen? Aside from installing my WireMailSendgrid module is there another step? I don't see how core's WireMail would know to use it. If I do the above test using $mail = new WireMail(); instead of $mail = new WireMailSendgrid(); it doesn't use my module. I have statements in the construct method which write to a text log so it's easy to tell. By the way I'm doing the tests on a fairly empty Processwire site which was 1.4 and then upgraded (with ProcessWireUpgrade) to ProcessWire 2.4.18 dev. PHP is 5.4.23. Thanks in advance.

Ryan this is a great convenience! It worked well for me today (from 2.4.0). The only thing I would suggest is merely a cosmetic thing. The page of output it generates while doing the update is a little mysterious until you scroll down. When I first looked at it I thought something might be broken. It doesn't look like the admin pages which is fine but maybe it should spit out a heading first that says "Processing upgrade:"

This is not a question about the module specifically but if you're using Piwik perhaps you'll know something about the problems I ran into today. I had no luck with Piwik for some reason. It seemed to install okay, I found the info I needed for this module's settings and put the Piwik generated tracking JS on my pages but after visiting a few pages nothing was getting added to the Piwik database so there was nothing to report. That's when I stumbled upon an issue with Piwik and eAccelerator. In the Piwik admin there's a page for Diagnostics where it says "You are using the PHP accelerator & optimizer eAccelerator which is known to be not compatible with Piwik. We have disabled eAccelerator, which might affect the performance of Piwik. Read the related ticket for more information and how to fix this problem." Really?! In what context? I'm using PHP5.4 and eAccelerator. The hosting company suggested eAccelerator over APC and eAccelerator's home page says it is compatible with 5.4 but as recently as 5 weeks ago Piwik is saying "eaccelerator is not supported anymore and Piwik is not compatible with it." Haven't found much in the web about this. Any clues?

Some brief feedback after using this module (V 3.1.3) on a project with PW 2.4. All in all a great tool for reducing page load times. There's an issue about this on Github and it will probably be addressed once the developer gets back from a trip but it took me a while to find so I'll mention that the cache ids are made from the modtime of the file(s). If you FTP files which arrive in the same second they will try to use the same cache file and your pages will be a mess. I suggested a fix. When using dev tools in browsers to inspect elements and peek into CSS files you'll be seeing the cache file filenames (md5 gibberish). I made a small modification to list the file path(s) at the top of the file. Sort of contrary to minifying but useful. EDIT: This idiom comes in handy to minimize only files in a certain folder. I do something just like it for 'styles' too. This way if I put URLs to external popular libraries (already minimized) in $config scripts they are left alone: foreach ($config->scripts->unique() as $path){ if(preg_match('#^'.$config->urls->templates.'scripts(.*)#',$path,$m)) $path = AIOM::JS('scripts'.$m[1]); echo ' <script type="text/javascript" src="'.$path.'"></script>'.PHP_EOL; }

Well, not by most users, but the users who might want to hack your site could easily build a request containing something nasty.

Here's my way of organizing AJAX. It's just another way of doing it. There's a module with some functions for handling AJAX requests. Mine's called 'fjax' and has some extra code for optionally sanitizing arguments to the functions. There's a 'fjax' template too. The fjax page (using fjax template) can be very minimal. I suggest putting it in /tools/fjax/ and setting tools as hidden. Having a Page gives us a handy URL to send requests to and the template file becomes the place to put the application's server-side AJAX code. The fjax template doesn't need anything more than the required title field. On the client side we use jQuery's AJAX tools. If you POST the data, use the query string on the URL to indicate the function you want to call (tools/fjax/?fn=function) and the module will simply pass the POST array to the function and return the result JSON encoded. If you use GET you pass the arguments on the query string too (tools/fjax/?fn=function&arg1=foo). In the template file you have 5 lines of code plus your function definitions. It's a simple PHP file so you can easily pull in code from reusable files etc. The fact that it's used with a Page means you can use Page fields as easily configurable data for your server-side AJAX functions.

I did something a long time ago where I integrated, somewhat, a forum with a website by adding a bunch of Ajax. That way they were separate but communicating with each other and my mods seemed less invasive tha way. I think I had an I frame so they could both be on screen at once. Just a thought.

Just FYI, include really isn't a function This does work, nothing wrong with it: include('form.inc'); But this is at least as good and 2 characters less: include 'form.inc';

Great progress! I haven't tried the new features yet (maybe this is covered already) but it might be handy to have it spit out a list of any template files it moves. That would be to remind us to manually move over any include files or other resources those files depend on.

FYI, Twig syntax has support for conditional expressions, loops, etc. Look for clues in the TemplateTwig README.md file which also mentions using the Template Data Providers module to prepare data for the template.

Re. "However, you'll want to make sure you've got some good security through obscurity (obscure URL), and/or a GET/POST variable pass key or something to ensure nobody else can trigger your script except you." Assuming your intended way to run this is via cron job on the same server, have your PHP check that REMOTE_HOST equals LOCALHOST

Congratulations! After fretting over it for nine pages I'm glad it turned out well.

Marco, do you have any pointers on how best to use Twig as a tool within the normal PW templating system? I want to have some of my PW template files prepare data, specify a path to a Twig template file and then invoke Twig to insert the data and return the result. I don't want Twig to be the default way of rendering pages. Thanks. Edit: I guess my question is really whether your module can be used in that way or should I just make something much more basic. Answer! I answered my own question. Porl's TemplateTwig module turned out to be perfect for what I'm doing. I just made one small change to point it to a newer version of Twig than the one distributed with the module. This is part of a larger MVC-ish scheme, part of which is just like Apesia's Template Delegate approach using PW's TemplateFile class. In templates/markup/layouts/ I have the TemplateFile PHP file ('whatever.php') which, depending on what needs to be done, can prepare variables and echo them out directly or pass them in an array to Twig which will look for a similarly named file ('whatever.php.twig') of twig markup. Just to make things easier, the system behind all this passes that 'twig' filename to the TemplateFile class file so all it has to do is prepare an array of data and then: echo $page->twig->render($this->twig, $arr);

Thinking outside the box. I love it.

Ditto. I'd like to hear more about using PW back end features to their best advantage, for a nice workflow.