ryan

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

It's on the list, just haven't had time to go after this one yet.

This turned out to be an issue with the order of variables returned by core TemplateFile::getArray. It was doing an array_merge which gave preference to API variables, preventing them from being overwritten. Maybe that's a good thing in general, but I don't think we want that limitation. I went ahead and changed it in dev. Now it gives preference to local variables, which enables Hanna Code to provide the behavior it was supposed to.

Not even Google Analytics reveals the vast majority of phrases used to arrive at your site. My understanding is that technically it may be for https, but strategy wise they are doing it to increase search relevance by keeping all of us more focused on content than keywords. Source (see section "100% not provided") This should be expected, as no PHP is executed on a ProCache request.

Thanks, glad you are enjoying it! I'm assuming you are running the latest PW (2.4, formerly dev branch) since you are using multi-language features, but just in case, make sure you are running 2.4 as the support of multi-language is much better in 2.4 than in 2.3.

Yes they are supported now and will continue to be. Though I'm hoping people will convert the themes over to AdminTheme modules. It's easy to do, and provides the benefit of having multiple-admin themes installed at once. When more than one admin theme module is installed, ProcessWire adds an admin-theme selection box to every user's profile screen. To convert an existing admin theme to a module, just move the files into /site/modules/AdminThemeName/ (replacing the Name part with the name of the Admin theme, i.e. AdminThemeTeflon). Then create a new file in the same directory called AdminThemeName.module (again replacing the Name part). All that needs to be in that file is this (I'll continue to use Teflon as the example name): <?php class AdminThemeTeflon extends AdminTheme implements Module { public static function getModuleInfo() { return array( 'title' => 'Teflon Admin Theme', 'version' => 1, 'summary' => "A nice admin theme.", 'autoload' => "template=admin" ); } } Of course, the AdminTheme can go a lot further if you want it to. Examples include: having its own install() method to add new assets it uses (i.e. user profile avatar), adding its own hooks, creating its own API vars, having a custom configuration screen, or anything else you could do with any other module. But all of that can come later... all you need to do to convert an existing admin theme to an AdminTheme module is just to move the files and add the AdminThemeName.module file shown above. I haven't yet had time to look at this one, but it's on my to do list. Thanks for keeping me up to date on it. There's always a long list of issues to cover on GitHub, but we were at a point where all remaining issues were relatively minor, affected very few people, and didn't need to hold up release. I just didn't see any reason for people to keep downloading 2.3 when 2.4 is already more stable. We'll be covering remaining issues, like this one, with incremental versions, working through the list.

Actually class_exists() should work, but WillyC missed an important part. ProcessWire doesn't include module files that aren't autoload unless some information about them is requested, like $modules->getModuleInfo("className"), or the like. In the same manner, a class_exists("className"); call triggers the autoload mechanism and causes the file to be loaded. But you can prevent that by specifying false as argument 2 to class_exists(): if(!class_exists("ModuleName", false)) { // module is not loaded }

Horst, it should already support the rel=0 option for video embedding (at least it used to). Try adding it to the YouTube URL you are embedding. If it doesn't work, go to the module settings and clear the video cache and try again.

Roope, PW's sanitizer functions are intentionally aggressive as they are aimed at dealing with user input situations. But you don't have to use them if they don't fit your need. In fact, if this is not something dealing with user input, then I would just not worry about the sanitizer and just wrap your values in quotes (unless your values also need to match quotes).

Actually it should be http://processwire.com (without the www).

Another option is that you could go for one of the scalable cloud hosting services (for example), letting the hosting side scale as you need it.

2.4 has been out for a couple days now as the current stable version, so you don't even have to use dev if you don't want to.

How about this: for($size = 4, $n = 0; $n < count($images); $n += $size) { foreach($images->slice($n, $size) as $img) { echo $img->url; } }