ryan

When you are using pagination, PW assumes all of your selectors are paginated (see the side effects section on the pagination docs page). As a result, you need to tell it which ones are not by adding a "start=0" to it. I'm thinking this will fix the issue in your case?

This is on the repeater roadmap, but no ETA on this yet. There are currently a couple of items in front of it, for repeaters: custom labels, custom sort, and collapse settings. Once those are in place, we're going to start at looking for ways to introduce pagination.

The trash shouldn't be a consideration in a web service feed like this, because items in trash are targeted for deletion and we have no control over when somebody will decide to empty the trash. So for all practical purposes, items in the trash should be considered the same as deleted items here. The code above won't pull pages out of the trash, so it should already work the right way, so long as you don't add "include=all" to the selector. If you do need the behavior of include=all, then I would suggest doing this instead: $trash = Page::statusTrash; $results = $pages->find("template=product, status<$trash, id=" . implode("|", $ids)); That should give you the same behavior as "include=all" but exclude pages in the trash.

It sounds like the second snippet of code is working, but not the first. Double check that URL segments are enabled in your "home" template settings. This is on the URLs tab. If that's not it, look at your PW version. Is it older that 2.3? If so, try replacing "urlSegmentStr" with "urlSegment1". Still not working? Add this at the top of your /site/templates/home.php file, temporarily, just to make sure it is working: echo "<h1>urlSegmentStr: $input->urlSegmentStr</h1>"; What do you see?

I don't know enough about this particular tool to say for sure, but if you are able to modify the core plugin to get it working, let me know what you change so that I can make the same change in the core. A lot of our users are in Finland and would like to have full support in everything from the core.

Horst, hadn't heard back from the last PM - did you get this figured out / able to install?

Since this module does not have a multi-language version, the best bet is to make your own with a repeater.

It is possible to extend the existing images field (by code) to make it do what you want. But a simpler solution (especially on the multi-language side) would be to use a repeater, where each item has a single image field and you add whatever text/multi-language fields that you need.

I'm thinking you probably don't want to use FieldtypePassword for your temporary password. I'm not sure PW will even support two of them in the same template. For a temporary password, I'd probably keep it in the $session rather than in a page field (session variables are temporary server side storage, with the data not present in the cookie). Since it's temporary, you don't really need it to have a permanent representation in the DB. This would also ensure the temporary password automatically expires with the session. Just don't ever show the user that password from the session, only use it to compare with one you've sent to them by some other means like email.

Joe, we haven't updated to ZipArchive in that part of ProcessWire yet. But if you know exec() is enabled, then try prepending your server path to the uploadUnzipCommand so that rather than "unzip ..." it says "/usr/bin/unzip ..."

That actually looks like a bug in this module. The error message is correct, as there's a "continue" in the middle of the function (not sure what I was thinking–I must have converted a loop to a function and not hit a date that would trigger the line). I'm not in the office where I can fix it, but I think it should be safe to just comment out or remove that line.

I haven't figured this one out yet but on the to-do list before 2.4 is released.

I wasn't aware of this issue and haven't ever experienced it myself. But just attempted to reproduce and sure enough I got the same thing. Here's a fix (attached), place this is /wire/modules/Process/ProcessPageAdd/ProcessPageAdd.js -- I'll commit this to dev when I get back in the office. ProcessPageAdd.js.txt

16k pages is a lot to deal with one one request (if you are using the API as opposed to hitting the DB directly). It looks like MySQL has some resource limiter placed upon it in your case, so re-connecting probably won't help you (though that's a guess). You probably need to reduce the quantity of pages you are working with there, perhaps setting a limit (5000?) and keeping to it for each run. But if you want to check for a DB failure, your best bet is to wrap your operations in a try/catch. But I think the solution here will involve reducing the amount you do in a single cron run.

In your template files, you can always control access just by performing your own checks, and that may be the simplest route here. For instance, you could have something like this at the top of your template file: if(!$page->category->viewable()) $session->redirect('/path/to/login/page/'); Another way to do it is to hook into Page::viewable to perform your own permission checks. The benefit here is that you would keep it all in one place: wire()->addHookAfter('Page::viewable', function($event) { // if it was already determined page is not viewable, then we'll exit and stick with that // this may or may not be the behavior you'd want, but you probably want some "early exit" // thing to check so that you aren't completely disregarding what the existing // $page->viewable() returned if(!$event->return) return; // check that this page has a 'category' field that we are using for permission $page = $event->object; if(!$page->category) return; // we'll abort now if there is no category // if category isn't viewable, we'll say this page isn't viewable either if(!$page->category->viewable()) $event->return = false; // you could also do things like check user roles: // if(!$user->hasRole('some-role')) $event->return = false; });

I don't know of any changes that would have affected the URL it goes to (s=1 for example). I don't think there have been any edits to ProcessPageEdit in the last couple of minor dev versions. The dev version is up to 2.3.9 if you want to give that a try, but so far the issue you are experiencing seems like a mystery. Is it only occurring for you in Firefox or other browsers too?

That's a good question and I'm not positive about the answer yet. This is the second time I've see SetEnv not liked by a webhost, so I think we need to at least have a note about it mentioned in the .htaccess file as a possible thing to comment out when a 500 error occurs. The SetEnv here really is only to pass along a message to the installer, and not crucial at all. I've not seen an issue with DirectoryIndex before though, so will keep an eye out to see if that one shows up at any other hosts, in which case we should document that issue too.

Yep it's a bug, I'll get this one fixed soon but just had to take care of a few other things first (like catching up with the forum).

There's also an API variable (on the admin side) called $breadcrumbs that you can either modify or replace. $breadcrumbs = new Breadcrumbs(); // start with a fresh breadcrumbs list if you want... // $breadcrumbs = wire('breadcrumbs'); // ...or grab the existing copy // then add breadcrumbs to it, here's one example: $breadcrumbs->add(new Breadcrumb($this->config->urls->admin . 'your/path/', "Your Label")); wire('breadcrumbs', $breadcrumbs); // then set it back as an API variable Note that breadcrumbs is just a type of WireArray, so everything from the cheatsheet applies in terms of modifying the contents of it.

One of the next items on the to-do list for repeaters it to be able to specify a max number of items, but I'm not sure that would accomplish what you are looking for here. Your best bet may be a hook after ProcessPageEdit::processInput to look at the values of both fields. I would suggest setting your repeater "ready" items at 0, so that it is less to consider when counting the values. You could put this, or something like it at the top in your /site/templates/admin.php file: <?php wire()->addHookAfter('ProcessPageEdit::processInput', null, 'checkRepeaterQuantity'); function checkRepeaterQuantity($event) { $form = $event->arguments(0); // ProcessPageEdit's processInput function may go recursive, so we want to skip // the instances where it does that by checking the second argument named "level" $level = $event->arguments(1); if($level > 0) return; $select = $form->get("your_quantity_select_field"); if(!$select) return; $quantity = $select->attr('value'); $repeater = $form->get("your_repeater_field"); if(!$repeater) return; if(count($repeater) > $quantity) { $repeater->error("You have specified more than $quantity items"); } }

Sounds like an interesting project. Admittedly, when reading your description it sounds a lot more like a fit for the software we are typing on here (IP.Board). Your development budget probably won't enable you to have anything custom built, so you'd need to focus on utilizing stuff that's already built and apply your budget towards integration and configuration of those things. As much as I'd like to see you use ProcessWire for this stuff, your project scope seems to fit almost exactly with what IP.Board and vBulletin provide out of the box. We are all about using the best tool for a particular job, and ProcessWire is the best tool for most of them. But as you can see, we use IP.Board for our forums here because we feel it's the best tool for forums. My impression of your project requirements is that IP.Board and/or vBulletin would be good things to look at first.

I'm not really sure what affects the order that unzip extracts those files (or PHP reads them in), but we are just pulling them in, in the same order they come through on the file system. I'm actually planning to replace the uploadUnzipCommand with ZipArchive (using uploadUnzipComment only as a fallback), so maybe the issue will resolve itself there. But just wanted to mention that I don't think PW is involved in the ordering of these files.

Looks like we've got a bug here on the dev branch (if that's what you are running?). First, update to the latest version of the dev branch. Then edit your /wire/core/InputfieldWrapper.php and add this line as the first line in the getChildByName() method: if(!strlen($name)) return null; Does that fix it? I think it will, but am not in my office to test yet. I can't yet find any indication of why this wouldn't work, and have it in use on a few sites. Make sure your dev version is up-to-date. Also make sure that you don't already have a "custom PHP code" or "custom selector" specified that might be overriding your template setting. If you still can't get it to work, let me know and I'll attempt to reproduce when back in the office. Another way you can get the same behavior would be to use the "custom selector" and specify "template=your-template".

I agree, sounds very interesting. I'd be interested to know if anyone gets the chance to try this. You are right that if it runs WordPress, it should also be able to run ProcessWire... assuming they haven't built it around WordPress or something.

A ram cache is something completely different from ProCache. ProCache takes dynamically generated ProcessWire pages and converts them to static assets, so that they can be served directly by Apache (bypassing PHP and MySQL). Though that's the easy part. The biggest job is managing when those assets get deleted and/or re-created. Files like images, JS, CSS are already static assets (usually). I could be wrong, but I don't think that the hard drive is usually a bottleneck on most web servers. So I'd think minification and optimizing your client-side cache settings in htaccess, and then considering a CDN would be things I'd probably look at before a ram cache. ProCache is going to deliver the biggest performance benefit over any of these though, as it is minimizing or eliminating the biggest bottleneck on a dynamically generated site (PHP and MySQL).