ryan

Image fields can't be used with dependencies at present because they are ajax-upload driven. As a result, the page receives the image before it knows about the dependency condition being met, and the image is refused. I suppose this could be solved by having dependencies operate only at the Javascript level and not at the server side, but that wouldn't be as safe either. I'll keep thinking on this one. Is this in the page editor or in a Form Builder form (or somewhere else?). If it's a Form Builder form, it be good if I could take a look at an export of it, so I'd have a good test case to debug from. Please PM to me if possible.

What you are talking about is relational data, and you definitely would not want to draw these relations by searching for the person's name (after all, there might be two John Smith's too). You want to use the Page reference field type, which lets you reference one page from another. Create a field called "people", and choose "Page" as the field type. On the "input" tab, choose "person" as the template to use for pages (or whatever you've called your template for people), and asmSelect (or Checkboxes or Page Autocomplete) as the Input type. Save. Add your new field to your "event" template. Edit an event, and now you can select the people that are related to the event. If you later change the person's name or anything like that, then it doesn't matter. To list the people connected with an event, you'd just do this in your code: foreach($page->people as $person) { echo "<p><a href='$person->url'>$person->title</a></p>"; }

Do you guys think it makes sense to bring LanguageFieldTabs into the core? So far I haven't come across a multi-language site install where I wouldn't want it, so starting to wish it was just there by default.

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.