ryan

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.

When I need a calculated field that will be used for sorting, I like to add a hidden (or regular, doesn't matter) field to the template to store the calculated value. The value gets automatically calculated on page save. A hook like this in your /site/templates/admin.php can do the work for you: $pages->addHook('saveReady', function($event) { $pages = $event->object; $page = $event->arguments(0); if($page->template == 'rider') { $miles = 0; foreach($page->rides as $ride) { $miles += $ride->miles; } $page->miles_ridden = $miles; } }); Then when it comes to sorting, you just sort on your calculated field: miles_ridden. If you are adding this to an existing PW installation, then you'd need to establish the initial values for each rider's miles_ridden. This could be done with a quick bootstrapped script: /setup-riders.php <pre><?php include("./index.php"); foreach(wire("pages")->find("template=rider") as $rider) { $rider->save(); echo "$rider->name: $rider->miles_ridden miles ridden\n"; } Then you'd just load domain.com/setup-riders.php in your web browser, and then delete the file when done.

You can make up your own users system, and sometimes it's the simplest route to achieve something. But I would try to get it done with regular PW users first. You can always map fictional page names to usernames via URL segments. For instance, if you had a template called 'riders' and you enabled 'URL segments' in the 'URLs' tab of your template, then your /site/templates/riders.php file could have code like this: if($input->urlSegment1) { $rider = $users->get("name=$input->urlSegment1"); if(!$rider->id || !$rider->hasRole("rider")) throw new Wire404Exception("Unknown rider"); // display rider echo "<h1>$rider->name</h1>"; echo $rider->body; // ...or whatever fields you wanted to output } else { // display list of riders foreach($users as $rider) { if(!$rider->hasRole("rider")) continue; echo "<li><a href='./$rider->name/'>$rider->name</a></li>"; } }

Regarding the first part of your question: if you want PW to run from the root of your domain, it's best to install it in the root so that you have /index.php, /wire/ and /site/, and not /subfolder/index.php, /subfolder/wire/, and /subfolder/site/. I'm glad you found a rewrite rule that works in your case, but I'm not confident that PW will be totally happy with it as it does consider various server variables to determine the installed path–page URLs might still reflect the subfolder. I don't totally understand the question. But if you need to ZIP up a copy of a site, then you only need to create a ZIP of the /site/ folder. Everything else (which is just index.php, .htaccess, and /wire/) can be obtained with a fresh copy of PW. When I'm backing up sites, I usually just backup the /site/ folder since I know everything else can be easily obtained.

Landitus, you and Soma are talking about two different issues. The issue you mentioned, about the description (alt tag) disappearing after editing an image, is one that I can't duplicate here (just tried). You may want to upgrade your site to PW 2.4 just in case the version you have had some issue in that regard. The issue that Soma mentioned is an expected one, because when you use the link or image dialogs, it is writing out a new <a> or <img> tag when you click the "insert link" or "insert image" button. Since a 'class' attribute is not used by the link dialog, it writes out a new <a> tag with no class attribute.