ryan

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.

If using the latest version of PW with the new default admin theme, it doesn't display the Inputfield label if there is no description – just shows the checkbox label. From the API side, you can also specify $field->label2 as something distinct from $field->label, where $field->label2 is the second label (the one for the checkbox).

The error message suggests that Twig is trying to call $page->template as a method, like $page->template() -- which doesn't exist.

I'm not getting any perceptible slowdown with 100+ fields here. Soma do you have any modules hooking into the rendering on that screen? Considering how quickly the dropdown navigation versions can be generated, I'm guessing the slowdown may have something to do with the calculation of # templates and # pages that are shown. If I can get a copy of your database dump, I could import here and test. These were actually just converted to AJAX yesterday, so that they don't have to be loaded/rendered on every admin page request. This also removes the 100 field/template limitation that we'd imposed on it.

I think these guys covered it really well, but here's an overly simple alternate example in case it helps. class YourModule extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return array('title' => 'Your Module', 'version' => 1); } const defaultValue = 'renobird'; public function __construct() { $this->set('yourname', self::defaultValue); // set default value in construct } public function init() { // while you need this function here, you don't have to do anything with it // note that $this->yourname will already be populated with the configured // value (if different from default) and ready to use if you want it } public function execute() { // will return configured value, or 'renobird' if not yet configured return $this->yourname; } public static function getModuleConfigInputfields(array $data) { // if yourname isn't yet in $data, put our default value in there if(!isset($data['yourname'])) $data['yourname'] = self::defaultValue; $form = new InputfieldWrapper(); $f = wire('modules')->get('InputfieldText'); $f->name = 'yourname'; $f->label = 'Enter your name'; $f->value = $data['yourname']; $form->add($f); return $form; } } If you have the need to manage several configuration values, then you can save yourself some time by using a static array of default values like in the examples before mine. Also this: foreach(self::$configDefaults as $key => $value) { if(!isset($data[$key]) || $data[$key]=='') $data[$key] = $value; } could also be written as this: $data = array_merge($data, self::$configDefaults);

Which line is producing the "not escaped selector" message? Your $pages->find() is missing a comma between "DMC_map!=''" and "sort=title", but that's the only issue I can see.