ryan

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.

I'm trying to reproduce this issue–no luck yet, but not sure I understand it in full. Does it occur editing a page in the admin, or just from the API side? If from the API side, does your API code create a new page or modify an existing page? Does your code populate the repeater? If so, does it populate it before or after the page is initially saved? How may 'ready items' does your repeater field have? Is there more than 1 repeater field? Other then removing the repeater from the template, has anything else changed the behavior?

The mb_strtolower($text) isn't necessary in the above line, as when you specify Sanitizer::translate, that's already the first thing it does in the pageName function. Take a look at the module settings in Modules > Inputfield > Page Name -- from here you can specify your own translation table for how characters should be translated. Is this what you are looking for, or something different?

Drupal is still a quicker path to a community-generated content site. It can all be built in ProcessWire, but Drupal is well suited to this from the get-go. It's not just user relationships, but the fact that it's a markup generating system… not much separates the editing side from the presentation side (this is also a point of frustration for some). Most other things I would say ProcessWire is better suited for (yes I'm a little biased). But it ultimately comes down to what system a webdev has the most expertise in, and Drupal is one of those that you can accomplish quite a lot in when you know it well. That's if you are willing to accept other aspects of the system–it's a fundamentally different approach [from ProcessWire] that works well for some and not others. Mary–I've always liked the fact that you know so many systems well, and stay up-to-speed with them. You've got a very good perspective about the CMS landscape. I'm glad ProcessWire is one of the systems you like working with. Btw, when you are trying to solve a particular user/role/permission scenario, please post it and we can help to figure it out. It's all possible in ProcessWire, but some more complex scenarios are solved programmatically with hooks (but it's a lot easier than it sounds).

You just posted the jQuery minified source code there. I'm a little confused and not sure exactly what we're talking about now (still profile exporter?). What are the steps to reproduce the issue? And are we still talking about a MySQL issue, or a Javascript one?

Little update on dev branch: The default admin theme now comes with an autocomplete search. If you are superuser, it will include templates, fields and users in the search as well. Once 2.4 goes stable, I'll assist with implementing this in other admin themes too.

Horst, I'm not so sure we'd want to take this route because it would either have to modify the settings of the Pageimage, or it would have to return a new copy of the Pageimage on every option change. I wouldn't want it to modify the settings of the original Pageimage because other code in one's site/application might be assuming it to have the default settings. It would be like some tall person borrowing your bike and not lowering the seat back to where they left it when they are done. Maybe the eventual size(); call could reset those settings back (if it hopefully occurs), but that might also be confusing to someone wanting to issue multiple size() calls on the same Pageimage. Returning a new Pageimage would solve that, except it would also be pretty inefficient creating a new copy of the Pageimage for every single setting change. It makes sense with a size() call because it's literally returning a new Pageimage represented by a new file, but I'm not sure it makes sense for functions changing settings to return new copies of the Pageimage. I personally think that options intended for a size() call probably belong with that size() call as they are now. But if you think the array syntax is too much, we could always look at providing an alternate selector string syntax or something?

The first part of a module name is considered a grouping and must consist of 1 upper letter followed by 1 or more lowercase letters. Then the module name after should do the same-1 upper+1 or more lower. You can also use digits in the second part. Example: ProcessField or MarkupPagerNav, or any existing module name. You can make up your own grouping if you want to, though if your module clearly fits in an existing grouping, it's better to use that (especially for ones that go in the directory). For your modules I would suggest "Wwwp", "We" or Weworkweplay as your grouping, i.e. WwwpInstaller, WeInstaller, WeworkweplayInstaller.

Hard to tell without seeing the code -- can you post the non-working code here?

Awesome job Adrian! I can't wait to use this one. I'd be using it right now if I weren't holding a baby in one arm and typing with the other. But I did browse the code and thought it looked great.

There's a few ways to get at them.This might be the most direct: $array = $field->getArray(); // or $array = $field->getTableData();

Soma, I like the direct simplicity of your solution here. The $user instead of $this->user was a typo on my part, not intended. PHP usually gives me an "undefined variable" notice to let me know about those things. But to explain the purpose of the temporary variable _language_tmp, that is so that the original setting could be restored. It's possible that $user->language is something different than $this->setLanguage, perhaps due to something changing it in the site's templates during the course of program execution. The only way to capture that is to store it in some temporary place before save and then restore it after save (which is what I was attempting to do). Though it's probably a rare thing, so if the new solution you've tested is working, then I'd rather just stick with it and approach the other issue if it ever comes up (I don't think it will). Thanks for debugging this and coming up with a nice simple and working solution. Just to confirm, this solves it? Or are there still things that aren't working still?