ryan

I just needed a couple more days to finish writing up the announcement and changes. I'm guessing you've already seen it by now but just in case you haven't it's located here: http://processwire.com/about/news/introducing-processwire-2.4/

I would bet that's got something to do with this line. That line may not be necessary anymore now that we've got CKEditor's ACF working properly. Try commenting it out to see if that fixes the issue? Please let us know.

I'm not sure that I understand, but you should have full control over your field names in FormBuilder. If you want a field to be automatically populated from a GET var, then you'd want that variable name (i.e. "myfield") to be what's specified in the URL, i.e. domain.com/path/to/form/page/?myfield=something. Likewise you'd want to use "myfield" (or whatever you named it) as the field name in FormBuilder. Also you mentioned populating those values programatically. You can do that like this: $vars = array('foo' => 'bar'); echo $forms->embed('myform', $vars); If using it in a non-embedded way (like method C) then you'd just populate the values to your form the old fashioned way, like you would with an Inputfield form.

You'll want to test ahead of time, but I think it'll still work. There are some bugs and security issues in PHP 5.3 versions prior to 5.3.8, which are good reasons for nobody to use those versions. That's the main reason I set 5.3.8 as the minimum. But the reality is that it should still work fine in any 5.3. Chances are it would still work fine in 5.2 as well, but I want to take that monkey off our back so we can move forward.

Nice work mvdesign! Very attractive look and lots of good thinking here. We* are actually working on a second core admin theme option that is quite similar in many ways to the look you've posted here (the overall layout of major elements is very much the same with regard to masthead and sidebar). Once released, I'm imagining it will also serve as a very good starting point for taking your design here to a full admin theme. *I say "We" because I assume I'll be working on it here soon too, but so far all the work has been done by someone else.

This is already old news to many of you here, but I finished writing up the full announcement today so figured I should post it (click the link below). Numerous upgrades and refinements make ProcessWire 2.4 our most friendly and powerful version yet! ProcessWire 2.4 is focused on listening to the feedback from of our users and answering with the best CMS experience for web designers/developers and their clients. Read the full announcement. For those upgrading from a previous version of ProcessWire, please read all of the upgrade instructions. Hope that you enjoy this new version! A huge thanks to Avoine for sponsoring the Field Dependencies feature new to ProcessWire 2.4!

Any difference if you remove the 3 validations you mentioned? I'm curious if it's an issue of validations or lower level.

InputfieldWrapper is the base class for a Form, Fieldset or Tab (InputfieldForm, InputfieldFieldset, etc.) It implies an Inputfield thats purpose is to contain other Inputfields. While Forms, Fieldsets and Tabs represent specific things, a regular InputfieldWrapper just acts as a wrapper/container for Inputfields, without any kind of visual representation. Because it is a type of Inputfield, it can take the place of a single Inputfield, while actually containing many of them.

Using modules for this stuff is nice if you are building functions you'll be re-using on multiple sites. But for the sake of simplicity, I usually put my shared output generation functions just in a common include file like this.

I wasn't able to duplicate the issue that Soma mentioned, despite repeated attempts here. As far as an issue with files in repeaters, I think it's possible there is an issue there, but haven't had time to test that one out yet. I've added a GitHub issue report for that so that I can test that one out during the next debugging phase (aka early Sunday morning).

What's your <input type='file'> code look like? How are you outputting the multiple <input's> for each file? Does your name attribute read 'documents[]' (indicating an array) rather than just 'documents' ?

Klauss, welcome to the forums. I think you might have too broad of a question there, and I'm not sure anyone can tell you how to build your app. I'm not sure what wettransfer is, but I think you'll need to focus more in on how to do these things with PHP and server configuration (4 gb file uploads is going to require some server config). I think you'll find ProcessWire helpful once you have a good idea of how you'll build this app.

You can also use language support and translate any of ProcessWire's built in messages to your own (including default language).

You might look at WillyC's htaccess rules too.

Your solution looks good, but would make the riders always appear at the bottom of the results. Maybe that's okay, but I think riders and other types of pages might be different enough that they'd warrant further segmentation or their own search, perhaps their own tabs at the top of the page, or regular pages in left column, riders in right column, etc.

I have no problem with spaces in passwords. Can't say I've ever thought to put spaces in passwords, but it makes sense. I'll update to support that the next time I'm in the code for that module. As for logging in with email address, PW uses the username as the unique key for all users. Users are pages, so this is for consistency with the pages system as a whole. I think maintaining this consistency is preferable in keeping the whole thing as simple as possible. Not to mention, 'name' is a built-in property of every page, whereas 'email' is just a custom field in the template (it's technically possible for it to not exist).

I'm running PW from crontabs all over the place. You can ignore the undefined index notices in this case as they don't have anything to do with the errors that follow. The error messages you are seeing seem to indicate that the database settings were not defined. No idea how that could happen, but maybe something to do with the symlink. Or you may be hitting up against some server security here, as it appears you've got one account (sev-online) trying to access another (abc). Make sure your cron job is running as the user that owns these files, or one with greater access.

"template=restaurant_features=1052|1053|1054|1115" This isn't a valid selector. I'm guessing just a typo and you mean something like this? template=restaurant, features=1052|1053|1054|1115 Quoting Pete: if(!$input->post->{$feature->name}) You can also do this: if(!$input->post($feature->name))

I don't understand the code example well enough. But I'm thinking maybe you are intending to do something like this? $c->recipients = $input->post->recipients; While that would work, it would be better to do some thorough validation, like this: $c->recipients->removeAll(); foreach($input->post->recipients as $id) { $recipient = $pages->get((int) $id); if($recipient->id && $recipient->template->name == 'recipient') { $c->recipients->add($recipient); } }

What version of PW are you using? I thought we had this fixed on dev quite awhile ago (now 2.4).

If you guys are using 2.3 or 2.4 you might prefer: $this->wire('key', 'value'); rather than $this->setFuel('key', 'value'); and $this->wire('key'); rather than $this->fuel('key'). The "fuel" terminology is meant mainly for internal use rather than public API. It'll work, but I think it makes code more complex than it needs to be, versus just using that single wire() function for everything.

You guys are tough. My impression is that the site is awesome, something different with lots to discover and great visual rewards. It made me want to stick around. I've found this site and the one that Felix posted to be some of the most visually interesting and engaging sites I've seen recently.

I don't know the answer to your question here, but I'm replying to bump it up in case someone else knows. Also moving this to the dev talk forum since it's not specific to ProcessWire.

Thanks for the debugging work you did with this. You are right that the status<Page::statusMax should be replaced with an include=all. That status<Page::statusMax is the old version of include=all ... what we used before we had include=all. It still works just fine, except it doesn't bypass access control the way include=all does, because access control used to be handled differently. So it looks like the behavior you saw there could occur if it was executed from a non-superuser account. Just to confirm, replacing it with "include=all" fixed the issue from what you can tell? I will make the change here, as it should be include=all regardless.

I think you'd be able to do this, but not 100% positive without seeing how it would all work. FormBuilder isn't meant to present multiple forms on the same page, though it can be done. It sounds like your forms would be popping up in a modal and perhaps you might technically only need one form in that case. The form could be populated with the lot number via a GET value in the URL (something that FormBuilder supports for pre-populating a form), and the timestamp is already recorded with each form submission.