ryan

It sounds like this is more multi-language/similar-site, rather than actual multi-site. You mentioned all the domains describe the same content (for the most part) so I would probably take the "multi-site" out of your thinking about it, because it's only multi-site so far as it is multi-language. I'd use the dev branch, purely because it's going to take you a lot farther on the multi-language side. It should be plenty stable, but you'll just have to use extra care when updating (i.e. test things out on your own before upgrading a live server). If you could, I would try to do this all on 1 domain rather than split among multiple domains, but I'll assume that's not an option. But it'll be workable either way. If using multiple domains (or subdomains), you'll only need to install the LanguageSupportPageNames module if you want to have the same pages use language-specific names. I'm guessing you'll want that. However, you'll want to set the $user->language yourself, based on the domain/subdomain, rather than any other factor. You can do that with code like this at the top of a common include/file for all site template files: // grab the subdomain, i.e. "en", "de", "at", etc. list($languageName) = explode('.', $config->httpHost); // sanitize it just for good measure $languageName = $sanitizer->pageName($languageName); $language = null; // attempt to find a language with the same name if($languageName) $language = $languages->get($languageName); // if no language matches, then we'll assume 'default' language. if(!$language || !$language->id) $language = $languages->get('default'); // set the language to the user $user->language = $language; The above is essentially serving as your "multi-site" code, forcing the language to match the subdomain. You'd want to remove any other multi-site solutions. You'd want to use multi-language text fields where possible. When using multi-language textarea fields where you need rich-text editing, I suggest installing the InputfieldCKEditor module and using it in inline mode. This scales much better for multi-language environments than TinyMCE. For situations where you need different images per language, you can use the tags feature to devise your own matching method (perhaps using the language name as the tag), or you can use language alternate fields. For situations where you have a page available in one language and not another (or some and not others) then you can simply make them active or inactive from the checkboxes on each page's "settings" tab. To summarize, I would treat this site purely as a multi-language site, and would probably develop it without considering the multiple domains/subdomains. Then when it comes time to launch, point all those domains at the same site, but use the $config->httpHost trick above to set the language based on the subdomain its being accessed from.

I'd be curious to know how you created the non-working field, just so that we can prevent that from happening in the first place?

It does kind of depend on how many users we're talking about here too. I would not be so enthusiastic about creating caches on a per-user basis, and more likely to focus any caching efforts on common content, that's the same for all users. But if it makes a major difference in performance, then the tradeoffs might be worthwhile, but still something to be cautious with.

Thanks celfred–Glad you like the Pages Web Service module!

I think that's okay, but it could be problematic in some cases like when file locations are different between master and dev, or when dev is using an updated DB schema from master. I don't think that either is the case right now, but just something to watch out for. The safest bet is to run them on separate databases. In your current setup, worst case is probably that you could end up being only able to run dev (with some part of the DB schema not compatible with the older stable branch). The changing file locations is not so much of an issue, but if you get errors you might need to manually clear the Modules cache (i.e. remove all /site/assets/cache/Modules.* files).

Nice job NoDice, looks awesome!

Thanks for the description, this may help me to reproduce. I don't yet have a good test case setup–I want to debug it now, but still have 3 pages of messages to get through, so may not get time today. But this week I was experiencing the same error you were, though in an entirely different situation. But it did reveal a problem where $pages->save() was catching an Exception that it shouldn't have, and this was leading to fieldtypes trying to save, presenting the familiar "Unable to save to 'field_title' for page that doesn't exist...". This is now corrected on dev, as of yesterday. I don't think it will fix the problem you are experiencing, but the result of the exception might very well reveal what the problem is. If you have a moment to try the latest dev sometime with the same situation, please let me know what you find. Otherwise, I will work to duplicate the issue here soon.

I'd tend to agree with you that it might be specific to that version of MySQL or something else specific to the server. But I'm going to keep an eye out for anyone else reporting something similar. If there's a problem there, it'll appear elsewhere, and that'll be a good signal to start debugging it. But so far I can't duplicate, so am thinking we should avoid debugging this too much until there's some indication it goes beyond 1 server.

Thanks for the testing and reports maba and Raymond, I'll experiment here and see what I can find/fix. But regarding the image field, I don't think you'll be able to use that as a live dependency because the ajax upload isn't submitting the entire form, just a single field. So when it gets processed, the context of other fields is not known. Only the existing page state is known. So that dependency would probably only come into play after the page is saved in full. As a result, image/file fields may not be good candidates for dependencies, unless we turn off the ajax upload for that situation. A repeater is a PageArray, so you'd have to extract an element from it first. Like if you wanted the first element: if($page->contentblock->first()->contentblock_headline != '') { // something }

Those above are actually translated with the individual modules (ProcessUser, ProcessRole, ProcessPermission), though looks like I didn't yet it have it translatable for ProcessLanguage. Though there's no harm in having them translatable there too, but just not sure it's necessary. Good catch–thanks, I have added this and they'll be on dev shortly.

Can you describe your scenario? Here's a common scenario: Lets say you've got a section called /articles/ and you want to have authors that can edit articles: 1. Create new role called "author" and check permission box for "View" and "Edit". Assign this role to one or more users you've created. 2. Edit your "Article" template (Setup > Templates > edit), the one represented by /articles/some-article/, etc. 3. Check the "yes" box on "access" tab to enable access control. 4. Next to the "author" role, check boxes for: View, Edit Want your authors to be able to create new articles too? 1. Edit your "Article" template again, check the box for "Create" for the author role. 2. Edit your "Articles" template (the one represented by page /articles/). Enable access control and check the box for "Add Children" for the author role. Want authors to only be able to create new articles but not to publish them? 1. Add a new permission (Access > Permissions > New) and call it "page-publish" 2. You don't have to do anything else. Since the author role doesn't have page-publish permission, they can't publish pages. They can still edit and create unpublished pages. Tell me more about your scenario and I'll outline instructions.

I don't think it's related to field dependencies. Sounds like that floatval() at the end needs to come out, but somehow we need to get the value converted to a real float/decimal number that MySQL will accept. You could try commenting out the floatval() at the end of the sleepValue() function in /wire/modules/Inputfield/FieldtypeFloat.module. Maybe we can just pass it to the DB as a string? i'm reluctant to do that since wakeupValue is meant to return a value in it's native state, but if it fixes this issue it'd be worth it. Thanks for your testing with this btw.

Like mentioned above, urlSegmentStr is your ticket. Note that it has no trailing slash, so you may need to add one to it in some instances. Also want to mention that the $input->urlSegments Array is not useless at all – I use it all the time. Just one small example is to count the number of urlSegments: count($input->urlSegments);

While true that you've got a lot of options there (and perhaps more than most people need), I don't think it interferes with the regular use of the module either. Testing it out here, all seems to work nicely and didn't present any configuration challenges. While I didn't need the ability to define custom formats just yet, it's always nice to know that I can.

I agree with you on this. It would be tricky and problematic. You'd have to enforce use of separators, likely both client side and server side. Having them split in two fields is a way of doing that already, while eliminating the possibility of errors. It does make it harder to enter and/or paste in a phone number, but it's ultimately more bulletproof. I can update the logic of the wireEncodeJSON function to detect a 0-prepended string, but that won't help with past versions. Since you aren't calling wireEncodeJSON yourself, I'd suggest maybe prepending something uncomming to your format before the 0 (like a "~") and trim()'ing it out when using it. Silly I know, but I can't think of another way around that short of requiring a specific version of PW. That might make sense, as I'm thinking an individual installation will probably want to standardize on one format rather than revisiting it for each field. Thanks for your updates, I am going to download now!

Sevarf2, you are correct about something here in that theoretically, supplying the template to the find() call should enable it to run faster. ProcessWire needs to know the template for a page before it starts loading it. So it'll query the DB for the page's template if it doesn't already know it. However, we don't have that optimization in place for $pages->find() at present, so your $pages->get("id=123, template=book"); doesn't benefit from that. But you can take advantage of that optimization by using the $pages->getById() method. It would technically be the fastest way to retrieve a page, but it's rare that I would be up for using it when developing a site (I only use it for core development). But it may be worth trying if you are trying to optimize a large amount of page retrievals. I'm not sure it'll make much difference in the end, but it's worth a shot. $template = $templates->get('book'); $page = $pages->getById($page_id, $template)->first(); The getById() method is really meant for retrieving multiple pages, which is why it returns a PageArray. If you have multiple pages using the same template, you can retrieve all of them here: $pageArray = $pages->getById(array(123,456,789), $template); If you can also supply a parent_id to the method (meaning, you already know all the provided page IDs have the same template and parent), it can use that for a little further optimization: $pageArray = $pages->getById(array(123,45,789), $template, $parent_id); Btw, the purpose of $pages->getById() method is as a support for all the other get(), find() and children() methods in ProcessWire (or anything else that returns a Page or PageArray from the DB). All pages loaded from the database are loaded by the getById() method, so all the other get/find methods are actually front-ends to it. getById() was never intended to be part of the public API though.

Selector may be a good way to go in that case. We'll have to look closer at this. But if you are interested in experimenting with different options, one way to go would be having a module add a new hook function to the Pageimage class, like this (warning: written in browser, not tested): public function init() { $this->addHook('Pageimage:mySize', $this, 'mySize'); } public function mySize(HookEvent $event) { $pageimage = $event->object; $selectorString = $event->arguments(0); $selectors = new Selectors($selectorString); $settings = array(); $width = 0; $height = 0; foreach($selectors as $selector) { if($selector->field == 'width') $width = $selector->value; else if($selector->field == 'height') $height = $selector->value; else $settings[$selector->field] = $selector->value; } if(count($settings) || $width || $height) { return $pageimage->size($width, $height, $settings); } else { return $pageimage; // nothing to do, return original } } Usage: $thumb = $page->image->mySize("width=300, height=200, upscaling=0, sharpening=medium");

That's interesting, as you should be okay on any PHP 5.3.x (at least those above 5.3.7). I'm wondering if maybe the web server's PHP omitted blowfish support for one reason or another.

Awesome work Kongondo! Very impressive seeing it in action from your video too. Regarding the help-please section and security: is the Process tool intended primarily for superuser/developer use, or something that would be available to non-superusers? If exclusive to superusers (as many admin/developer helper tools can be), security becomes a much simpler task because we already assume they have access to do whatever they want. If not exclusive to superusers, then there's more to consider. With regards to SQL queries, it looks like you are doing a good job of sanitizing everything that gets bundled into a query. But for any string values, you might also want to run them through $str=$db->escape_string($str); just to complete it with the DB driver's own sanitization method. It's probably not technically necessary in any of the instances I saw, but it's just a good practice either way. Of course, you can also use numbered parameters in mysqli to avoid that issue, but I don't care for mysqli's implementation of this and generally don't use it (on the other hand, PDO's named parameters are great).

Blickwerker, please let me know if you aren't able to access the FormBuilder board or can't find the solution in there. I don't remember what it was off the top of my head, but can track it down.

If you wanted it to automatically bypass the _main.php template during an ajax request, you could also do something like this in your _init.php: $useMain = !$config->ajax;

I had some updates to push on dev related to InputfieldPage and the <select> dependencies, so went ahead and did that, just so that we're all testing on the same version of things here. This is a little off-topic here, but wanted to mention before I forget: @Soma: I implemented something so that you can specify which classes should behave like InputfieldPageListSelect/InputfieldPageListSelectMultiple, where the "parent" setting reflects the root of a tree rather than an immediate parent. Rather than having those hard coded in the class, they can now be specified by making your class implement the interface "InputfieldPageListSelection". This interface doesn't currently require any methods, so it's a blank interface. You can have your Inputfield class defined like this to be treated as a tree selection: class YourInputfield extends Inputfield implements InputfieldPageListSelection { Non-selected pages aren't actually part of the POST submission. They are no different from unselected items in a <select multiple> ... actually that's exactly what they are behind-the-scenes, as this jQuery UI widget is just a progressive enhancement to <select multiple> in the same way that asmSelect is. The data that they represent can't go beyond what is represented by a <select multiple>.

For you guys that can't get this working, what is the exact selector string that you are using? Are you combining it with any parent/template settings separate from the selector? I've been using it every day since posting it here, and it's been working well for me on two different sites I've got in development. I'll double check that I don't have any lingering files needing to be committed to dev.

2.4 will be released once the dev branch source has sat for a week or so without any necessary fixes or major additions (meaning, it's reached a stable state). I think that's probably soon, but don't want to promise any dates since I'm actively working on the code almost every day.

I haven't been able to reproduce it either, but it's come up a couple times here, so there must be something to it. Though I'm not sure if it has to do with possibly leftovers from a previous version of ProcessWire. I think we need a test case/code to reproduce it consistently before it's something we can reproduce and solve.