ryan

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

Try to disable pagefileSecure in your /site/config.php: $config->pagefileSecure = false; Most likely the Apache htaccess rules that make that option work are not compatible with nginx (or require a different set of htaccess rules).

Kyle, I'm not familiar with Vagrant but looked it up and it looks interesting. Is it possible that it's interfering with variables $_POST or $_SESSION? Also, when on that login page, does your URL address bar have a trailing slash or not? (it should, but double checking). You might also try disabling session fingerprinting in your /site/config.php file $config->sessionFingerprint=false; I'd also be interested to see what's in your phpinfo if you want to paste "<?php phpinfo();" into a file and view it in your browser.

Yes, I'd be happy to do this. I didn't realize it was that simple. I've got some other things on the to-do list first, so if anyone gets to it before I do feel free to send over the files and I'll add them when I get back in the office next week.

The "Geocode OFF" text is what is shown when the checkbox between address and lat/lng is not checked–make sure you've got that checked, unless you want to manually input your own lat/lng coordinates.