SteveB

Thanks Adrian. I'm just trying to figure out what it might be relied upon to do in it's current, work-in-progress, state. For this project I can probably just build users from scratch each time. The password issue can be dealt with.

I'm not trying to access the data from the external table. I'm trying to build new pages (or update existing ones) using the API. Doing things manually from the admin's page editor... "the selector appears on the page edit form, I can chose "Bob" from the list" I need to be able to do that via the API, so that when somebody views the page, "Bob" will already be selected.

When you change the user to Gold put the current date or expiration date in another field. Setup a really simple module to hook on login. Then it can test the date field and role to see if it's an expired Gold user and change their role. Maybe even redirect them. $this->addHookAfter('Session::loginSuccess', $this, 'hookAfterLogin'); and public function hookAfterLogin ($event) { $user = $event->arguments[0]; foreach($user->roles as $role){ do things... } } Edit: More here http://wiki.processwire.com/index.php/Module_Creation#How_to_attach_hooks_with_a_module

I'm using 1.1.5 on PW 2.6.19 and the table is setup, the selector appears on the page edit form, I can chose "Bob" from the list, save the page and see the data in the database. What I can't do is make the selection via API. Let's say we're using id numbers and usernames and that Bob is #3. I should be able to do $page->myfield = 3 shouldn't I? Thanks.

An update on the status of Migrator with respect to current dev version of PW (soon to be stable 2.7) would be much appreciated! Reading this thread I get the sense that, understandably, there are plenty of edge case problems but do we know what's working reliably on recent PW installations? I'm piecing together a staging-to-live strategy for a site where most of the content will be imported from non-PW data sources (including images). One way is to first delete those pages which get imported from the external data, then use the reliable method of copying over the whole database, the site folders (templates and modules) and any necessary config, .htaccess, index.php tweaks. This keeps users, roles, user/role mapping and template access settings intact. I feel as though a "cleaner" way would be to explicitly export/import users, roles, user/role mapping and all template settings. Then I could start with a clean PW install. How much of that might Migrate be able to do these days? Thanks, Steve

Still perplexed. I found that the admin's edit page embeds this javascript. Seems pretty indiscriminate to do that to all the img tags. $(document).ready(function(){ $( "img" ).attr({ src: "", title: "Processwire.com", alt: "Processwire.com", height: "23px", width: "auto" });}); Note that it clobbers the src attribbute. Haven't yet found where that comes from. FIXED! It was the AdminThemeCustomizer module (version 0.0.1). Uninstalled that and no more problem. Weirdly, I had noticed that months ago and forgot about it.

For some reason it's not putting anything in the "src" attribute of the image tag. The image really does exist and my (frontend) template has no trouble displaying it.

I'm migrating a work-in-progress to 2.6.19 and the admin pages (page edit) don't show images of the image field. See attached. If I click where it says "Processwire" I get the image in a popup. Any idea why? It's this way in the standard admin theme as well as Reno. If I add an image to a page the new image appears there until I save the page then when the page reloads it's back to "Processwire" again. Thanks, Steve EDIT: Oh good a clue! /demo26/wire/modules/AdminTheme/AdminThemeReno/styles/main.css.map is coming up 404.

Several ways. I'd suggest thinking about how best to represent the data using Processwire's Templates, Fields, Pages (specific PW terms) and then write a script to use the API to read your existing data and build those PW pages. It can have a very relational database feel to it and have tree-style hierarchy available too. There also are various ways to incorporate a separate database table (look in modules, fieldtypes, etc.). If that dataset has to stay where it is (maybe something else maintains it) you could use PW's very flexible API to interface to it. Wrap all your back and forth logic up in a module. Maybe hook into some Page functions to make it seem more built in.

My frontend autocomplete support for text fields is working nicely now. It uses autocomplete to build a csv list in a text field. You can use the autocomplete suggestions or just edit the text field as you like. The UI is sort of a "lite" interpretation of InputfieldPageAutocomplete. The javascript is based on jqueryUI example code, with the ajax call going to a ServicePages URL. For styling, I extracted parts of the CSS of InputfieldPageAutocomplete, mostly that having to do with the popup list and the status icon. Renamed those classes InputfieldTextAutocomplete. There's nothing special to do when making the form markup, just add JS and CSS files to the page. A jQuery selector string in the JS determines which fields get the autocomplete treatment and I'm using the text field id as the template name in the selector that gathers page titles for the list. Some of the people who use this form will also be using the backend so I felt it was important to mimic the ">>" status icon from InputfieldPageAutocomplete. It does a great job of showing autocomplete is there and giving feedback on the ajax search operation. Instead of the note part of InputfieldPageAutocomplete I use a title attribute (on the status icon) to say "Type a few letters and autocomplete will offer matching items" and clear that out after they've done it once. That's enough of a clue and not too naggy. Thanks everybody.

Yeah, all good points. Looks like my script needs some functionality from InputfieldPageAutocomplete.js. Might be better to figure out how to make InputfieldPageAutocomplete.js work in this situation but will save that for another day.

I need to pick out the necessary CSS from wire/modules/AdminTheme/AdminThemeDefault/styles/main-classic.css to support InputfieldPageAutocomplete fields on a frontend form. I don't want the whole form to look like an admin form, I just want the look and feel of the field, such as the little prompts and indicators inside the field, to work like they do on the admin pages. Whenever I do this kind of thing I end up tediously searching main-classic.css (which is all on one line) and trying things out until I have added just the CSS that's actually needed. I wish there were a breakdown of what's used by what or a more comprehensible commented version of main-classic.css. How do you go about this? My frontend form is built using the API. A couple of fields are ones where I want the user to select Pages. These are made as ordinary text fields but I've added javascript to support the jQueryUI Autocomplete functionality with the ajax calling ServicePages. The JS is working nicely and I like that I can use it to add autocomplete support to any text field. The fields collect titles as a delimited list. Thanks.

Interesting idea! Splitting up creation and selection makes things clearer to the user too. I think I'll finish a modified InputfieldPage module working I've been working on and then try your suggestion. In this usage it would be good to have adding new options be a bit more deliberate. Thanks.

If I put code in InputfieldPage.module ___renderAddable function to conditionally set $this->parent_id and $this->template_id the autocomplete box will prompt me to "Hit enter to add a new item." The new value then appears in the list that's part of the UI (the drag and drop bars) but when I save the page I see that no new item has been made. No errors either. Later... I think I can deal with this via hooks but I could use some help with the hooks. I'd like to conditionally change some properties of $this in InputfieldPage.module methods ___renderAddable and ___processInputAddPages I setup a module file like this: class HookInputFieldPageAutocomplete extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'HookInputFieldPageAutocomplete', 'version' => 1, 'summary' => 'Modify autocomplete to add own processes.', 'singular' => true, // Limit the module to a single instance 'autoload' => true, // Load the module with every call to ProcessWire ); } public function init() { // init() is called when the module is loaded. $this->addHookBefore('InputfieldPage::renderAddable', $this, 'beforeRenderAddable'); $this->addHookBefore('InputfieldPage::processInputAddPages', $this, 'beforeProcessInputAddPages'); } public function beforeRenderAddable() { if($this->template_id == 60){ $this->parent_id = 13043; } } public function beforeProcessInputAddPages() { if($this->template_id == 60){ $this->parent_id = 13043; } } } Questions: Any obvious beginner type errors? Is the hooked function's $this also $this in the context of the functions beforeRenderAddable and beforeProcessInputAddPages? What I'm trying to do is evaluate that conditional before either of those two InputfieldPage methods is run. I could just put a modified version of the module in my sites/modules folder and be done with it but this seemed like an opportunity to try something new with hooks Thanks

For a page field with InputfieldPageAutocomplete the option to allow new pages to be created from the field doesn't work. I assumed that's because I'm not following these rules: 1. Both a parent and template must be selected above. 2. The editing user must have access to create/publish these pages. 3. The label-field must be set to "title (default)". Instead of doing it that way I use a custom selector (template=feature,sort=name). It works fine for selecting existing pages but I can't make new pages with it. I don't want them all under a single parent because there are thousands of selectable options. I have a HookAfterPageSave module setup to automatically set the parent (for pages with "feature" template) to one of several folders based on the first letter of the title (folders named "A" to "Z" and "Numbers"). That works fine when I create and save them via the API as part of a data import. To satisfy that rule #1 above I tried setting parent to one of the folders just mentioned thinking that it wouldn't disturb anything since HookAfterPageSave is going to save new pages to the right parent anyway and the my custom selector will be used to find the items. This fooling around with settings did not allow me to add new pages. Any suggestions?

I like SelectMultipleTransfer too but it's one of those which loads the entire list so that's not good for huge numbers of choices. Looks like it's down to these two: PageListSelectMultiple - cumbersome but lets user look through all the choices PageAutocomplete - quicker but requires some familiarity with available choices I'm going with PageAutocomplete. If a user gets stumped staring at the empty field they can go view the choices elsewhere as ordinary pages. Eventually I'd like to figure out how to put a different Javascript front end on some of the existing inputfields.

I'm struggling with this too. In my case I need to choose from a huge set of tags. There are about 10,000 of them and I've set them up as simple pages. They are not in any kind of taxonomy (I lost that argument). I've been trying all the methods I'm aware of. The best in terms of performance and ergonomics is to divide the tags up into folders A to Z and use PageListSelectMultiple but each of those folders is presented as a paginated list. With several hundred items per folder its a very tedious click, click, click experience to tag a page with half a dozen tags. I tried AsmSelect and ChosenSelectMultiple with all the tags in one folder but both get overwhelmed and fail. The edit page never loads. A field using SelectMultipleTransfer can be paired up with another field to select one of the A-Z folders as its source. With its dual lists I was hoping options which had been selected would persist when the source folder is changed but it doesn't work that way. If you change the folder feeding the SelectMultipleTransfer it clears the previously made selections. Any idea how I can accumulate selections from different folders?

Yes, that's pretty much what I did. At the time I thought I might like storing filter options as an attribute of the $page. We'll see. This is working fine: $fid = $fields->get($fieldname)->id; //get the field id $field = $fields->get($fid); //this is what we need to set filter settings (then like your example above)

Yes but I want to change the available options automatically depending on various conditions which change from time to time. EDIT: Maybe there's a way I can modify the module's filter method so I can change the filtering dynamically. Then when building a form I could setup the filter before calling getInputfield(Page $page, Field $field) and the user would see only those options. Putting this at the top of the filter method is a good start: $attr = 'optionFilter_'.$field->name; if(!empty($page->$attr)){ $field->filter_column = $page->$attr->filter_column; $field->filter_selector = $page->$attr->filter_selector; $field->filter_value = $page->$attr->filter_value; }

With the API and SQL or a selector string I'd like to specify a subset of the records in the database table used by the field and set the field's selection to that set of records. How do I do that?

FYI, tried this on 2.6 the other day. I wanted to delete thousands of pages (finding them by the template name). It didn't seem to do anything. I got it done with a script and didn't go back to investigate but I thought I'd ask if it ought to be able to do that.

FYI, in 2.5.26 dev this module works but has an odd side effect. In the page editor images images do not display. They come back as soon as you uninstall the module.

Having some luck with this but can't seem to use it for this scenario... Selectable items are parented to various "group" pages. They also have a page field for their "type" (typical pages-as-categories kind of thing). On the template of the page where I need to select these items, I can setup a group page field and make my custom selector string use that for parent, OR I can setup a type page field and make my custom selector string use that for type, BUT I can't do both (it doesn't find anything). This works: parent=page.item_group, page.item_group!='' This works: item_type=page.item_type, page.item_type!='' This does not work: parent=page.item_group, page.item_group!='', item_type=page.item_type, page.item_type!='' Edit: Apologies for extending the somewhat tangential dependent selects discussion in this "Select Multiple Transfer" topic. As for Select Multiple Transfer, I can't get it to show up in 2.5.26 dev as a choice among the other input fields. Have uninstalled/reinstalled.

Celfred, I had some of the same thoughts about Fredi and access. In that thread SiNNut mentioned above there was a simple module to hide the backend admin from certain users. By modifying it slightly I'm using Fredi without letting frontend editors see admin pages. 1. Create a role called frontend-editor and give it page-view, page-edit, page-edit-recent permissions. 2. Create a user (or several) with that role. 3. For each template they need access to, use template's access tab to grant 'edit pages' access to that role. 4. Setup HideBackend this way (a little different from Adrian's version, maybe rename it) to keep them out of backend... class HideBackend extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Hide Backend', 'summary' => 'Redirect frontend-editor user from backend admin back to site\'s homepage.', 'href' => '', 'version' => 1, 'permanent' => false, 'autoload' => 'template=admin', 'singular' => true, ); } public function init() { if($this->user->isLoggedin() && $this->user->hasRole("frontend-editor")) { $this->addHookAfter('Page::render', $this, 'redirect'); } } public function redirect(HookEvent $event) { if($this->page->template == "admin") { $this->session->redirect("/"); } } } I think I'll have it redirect to some kind of welcome page instead of "/" but this does seem to be working. The user can use the admin login page to login. Once they succeed they are immediately redirected away and Fredi edit links should become visible. Edit: Wait! - Had it working yesterday (thanks to a typo) but there's a problem with this method. The crux of it is that if we redirect in HideBackend we break fredi's uses of the admin pages too. I can't totally prevent a frontend-editor user from going into admin pages but I'm testing a workaround to reduce the likelihood of that happening. This may not be the final answer but in HideBackend's init function I'm saving the current time to a session variable each time an obvious fredi request comes in (opening the modal). Other requests are allowed if previous fredi request was not too long ago, otherwise the redirect hook is set.

Elastic Search itself was okay. Here's what I found. Timeout while indexing: The module's code for indexing all pages does a find and I'd assumed it would make use of the template whitelist value from module configuration but it didn't. It finds lots of pages, then skips the ones which should not be indexed. I have thousands of simple pages (containers for images) which don't need to be found by this selector. Now I'm using the whitelist to build a more specific selector. May have to break this up into multiple finds when I have more content. In checkForRebuildSearchData() $arr = $this->getAllowedTemplates(); $str = (count($arr)) ? ' template='.implode('|', $arr).',' : ''; $pages = $this->pages->find("id!=2, id!=7, has_parent!=2, has_parent!=7, template!=admin,$str include=all"); The other thing that became obvious pretty quickly is that the Textareas (with an s) fieldtype was not handled. Adding a function and a line to use it in getAllContentForPage() took care of that. protected function getTextareasTypeAsContent($value) { $values = array(); foreach ($value as $name=>$value) { $values[$name] = $value; } return $values; } ... elseif ($type instanceof FieldtypeTextareas) $value = $this->getTextareasTypeAsContent($value); I've confirmed that it is picking up changes when I edit pages. Too early for opinions on effectiveness of Elastic Search itself.