ryan

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; } }

Kongondo, great video and module! I hope you'll add this one to the modules directory when ready. Also for those above, wanted to mention that Teppo's Changelog module is also a good way to look at what's been edited recently. In terms of having a list of "recent edits" display in the default admin theme, that kind of goes against the desire to keep the admin theme as minimal as possible. I don't disagree on the usefulness of it, just think it doesn't belong in the default admin theme. I'd rather leave that to other admin themes, or support such features in the future with theme-specific 3rd party installable modules or widgets (this could be fun).

That universal module is called ProcessWire. In all seriousness, I understand what you are saying. This Events fieldtype isn't particularly useful in it's standard state. It is meant purely for you to take and extend it to do what you want with it. It might also be useful as a starting point for someone wanting to make a fully configurable version of it. But as to how "much work" it would take, it would not be a small project.

I'm unclear about why you are using Hanna code for this. I might not be understanding the question, but it sounds like something that maybe you should just be using pages for. For instance, you could have a page called /tools/rental-prices/, and output that: echo $pages->get('/tools/rental-prices/')->body; If you had various different options for rental prices, then you could create a 'page reference' field called rental_prices, and make it select from one of the many pages living under /tools/rental-prices/, like /tools/rental-prices/summer/ and what not. Then you'd output it like this: echo $page->rental_prices->body;

You are right that repeaters add overhead. Think of it this way: each repeater item is itself a page. So if you are loading 1 page that has 5 repeater items, then you are actually loading 6 pages. ProcessWire can deal with lots of pages no problem, but if you start dealing with lots and lots of pages with lots and lots of repeaters, then it's good to be aware of potential overhead. Autojoining your repeater won't help, but autojoining the fields in the repeater can help.

Yes, links generated by $page->url type calls are updated automatically according to the language. I'm not opposed to having other dedicated language boards here. But there would have to be adequate demand for such a thing. I'm not aware of there being sufficient demand for it at this point. As good as Google translate is, it's not great. For instance, Google Translate taking a German page to English is barely intelligible. Not to mention, code examples rarely survives Google Translate. If we were ever to have any other language boards here in the future, I don't think we'd be wanting a translate button. Having the same page URL respond to a user's accept-language browser setting is frowned upon by google. For that matter, having the same page URL display different content based on the value of any header, geo location, referrer or user agent is frowned upon by google. This is not considered a good practice. If building a multi-language website you'd want to use an obvious language switcher of some sort and be sure your multi-language content is separated by URL or hostname so as not to confuse the search engines.

I think underk hasn't seen your message yet, so I went ahead and updated the project URL / download link to point to the GitHub repo.