ryan

You actually can't bootstrap one PW installation from another PW installation, though the idea sounds interesting. If you've got two sites sharing the same core, but running on different databases, then the only way they can share data is by taking a web service approach (the same way you'd share data with any two sites).

Soma I can't seem to duplicate this one either (also latest dev and in latest Chrome).

Soma, it sounds like output formatting is disabled in test mode. Can you try the attached to see if that fixes it? TextformatterHannaCode.module Do you know if this is an issue with AceEditor, or something about the way I've implemented it? I only ask since you mentioned Adam's inputfield had the same issue.

What URL does it show in your address bar when you get that message? Also, what version of Form Builder?

Soma, reading through php.net, it sounds like versions of PHP prior to 5.3.8 had incorrect behavior for is_subclass_of(). In those versions, the only straightforward way to determine it is I guess to use Reflection. I've added a PHP version check which falls back to Reflection in older versions of PHP, but don't have a PHP version to test it out with. Do you want to try replacing your /wire/modules/Inputfield/InputfieldPage/InputfieldPage.module with the attached and let me know if this resolves the issue? InputfieldPage.module

Wanze, Adrian is right with the _createPath() function he linked to. It maybe that you could solve it entirely simply by making it recursive, as he suggested. Actually, it might be good to just have the wireMkdir() function support creating a path rather than just a single directory... lets update that one in the core instead. The wireRmdir() already supports a $recursive argument to it, so wireMkdir() should too.

I realize I sound like a broken record in this thread, but thanks again for your great work with this language pack. This is the most complete and up-to-date language pack for PW.

Well done Horst!

Another way would be to create a module to extend the WireSessionHandler (/wire/core/WireSessionHandler.php) and leave the implementation blank. WireSessionDB module would be a good template to remove code from. Though have not tried it and not positive it would work. But it sounds like you've already found a potentially better solution.

I'm actually getting a different but similar result here, so can confirm there must be an issue. I hadn't noticed it before because I've always kept my multi-language repeaters as having no ready items. For me, I start to experience strangeness (like multi-language fields having only an input for default language) when my ready items is set to some number greater than 0. In your case, I'm assuming you have ready items > 0, and that changing it to 0 would fix it, so that's what I'd suggest for now. But I'm going to try and fix this here soon. Is this already on the GitHub issues list or should I add it? This one I had run into myself before and had fixed it (a few weeks ago). Are you sure this is still occurring, or is it from a repeater that possibly was created before the issue was fixed? It's always possible I've not found the right fix for that, so I will test a little more here. But let me know if you think this is most likely still a current issue and not just something present on an older repeater. Edit: just tested and confirmed the issue is fixed (here at least)–my repeater items are active for all languages. I still need to test with ready items > 0, as I'm guessing the two issues from this thread may be related entirely to that.

Edit: just updated the post to account for the "!=" operator, and also updated the FieldtypeRepeater.module file.

Thanks for the report. I was able to duplicate it too. Can you try replacing your /wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module with the attached file and let me know if that fixes it for you too? FieldtypeRepeater.module To fix it, I replaced this line get getMatchQuery(): $query->where("($table.count{$operator}$value)"); with this: if(($operator == '=' && $value == 0) || (in_array($operator, array('<', '<=')) && $value > -1) || ($operator == '!=' && $value)) { $templateIDs = array(); foreach($field->getTemplates() as $template) $templateIDs[] = (int) $template->id; if(count($templateIDs)) { $templateIDs = implode(',', $templateIDs); $sql = "($table.count{$operator}$value OR " . "($table.count IS NULL AND pages.templates_id IN($templateIDs)))"; $query->where($sql); } else { $query->where("1>2"); // forced non-match } } else { $query->where("($table.count{$operator}$value)"); } Hopefully I got the logic right on this one, as it's a little different need than count() situations for other Fieldtypes. Most fieldtypes don't keep track of their own counts and PW relies on the quantity of rows present in the table instead.

I think this may be because the only encoding allowed for JSON is UTF-8, so UTF-8 is implied by the format and a UTF-8 header is technically redundant. Though my understand was that it's still a good idea to specify it. And I'd not be surprised if IE assumed JSON is Windows-1252 if there's no charset header. But if it's screwing up Firefox, that surprises me, but that'd also be a good reason to remove it. Just wondering though since Firefox (or any web browser) is not the intended client for this module, how is Firefox coming into play here (debugging?).

Just to confirm, sessions are working (i.e. you are able to stay logged in consistently), but you just don't see anything in the Setup > Sessions page? Is it completely empty, or do you just see yourself there? In testing here, I can't seem to duplicate the issue. Double check the top drop-down box that lets you specify how many minutes you want to see sessions for. Make sure it is set to at least 5 minutes. If doesn't do it, try increasing it to 43200 minutes and see if that makes any difference? Another thing to double check is caching. If you are using ProCache, you will not see sessions appear here except when PW has to render the page. That's because ProCache bypasses sessions and the overhead associated with them. So not seeing sessions here would be expected and desirable, but only if using ProCache. Last thing to look at is your Modules > Session > Session Handler DB module settings. Try enabling (or disabling) "track IP addresses" and/or "track user agent" in the settings, to see if it makes any difference.

Sounds interesting. I'll look into this as a future option, as it would make a lot of sense in a single-install, multi-site environment.

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