adrian

Hey Joss, Did you find the share option in Pydio? It is awesome - you can right click on a file (zip if you like) and share it with a unique url which gives them a one click download - no password required. I have Pydio hooked into a parent folder that is above web root so the files are not directly accessible, but I can still map the folder as a drive (SMB etc), so we have multiple ways to access the same stuff. You can set up user accounts with all sorts of access levels. It's not perfectly bug free, but it is still the best tool I have found that allows me to manage our own server and still share files very easily.

Played with it some time back - not sure if it has matured further, but worth a look: http://sparkleshare.org/ Also, Pydio now has a sync tool - again, not really ready for prime time, but their web interface is a great way of sharing files with clients: http://pyd.io/ Or if you are a linux geek and want ultimate configuration: http://www.rsnapshot.org/ (you could of course use cron and rsync, but this is a nice addition to managing things)

Not sure about the 500 error, but have you made sure to get the new version of the modules manager? Before you upgrade to it, you need to install this module first: http://modules.processwire.com/modules/jquery-data-tables/ Hope that fixes things for you. EDIT: Just reread what you wrote and I see that you have already installed the latest version of MM. I don't think it would install without jquery-data-tables so that probably isn't the issue afterall. Sorry for the bad advise

Alternatively you could use this line in the module to send the 404 Page Not Found body to the search template echo $this->page->render($this->pages->get($this->searchPage)->template->filename, array('q' => $term, 'out' => $this->page->body)); and have it output in the search template using: if(isset($options['q'])){ $input->get->q = $options['q']; $out .= $options['out']; } Lots of options really

Just had a thought for a slightly better version. I replaced this: echo $this->pages->get($this->searchPage)->render(array('q' => $term)); with: echo $this->page->render($this->pages->get($this->searchPage)->template->filename, array('q' => $term)); which seems a little cleaner. This change also means that now you only have to add just the one line to your search.php file: if(isset($options['q'])) $input->get->q = $options['q']; No need to change the page title anymore because we are actually now still rendering the 404 page with it's existing fields, just using the template file of the search page. However, I also added the 404 page's body to my search.php file: if(isset($options['q'])){ $input->get->q = $options['q']; $out .= $pages->get(27)->body; } With this approach you can easily then edit the body field of the "404 Page Not Found" page in the PW admin to read something like this: <h3>The page you were looking for is not found.</h3> <p>We have tried to find the content you were looking for, but if we didn't get it right, please use our search engine or navigation above to find the page.</p> Any thoughts on this new version, or the approach in general? Any problems from anyone who has tested it?

Ok, here is something I'm not exactly proud of, but I really don't have anymore time right now, so I thought I'd post anyway in case it inspires someone else to come up with something better. This is the key line that shows you how things are working: echo $this->pages->get($this->searchPage)->render(array('q' => $term)); This way, there is no redirect, so the http headers still return a 404 status code, so I think this solves the SEO issue. There is a new config option that lets you choose your search page, so that should take care of the issue kongondo brought up. With this new version,you need to add this line to the top of your search.php file if(isset($options['q'])) $input->get->q = $options['q']; Or this if you want the title on the search page replaced: if(isset($options['q'])){ $input->get->q = $options['q']; $page->title = $pages->get(27)->title; //27 is the ID of the 404 page that comes with PW } Anyone have any brighter ideas? PS Due to the use of render($options), you need PW 2.4 or a recent 2.3 dev version.

Good point Soma and now I better understand what you are thinking @cmscritic. Agreed - this shouldn't redirect to the search page. It should load the 404 page, but populate it with content from the search results. Will have to rethink for sure!

I knew the issue of wanting to configure the path to the search page was going to come up This was supposed to be a quick response while procrastinating from real work! Give me a few minutes!

Ok, how's this work for you? http://modules.processwire.com/modules/process404-search/

Maybe just replace slashes in the url with + and send those terms to the search page? Sounds pretty simple to achieve. Not tested ... $this->addHook('ProcessPageView::pageNotFound', $this, 'search'); public function search($event) { $request = parse_url($_SERVER['REQUEST_URI']); $path = $request["path"]; $result = trim(str_replace(basename($_SERVER['SCRIPT_NAME']), '', $path), '/'); $result = explode('/', $result); $term = implode('+', $result); $session->redirect("/search/?q=$term"); } Might be more things to consider. Maybe no real need to explode/implode. Maybe just a str_replace('/','+', $result), but you get the idea.

Interesting - I was wondering about that choice of logo size and position - I thought Ryan was being artistic! I just did a hard reload and it is now in the right spot and right size, and those buttons are missing

That is weird - nice button shadows though Still, looks fine for me.

Not yet: http://processwire.com/talk/topic/1390-repeater-module-title-of-item/ http://processwire.com/talk/topic/4826-custom-repeater-field-input-title/

Yeah, what happened to your menu header? It's there for me, along with the new logo.

I think this is what you are looking for: $datetime = strtotime("2014-03-01"); $sp = $pages->find("modified>$datetime"); foreach($sp as $p){ echo "<p>{$p->title}</p>"; } Just swap out modified for created if that's what you want.

Well it sounds like you are only after those templates with a template file. Actually can't think of how to do this with a selector right now, but you could find all parents of the page and then foreach through these and do a: foreach($page->parents as $parent){ if($parent->viewable()) { echo $parent->title; break; } } https://github.com/ryancramerdesign/ProcessWire/blob/03387f8283d518e9cc405eff8f05cd6a5bf77c4c/wire/modules/PagePermissions.module#L166 The will not only check to see if there is a template php file, but also check to make sure the user has view permission for the template. I haven't tested this, so I am not sure if the echo page title will be the closest parent or not, but hopefully it might get you going in the right direction?

Really great writeup teppo - I feel like this should be posted somewhere upfront. As you so eloquently stated it really is PW's ability to use pages and custom field types with the selector engine, but then if you really need it, it's not difficult to integrate full custom database tables with SQL queries. It's that combo that sold me too!

Sorry about that - I did have a quick look for that, but missed it. Apparently I wasn't searching with: http://processwire.com/talk/topic/4510-field-type-json/?p=44317

MVC Options: http://modules.processwire.com/modules/spex/ http://processwire.com/talk/topic/4892-an-almost-mvc-approach-to-using-templates/ http://processwire.com/talk/topic/3587-templates-mvc-recursion-etc/ http://processwire.com/talk/topic/5031-get-started-with-pw-mvc-module-by-harmster/ A few links to get you going on understanding what a page really is: http://processwire.com/talk/topic/5059-2-question-about-pages/ http://processwire.com/talk/topic/5325-database-table-versus-pages/ http://processwire.com/api/variables/pages/ http://wiki.processwire.com/index.php/Page_Field

Well assuming keywords and license are in the same format, have you tried foreach'ing through $license like you did with $keywords?

http://processwire.com/talk/topic/5660-form-builder/

Great idea Steve - I'll do that for sure. Done and committed!

Several of the outstanding issues and a couple of bug fixes have been taken care of this morning. Be sure to grab the latest from Github EDIT: Even more issues taken care of this afternoon. Updated in post #47 above.

No problem at all. I learned some things along the way Speaking of which, here is a much more concise version of the script using the ImageSizer approach I picked up from Soma at some point: $cp = $pages->get(1157); $cp->of(false); foreach($cp->fields as $imagesfield){ if($imagesfield->type == "FieldtypeImage" || $imagesfield->type == "FieldtypeCropImage"){ foreach($cp->$imagesfield as $image){ $ImageSizer = new ImageSizer($image->filename); $ImageSizer->resize($imagesfield->maxWidth,$imagesfield->maxHeight); } } } As for the memory issues. If it's just max_execution_time that should be an easy fix. If it is also memory related then you might come up against a barrier, no matter where you set the limit if you have too many images. You might need to do it in batches, which you could automate by simply adding a check to see if the dimensions of the image already match what they are meant to be. That way on each batch you'd skip by those that have already been resized. I think that might be a decent approach, but maybe someone else will chime in on this. You also might be better off bootstrapping PW from a php file and running that from the command line.

This is fantastic teppo! I don't necessarily think you should (as it may make the module unnecessarily complex), but do you have any plans to implement any of the SwiftMailer plugins like Decorator, AntiFlood, and Throttler? I use these for sending out bulk emails to subscribers. I think perhaps in these cases it is simpler if we just include swiftmailer separately in the appropriate template/module code, but thought I'd raise it in case you have any ideas along these lines.