ryan

I hope so too. But I've got a big GitHub issues list to work through, and a few more new things to polish off, so it may be awhile yet. But rather than waiting, I'd encourage folks to use the dev branch. Though I'm wondering if we might benefit from having another "beta" branch, which would be a variation of the dev branch intended more for official presentation and download links, etc.

I think the best option is both. At least, that's what I used in the rating module I wrote. The problem of two people on the same IP is a compromise for the reasons you mentioned, but it can be mitigated quite a bit by using the $_SERVER['HTTP_CLIENT_IP'] or $_SERVER['HTTP_X_FORWARDED_FOR'] headers instead of $_SERVER['REMOTE_ADDR'], when they are available. My opinion is that the compromises in relying on a cookie for any kind of rating are much bigger compromises than occasionally blocking a vote due to IP.

It just depends on what your expectations are. I think most agree PW provides quite good performance in this area, and perhaps better than the other CMS platforms out there. But if performance is the primary factor, you can do no better than to work directly with the database and well defined indexes. Abstracting the database is always a compromise for performance, but definitely a worthwhile one here, in my opinion. So long as you use scalability best practices (especially use of pagination) I think you'll find PW to provide very good performance regardless of scale. No, when it comes to pages or any data connected with pages, PW does not load the whole dataset unless you tell it to (by omitting a limit=n in your selector). PW is designed to be scalable regardless of page quantity. Though for most installations, this is generally under 100k pages. However, I do know of at least one person using PW with more than 100k pages, and all is good. We're now talking about using PW for millions of pages, but I don't think that's been tested to date. However, I fully expect PW can support that scale.

It does make your upgrade task a lot more difficult, but ProcessWire itself doesn't care if you put modules in /wire/modules/ rather than /site/modules/.

Looks cool Jonathan! I look forward to taking a closer look soon. In reading the notes, I noticed what you said of head.inc/foot.inc and just wanted to mention that most of us don't actually use that method. It's just what it is in the default profile purely because it's the simplest for newbies to understand (and most similar to the WordPress approach). So the use of head.inc/foot.inc is really more about making things easy to understand and a gentle introduction, but it's probably not the way to go as your needs grow. I also noticed that you use _init.php – is this related to ProcessWire's _init.php using the $config->prependTemplateFile and $config->appendTemplateFile options, or is this something different? I also see in your API methods addStyles/addScripts -- do these use the $config->styles and $config->scripts or is this something different? Maybe I will find my answers when I get more time to explore the module. Thanks for your work and sharing this with us.

No problem–it is now hookable on the dev branch. Ok, I think I understand now (It's using the page title rather than the module title). These are translatable by making the title field multi-language. But it'd be better to just bundle them in with the language pack since they are core modules, so we can add this to the default.php template, no problem. I'll add that. I have no idea what this could be. We don't serialize any objects with sleep/wakeup. It sounds like there must be some other code doing this, but who knows where. I would look at your 3rd party modules and any other code you might be including in your site. Also, double check that you entirely replaced your /wire/ directory when updating (removing or renaming old /wire/, and creating new one). I've not been able to duplicate this one. But what you are describing points to a JS error occurring. Open up your JS console and check for errors. If you don't see any, go to the "network" tab and click on the page list ajax request. In the "response" you'll probably see some error message above the JSON code for the response. You get an endless loading arrow because the response isn't valid JSON, but looking at the response should quickly answer what the problem is.

Thanks I was able to reproduce. Can you try out the latest commit to dev to see if this fixes the issue? In addition to column widths, this version also adds management of column heights–it attempts to normalize the heights of all columns in the same row dynamically, depending on what's shown, in the same way it does column widths. OR conditions are not yet supported. I've tried to duplicate the issue you mentioned, but can't so far. I probably don't fully understand what you are trying to do. But I can envision a lot of potential problems with combining dependencies and repeaters, so I think we will probably disable the capability once this goes beyond the dev branch. I noticed some uncommitted updates I had, related to the line where that error occurred. I don't remember exactly what prompted me to make the changes, but it seems like I may have run into the same error you did. I went ahead and committed that now. As for multi-language fields, I've not been able to go there yet with dependencies. No code has been written to support them yet. But this is something that certainly is feasible and I do plan to add. However, you should be able to show/hide a multi-language field based on the values in a non-multi-language field, but I'm not sure you can do more than that at present. I think that it's showing the dependency options for pretty much all fields at this point. I'm going to wait and see how far we get in terms of field support before I start adding exclusions. But we will be adding some exclusions in 2.4.

Are the sessions working, but just not appearing in the list? Are you seeing sessions present in the DB table 'sessions' (when looking at it via PhpMyAdmin or equivalent)? Also make sure you've got debug mode on when testing, just to make sure any errors aren't getting suppressed.

Since your values appear to be integers, you can sanitize them as easily as: $sanitizedValue = (int) $t; That sanitizes, but doesn't validate the value. Validation is also important, especially with something like an ID number that indicates a reference to something else. This is even more important in ProcessWire, where page IDs can also represent things like users, admin pages and more. To validate, you'd want to make sure the number is valid for the selection. To do this, you'd need to confirm that the value you were given was present in the list of selectable options you gave to the user. Or, if you know the selection is limited to pages from a certain parent or template, you could validate like this: $p = $pages->get($sanitizedValue); if($p->id && $p->template == 'your-valid-template' && $p->parent->id == 123 && $p->viewable()) { // it is valid } else { // it is not valid }

What version of ProcessWire? you might try fixing it manually by locating the page through the page list tree via Admin > Pages > Repeaters > ...

Repeaters actually do have template files. In Setup > Templates > Filters, check the box to show system templates. However, this isn't going to help with sorting, as you'd need to define that on the parent. You could locate where your repeaters are stored in Admin > Repeaters and set the sort there, but you'd have to do it individually for each page. Ultimately, we need to just make this a configuration option with FieldtypeRepeater.

That's what I'm wondering too–potential JS errors. Mike, with your permission, I'll check your site to see if I can spot anything obvious. Installing CKEditor may be a good idea, but since you and your editors are already used to TinyMCE it probably makes sense for us to try and debug it first.

The above code should work. Just make sure you are outputting the truncated version ($summary) and not $child->text. echo $summary; // do this echo $child->text; // do not do this

Martijn is correct, and this profile is written for the HTML5 spec. I think there are a few more examples of the same thing in this profile as well.

I haven't taken a close look at it yet, but there is some info about localization for this timepicker on this page: http://trentrichardson.com/examples/timepicker/

Try adding this to the top of your /site/templates/admin.php, after the opening <?php tag: $pages->addHook('saveReady', null, 'makePageHidden'); function makePageHidden(HookEvent $event) { $page = $event->arguments(0); if($page->template != 'category-site') return; // replace 'category-site' with your template name if(!$page->is(Page::statusHidden)) $page->addStatus(Page::statusHidden); }

The deleteAll() is actually a queued call that occurs when the page is saved. As a result, you might need to add $page->save() right after the deleteAll() call, just so that it doesn't end up deleting the newly added image too.

I've wondered why they do this too. There must be a good reason for it, but it escapes me. Any guesses? The guys that make Foundation aren't dumb (quite the opposite), and it's still my favorite css framework overall. But this extra <li class='divider'> seemed very unusual when I was working with it, though I just went with the flow and assumed they must know something I didn't. The only thing I can guess is that, semantically and visually, an extra <li> representing a divider might translate to any situation (even one with no CSS, though it'll look unusual). But I think of a divider as a style not a semantic element. I'd be curious on any other theories.

Soma any chance I can get a copy of the site (or maybe online/FTP/SSH access to it) so that I can try and debug it? I'm jut not sure I have a good enough of a test case here. I have a multi-language site that imports from a giant XML feed every day, including numerous repeater fields. But have not run into these issues. Though in my case, I set language values using $page->field->setLanguageValue() rather than switching the user to different languages, so that may be the difference. But it definitely sounds like there is a bug in there somewhere if you are seeing data1011 and 1011 is the ID of the default language. I think I could track that one down pretty easily once I can reproduce it. The fastest way to that may be to just get access to your site.

Another option that might work (though not yet tested to compare): $result = $pages->find("template!=admin, has_parent!=2, include=all");

I'm not sure I understand the question? The only thing I can think of you might be talking about is using comparison operators where you pass attributes to the Hanna code? The thing is, attributes are no different from HTML attributes (key=value)... they are assignments, not comparisons. So I'm confused about the question.

I think the answer lies in your FieldtypeTags module. Unless it extends FieldtypeText and inherits the capabilities of FieldtypeText (which includes support for the *= operator) then you will get the error saying that the operator is not implemented. As for why it works in one instance and not another, I have no idea without seeing the code behind the module. But just wanted to mention that operators like "*=" and "~=" and "%=" are not something that Fieldtype knows about natively – your module has to implement them instead. The good news is that it's very easy to do, and PW even provides a helper class to do it for you. See here in FieldtypeText for an example. You'll also need to make sure your Fieldtype's schema uses a fulltext index.

I'm not an expert on this, so correct me if I'm wrong, but wouldn't you be better off doing this with htaccess? This post by WillyC seems to have some good suggestions in that regard. But it seems like there would be real downsides to doing this with PHP rather than htaccess. For example, if using PW's template cache or ProCache, combined with ob_gzhandler in PHP, your cache files would end up gzipped and presumably re-gzipped when delivered. Or if PHP is smart enough not to re-gzip something then it seems likely that clients that don't support gzip could still get cached gzipped files? We could probably get around these issues by providing ob_gzhandler to ProcessWire's root ob_start() call, but I'd be curious to know the benefits of doing this with PHP rather than Apache, before suggesting that as a configuration option. I had always assumed this was something best left to Apache. Apache can do the same with your static assets too (CSS, JS, etc.)

Anyone else using the spellchecker with TinyMCE that knows how to fix this? I've not used TinyMCE's spellchecker yet, though will have to try it out. Mike, if we can't get TinyMCE's spellchecker working, we can switch you to CKEditor with Scayt (spell-checker-as-you-type) which seems to work pretty well.

Not in javascript. Taking a closer look, both FieldtypeFloat::sanitizeValue() and InputfieldFloat::sanitizeValue() get their hands on the value before sleepValue() does. They just do simple typecasting with (float) and a round() calls. The only thing I can think of is that maybe PHP's round() is not respecting the float internationalization? You might try removing the round() call from both of those functions. When it comes to float i18n it seems like PHP is trying to do too much for us in some places and not enough in others. I find it pretty confusing.