Leaderboard

Not sure if something like this could be helpful to consider here. I'm using a simple module for page/branch level access on user level. There's a simple page field attached to the user template. This allows to select 1 or more page from the site tree. So a user could have edit access for one page or a whole branch (inherited from 1 parent page) I then have a module that does hook into Page::editable and determine if the user has edit access for that page. The module looks like this: ... public function init() { if($this->user->hasRole("client")) $this->addHookAfter("Page::editable", $this, 'checkpermission'); if($this->user->hasRole("client")) $this->addHookAfter("Page::addable", $this, 'checkpermission'); //if($this->user->hasRole("client")) $this->addHookAfter("Page::viewable", $this, 'checkpermission'); } public function checkpermission(HookEvent $event) { // if it was already determined they don't have access, then abort if(!$event->return) return; $page = $event->object; $parents = $page->parents; // run check for parent pages and allow recursive inherit access foreach($parents as $p){ if($this->user->editablepages->has($p)) $event->return = true; } // then run check on selected single pages if(!$this->user->editablepages->has($page)) $event->return = false; } ...

Hi all, I know it's been awhile, but I'm just now checking back on this thread. Thanks for all the kind words - I'll be sure to pass them along to the folks on our team who actually did the design for it (I'm only responsible for the guts of it, not the prettiness). @ryan, I am using template level caching - I have each template set to clear for all pages including the home page on each save, and to save the cache for 24 hours. Without this aggressive caching, I think the site would be too slow in the real world. @AnotherAndrew, in this case the videos are just text fields, representing the main video file name. We are using the JW Player, and do have HTML5 compatibility setup, so the mp4, ogv and webm files are all named the same, save for the extension. For another site I did with PW - on which a client is making updates, including adding videos - I've set it up so that they upload the videos through ProcessWire. Knowing I can't count on the client to upload the HTML5 safe formats, I restrict the file field to mp4 only, then do a check for the existence of the other versions, changing the JW Player config as needed for each instance. I was thinking that, as we continue to use ProcessWire for sites going forward, that I might build a module that uses the Zencoder encoding API, along with JW Player, to allow full HTML5 compatibility for any video file the client uploads. I'll keep the community in the loop on that effort. Thanks again all.

Good questions RecycleRobot. This is really is going to vary from environment to environment, so my recommendations would be more general. Though awhile back Soma reported that some of his colleagues had run a stresstest called a "proxy sniffer load curves report", and the report came back quite good. But I don't know what all that entailed. I recommend giving it 128M memory (the PHP 5.3 default) or more, in your php.ini. If you need to deal with lots of traffic, it's a good idea for your server to have a PHP opcode cache like APC or eAccelerator. Beyond the server configuration, other performance factors depend on how you use ProcessWire. If you are doing anything heavyweight with the API towards markup generation, or just need to handle lots of traffic, it's a good idea to make use of PW's various caching options. From the template settings, you can tell it to use a cache from the 'cache' tab. Choose settings that maximize the lifetime of the cache, clearing only what you need to cleared when a page is saved. You'll also want to get familiar with the MarkupCache module, which enables you to cache individual pieces of markup in your templates. This is really handy for caching markup that may be expensive to build on every request, like larger navigation trees... or anything you want. You'll also want to look at these best practices for long term scalability, as well as the field autojoin option. If you need to work with a lot of pages in memory at once during the same request, the $pages->uncacheAll(); function can clear memory when you need it (at the expense of having to reload any pages you try to access again). How much memory a Page takes up depends entirely upon how many fields it has and how many are loaded/populated. ProcessWire generally tries to keep Page objects as lightweight as possible, and doesn't load fields until you actually access them. As a result, you could feasibly get thousands of pages in memory if all they had were short 'title' fields. But you might only get a few hundred if those pages have their fields loaded and all in memory at once. PW does create a new directory for each page at present. That behavior will become on-demand in the near future. But at present, this would mean your maximum quantity of pages (at least, pages that can also store files) could be limited by the file system and any hard limits present there. ProcessWire is not compatible with PHP 5.1. If you are running it, I'm not sure how because 5.1 lacks some things that PW depends on. I'm guessing 5.1 was a typo, but if not, let us know as I may have missed something. I recommend running PHP 5.3 if possible to maximize performance. Also, I may be wrong about this, but I had thought that there was some overhead with running PHP as a CGI as opposed to running it as a module. If that's still the case (?), you may benefit from running PHP as an Apache module, but I'm out of area of knowledge on this one.

Here's how: So you basically create the blog site, then run that profile export. Then take the /site-default/ directory from a blank ProcessWire (one where the installer hasn't yet been run) and replace these directories in it with the ones from your blog site: /site/templates/ /site/modules/ /site/install/ Then zip up that entire /site-default/ directory, or put it on GitHub. This is a site profile. Now anyone can replace the /site-default/ directory in a new copy of ProcessWire with yours, and it'll install your blog site. I also often use this technique for migrating client sites from dev to live.