ryan

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?

I'm not sure I agree that it's a good idea or that it would make more sense to clients. I think what makes the most sense to clients is when structure represents reality, both front-end and back-end. In that context, the homepage is the root page, the common ancestor of all others. The more you abstract those things, the less sense it makes to clients, at least in my experience. As a result, I encourage people to use the homepage as the homepage rather than trying to abstract it to somewhere else. If you are going to abstract it, then it depends how you do it. I would avoid handling it from the htaccess and instead edit your /site/templates/home.php to load and render the other page that you want to represent the homepage. $otherPage = $pages->get('/path/to/your/abstracted/homepage/'); $otherPage->you_be_homepage = true; echo $otherPage->render(); In the page represented by that path above, you'd want to have it throw a 404 (via it's template) when you_be_homepage is not set, just by throwing this at the top. if(!$page->you_be_homepage) throw new Wire404Exception(); or make it redirect to the root page: $session->redirect('/'); Using this strategy, you shouldn't have to consider any effects on SEO as the abstraction will be invisible from the outside.

In this case I think it's fine to do what you did, rather than extending. Though what you'll miss out on is when fixes or additions are made to the core modules, your module won't automatically inherit those. I usually try to extend or better yet, delegate, when it makes sense. But sometimes it can be a less direct path. So it does come down to how much time you want to put into it as well. I'm not exactly sure why that would be occurring in your case–is your module file in /site/modules/? One way you can resolve it is to add this at the top, before the class declaration: include(wire('config')->paths->modules . 'Fieldtype/FieldtypePage.module'); or wire('modules')->get('FieldtypePage'); But I'm surprised you'd have to do that in this case, at least I've not had to when extending a core module. If running APC, you might want to apc_clear_cache(); just in case.

There are limitless possibilities, so instructions kind of depend on what your need is. Most likely "author" would be the name of the role you would create. What do you want the author to be able to do? I can follow-up with instructions on how to do it. Thanks for letting me know, I have unpublished that page temporarily until I can update it. Didn't realize we had such old info there!

There are other 3rd party modules that might store files in a page's files directory as well. So that's why that unlink() is left commented, and why this is better left as a script that you adjust according to your installation, rather than as a ready-to-run module or something. It only knows about core-managed files.

I sometimes end up with orphaned files as a result of doing mass imports during development. My code won't be quite right the first time around and I'll end up with extra and/or duplicated files. At least that was the case this last week. It was on a pretty large scale, so not something I wanted to clean up manually. Here's how I cleaned them out. Place this in a file in your site root called clean-files.php and then load it in your browser. /clean-files.php <pre><?php ini_set('max_execution_time', 60*5); // 5 minutes, increase as needed include("./index.php"); $dir = new DirectoryIterator(wire('config')->paths->files); foreach($dir as $file) { if($file->isDot() || !$file->isDir()) continue; $id = $file->getFilename(); if(!ctype_digit("$id")) continue; $page = wire('pages')->get((int) $id); if(!$page->id) { echo "Orphaned directory: " . wire('config')->urls->files . "$id/" . $file->getBasename() . "\n"; continue; } // determine which files are valid for the page $valid = array(); foreach($page->template->fieldgroup as $field) { if($field->type instanceof FieldtypeFile) { foreach($page->get($field->name) as $file) { $valid[] = $file->basename; if($field->type instanceof FieldtypeImage) { foreach($file->getVariations() as $f) { $valid[] = $f->basename; } } } } } // now find all the files present on the page // identify those that are not part of our $valid array $d = new DirectoryIterator($page->filesManager->path); foreach($d as $f) { if($f->isDot() || !$f->isFile()) continue; if(!in_array($f->getFilename(), $valid)) { echo "Orphaned file: " . wire('config')->urls->files . "$id/" . $f->getBasename() . "\n"; // unlink($f->getPathname()); } } wire('pages')->uncache($page); // just in case we need the memory } When you can confirm that it has found the right files (and no false positives) uncomment the "unlink" line above to have it remove the files on the next run.

Yes, there should be a placeholder option for any text-based field in ProcessWire. You'll see it when configuring it. To use it from the API side, you'd do: $inputfield->attr('placeholder', 'your placeholder text');

Nice job Soma. I've actually had the same issue with TinyMCE and I don't even use templates. When using the <pre> format, if it's the last thing in the document, there's no way to add something after it. For example, if I'm editing the processwire.com site and adding a code example, suddenly I can't continue with anything after that. So I have to open up the HTML modal and add a <p>...</p> manually. It sounds like your plugin would fix this issue too.

I don't want to say anything that implies we aren't moving forward. The worst thing for software is to be stuck in time. But I do believe our API is a constant that will transcend versions. In fact, the term API implies a level of consistency and predictability that I take seriously. If for some reason we need to change parts of the API in order to move forward in the future, then we would version it. Meaning, you'd still get the old behavior if your $config->apiVersion was not up-to-date. Though I've not yet seen any reason for API changes, just additions. Believe me I don't want to create upgrade hassles for myself or anyone else, though I don't typically upgrade existing PW installs unless the client needs something from the newer version. Libraries like jQuery can't afford to version their API because they have to be as tiny as possible. But we can afford to do that, because source code size is far less of an issue for a server side application than a client side one. But this is all theoretical, as I mentioned we have not yet come across any reason to change the API. I agree with Pete.

Hani, ProcessWire will scale pretty infinitely in terms of pages, but not in terms of fields or templates. The same can be said of databases in general–you can have millions of rows in a table, but probably don't want millions of tables. I would say you've gone beyond what may be practical for long term use and maintenance of the site. At least, I have never tested ProcessWire with any more than 200 fields (and I thought that was an insane amount). I would be curious why so many fields are necessary? It might be good for us to get a list of all the fields, which may lead to some good suggestions on alternatives. But this is a situation where I think you might really benefit from making your own Fieldtype and Inputfield combinations. It is surprisingly simple to do, and can represent any DB table, no matter how many columns it needs. There is far less overhead in having a custom Fieldtype that represents a table with 100 columns, than there is in having 100 separate fields. Have a look at Adrian's new FieldtypePhone/InputfieldPhone module for a good example of how to represent a DB table with a Fieldtype. Some other options I can think of relate to ProFields, a pack of modules I've been working on to release soon (probably as commercially supported like FormBuilder and ProCache). It includes FieldtypeMultipler, FieldtypeTable, FieldtypeTextArray and FieldtypeTextareas, among others. These enable you to have a single field that can to represent any quantity of inputs. Though they all do it in a little bit different ways. FieldtypeMultiplier lets you take any other Fieldtype (that isn't already multi-value) and turn it into a multi-value field. FieldtypeTable is a multi-value compound type that lets you keep a user-defined combination of fields contained in a group… not quite as powerful as a repeater, but it's only 1 field and has far less overhead. FieldtypeTextArray lets you have a defined quantity of inputs for any text field… like say you needed a field to represent 3 email addresses, for instance. Lastly, FieldtypeTextareas lets you have 1 field that can represent any number of named textareas while having them all be searchable from the same field. For example, you could have a single field called "content" that contains separate inputs for body, sidebar, summary and about_the_author or something like that, but they only consume 1 field, accessed via $page->content->body, $page->content->sidebar, etc. All of these Fieldtypes/Inputfields are aimed at really reducing the overall quantity of fields necessary to represent lots of data. I developed this set because I had a site with lots of similar fields, and this group of modules helped me to reduce the quantity of fields by more than 70%. However, these aren't ready for production use, so it may be a little while before I have them ready. But if you'd be interested in helping to beta test them, your use case might be about perfect.

You should be able to use this module from the API side like you've mentioned. The module is built around a jQuery UI plugin called uix.multiselect, so you'll want to make sure that your context includes jQuery UI. Like with all of the selection inputfields, you'll have to add some selectable options: // add some options $test->addOption('a', 'Option A'); $test->addOption('b', 'Option B'); $test->addOption('c', 'Option C'); // now tell it which ones are already selected $test->attr('value', array('a', 'c'));