Leaderboard

Hi everyone, To celebrate @teppo featuring this module in PW Weekly, I have added a new action: Create Users Batcher It lets you quickly create many users by entering: "username, email address" on separate lines in a textarea. This action requires the EmailNewUser module and it must be configured to automatically generate a user password. The action checks for this module and that setting before it will let you proceed. I also recommend that you install the PasswordForceChange module to reduce the risks of having emailed a password to a user. You can set multiple roles to be added to each new user. Be aware that at least one of these roles must have the "profile-edit" permission so that the user has the ability to change their password when they first login. Note that EmailNewUser will report each successful user creation and email sent success. I hope that the next time you need to create several users for a new client that you'll give this a try. And of course, don't forget to send me your own actions for inclusion with the module

CKEditor is stripping out your code since <healcode...> is not a valid HTML tag. You can tell it, via its ACF and/or Extra allowed content settings, to allow that tag, though am not sure even that would work. Another possibility is to use Hanna Code to insert that code at runtime. Parameters would have to be passed to it (the values you want the client to be able to change) so as to render them at runtime. The Hanna Code would be could like so in your body field: [[widget a=value1 b=value2 c=value3]] where a, b and c are the parameters whose value the editor can change. You can rename them to something your client would understand, e.g. type,partner,id, etc...However, do you still want your client to be editing the Hanna Code like that? Alternatively, you can create a field(s) to store your editable values and via the Hanna Code, tell it to read from that field(s). Or, if the values will always be coming from a set pool, you can save them beforehand to a pagefield. The client would then have select the applicable values in that pagefield. Hanna Code would then grab the values from that pagefield. Note that the above is not the Hanna Code code itself; just how to call it on your page. Anyway, please describe your scenario with a bit more specifics so that we can tailor our responses to that.

If you enter PHP code into an inputfield in Page Edit you would have to eval() it in your template in order for it to execute. But the idea of entering PHP code into Page Edit is really not good. If you want to execute a PHP block within some HTML coming from Page Edit then use the Hanna Code module.

Merry Christmas to everybody. (Missing Christmas Emoticon) The JavaScript File: $(document).ready(function() { // instantiate WireTabs if defined $('body.hasWireTabs #ModuleEditForm').WireTabs({ items: $("#ModuleEditForm > .Inputfields > .InputfieldWrapper"), }); }); The Module: <?php class ModuleSettingsTab extends Process implements ConfigurableModule { /** * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Module Settings Tabs', 'version' => 000, 'summary' => 'Provide Tabs for module settings screen' ); } public function __construct() { $this->wire('config')->scripts->add(wire('config')->urls->ModuleSettingsTab.'ModuleSettingsTab.js'); } /** * Initialize the module * */ public function init() { } /** * Module configuration * */ public function getModuleConfigInputfields(array $data) { wire('modules')->get('JqueryWireTabs'); $inputfields = new InputfieldWrapper(); $tab = new InputfieldWrapper(); $tab->attr('title', 'Settings'); $tab->attr('class', 'WireTab'); $markup = $this->modules->get('InputfieldMarkup'); $markup->label = 'Settings'; $markup->value = '<p>Just a placeholder for some inputfields.</p>'; $tab->add($markup); $inputfields->add($tab); $tab = new InputfieldWrapper(); // $tab->attr('id', 'ext_settings'); $tab->attr('title', 'Extended Settings'); $tab->attr('class', 'WireTab'); $markup = $this->modules->get('InputfieldMarkup'); $markup->label = 'Extended Settings'; $markup->value = '<p>For very experienced developers only.</p>'; $tab->add($markup); $inputfields->add($tab); return $inputfields; } }

just tried the new repeater updates and it seems like a perfect match for this request! almost. you would just have to hide the label of the repeateritem then it looks really nice! keep in mind that selectors could get more complex when using this approach!

Check out Profields Table, Repeater or Profields Repeater Matrix, PageTable (can't find a good link for this but it's an installable core module).

You might want to correct your meta keywords. <meta name="keywords" content="echo $homepage->keywords;">

Hi everyone, Here's a new module that I have been meaning to build for a long time. http://modules.processwire.com/modules/process-admin-actions/ https://github.com/adrianbj/ProcessAdminActions What does it do? Do you have a bunch of admin snippets laying around, or do you recreate from them from scratch every time you need them, or do you try to find where you saw them in the forums, or on the ProcessWire Recipes site? Admin Actions lets you quickly create actions in the admin that you can use over and over and even make available to your site editors (permissions for each action are assigned to roles separately so you have full control over who has access to which actions). Included Actions It comes bundled with several actions and I will be adding more over time (and hopefully I'll get some PRs from you guys too). You can browse and sort and if you have @tpr's Admin on Steroid's datatables filter feature, you can even filter based on the content of all columns. The headliner action included with the module is: PageTable To RepeaterMatrix which fully converts an existing (and populated) PageTable field to either a Repeater or RepeaterMatrix field. This is a huge timesaver if you have an existing site that makes heavy use of PageTable fields and you would like to give the clients the improved interface of RepeaterMatrix. Copy Content To Other Field This action copies the content from one field to another field on all pages that use the selected template. Copy Field Content To Other Page Copies the content from a field on one page to the same field on another page. Copy Repeater Items To Other Page Add the items from a Repeater field on one page to the same field on another page. Copy Table Field Rows To Other Page Add the rows from a Table field on one page to the same field on another page. Create Users Batcher Allows you to batch create users. This module requires the Email New User module and it should be configured to generate a password automatically. Delete Unused Fields Deletes fields that are not used by any templates. Delete Unused Templates Deletes templates that are not used by any pages. Email Batcher Lets you email multiple addresses at once. Field Set Or Search And Replace Set field values, or search and replace text in field values from a filtered selection of pages and fields. FTP Files to Page Add files/images from a folder to a selected page. Page Active Languages Batcher Lets you enable or disable active status of multiple languages on multiple pages at once. Page Manipulator Uses an InputfieldSelector to query pages and then allows batch actions on the matched pages. Page Table To Repeater Matrix Fully converts an existing (and populated) PageTable field to either a Repeater or RepeaterMatrix field. Template Fields Batcher Lets you add or remove multiple fields from multiple templates at once. Template Roles Batcher Lets you add or remove access permissions, for multiple roles and multiple templates at once. User Roles Permissions Batcher Lets you add or remove permissions for multiple roles, or roles for multiple users at once. Creating a New Action If you create a new action that you think others would find useful, please add it to the actions subfolder of this module and submit a PR. If you think it is only useful for you, place it in /site/templates/AdminActions/ so that it doesn't get lost on module updates. A new action file can be as simple as this: <?php namespace ProcessWire; class UnpublishAboutPage extends ProcessAdminActions { protected function executeAction() { $p = $this->pages->get('/about/'); $p->addStatus(Page::statusUnpublished); $p->save(); return true; } } Each action: class must extend "ProcessAdminActions" and the filename must match the class name and end in ".action.php" like: UnpublishAboutPage.action.php the action method must be: executeAction() As you can see there are only a few lines needed to wrap the actual API call, so it's really worth the small extra effort to make an action. Obviously that example action is not very useful. Here is another more useful one that is included with the module. It includes $description, $notes, and $author variables which are used in the module table selector interface. It also makes use of the defineOptions() method which builds the input fields used to gather the required options before running the action. <?php namespace ProcessWire; class DeleteUnusedFields extends ProcessAdminActions { protected $description = 'Deletes fields that are not used by any templates.'; protected $notes = 'Shows a list of unused fields with checkboxes to select those to delete.'; protected $author = 'Adrian Jones'; protected $authorLinks = array( 'pwforum' => '985-adrian', 'pwdirectory' => 'adrian-jones', 'github' => 'adrianbj', ); protected function defineOptions() { $fieldOptions = array(); foreach($this->fields as $field) { if ($field->flags & Field::flagSystem || $field->flags & Field::flagPermanent) continue; if(count($field->getFieldgroups()) === 0) $fieldOptions[$field->id] = $field->label ? $field->label . ' (' . $field->name . ')' : $field->name; } return array( array( 'name' => 'fields', 'label' => 'Fields', 'description' => 'Select the fields you want to delete', 'notes' => 'Note that all fields listed are not used by any templates and should therefore be safe to delete', 'type' => 'checkboxes', 'options' => $fieldOptions, 'required' => true ) ); } protected function executeAction($options) { $count = 0; foreach($options['fields'] as $field) { $f = $this->fields->get($field); $this->fields->delete($f); $count++; } $this->successMessage = $count . ' field' . _n('', 's', $count) . ' ' . _n('was', 'were', $count) . ' successfully deleted'; return true; } } This defineOptions() method builds input fields that look like this: Finally we use $options array in the executeAction() method to get the values entered into those options fields to run the API script to remove the checked fields. There is one additional method that I didn't outline called: checkRequirements() - you can see it in action in the PageTableToRepeaterMatrix action. You can use this to prevent the action from running if certain requirements are not met. At the end of the executeAction() method you can populate $this->successMessage, or $this->failureMessage which will be returned after the action has finished. Populating options via URL parameters You can also populate the option parameters via URL parameters. You should split multiple values with a “|” character. You can either just pre-populate options: http://mysite.dev/processwire/setup/admin-actions/options?action=TemplateFieldsBatcher&templates=29|56&fields=219&addOrRemove=add or you can execute immediately: http://mysite.dev/processwire/setup/admin-actions/execute?action=TemplateFieldsBatcher&templates=29|56&fields=219&addOrRemove=add Note the “options” vs “execute” as the last path before the parameters. Automatic Backup / Restore Before any action is executed, a full database backup is automatically made. You have a few options to run a restore if needed: Follow the Restore link that is presented after an action completes Use the "Restore" submenu: Setup > Admin Actions > Restore Move the restoredb.php file from the /site/assets/cache/AdminActions/ folder to the root of your site and load in the browser Manually restore using the AdminActionsBackup.sql file in the /site/assets/cache/AdminActions/ folder I think all these features make it very easy to create custom admin data manipulation methods that can be shared with others and executed using a simple interface without needing to build a full Process Module custom interface from scratch. I also hope it will reduce the barriers for new ProcessWire users to create custom admin functionality. Please let me know what you think, especially if you have ideas for improving the interface, or the way actions are defined.

Custom Inputfield Dependencies A module for ProcessWire CMS/CMF. Extends inputfield dependencies so that inputfield visibility or required status may be determined at runtime by selector or custom PHP code. Overview Custom Inputfield Dependencies adds several new settings options to the "Input" tab of "Edit Field". These are described below. Note that the visibility or required status of fields determined by the module is calculated once at the time Page Edit loads. If your dependency settings refer to fields in the page being edited then changes will not be recalculated until the page is saved and Page Edit reloaded. Usage Install the Custom Inputfield Dependencies module. Optional: for nice code highlighting of custom PHP install InputfieldAceExtended v1.2.0 or newer (currently available on the 'dev' branch of the GitHub repo). The custom inputfield dependencies are set on the "Input" tab of "Edit Field". Visibility Show only if page is matched by custom find Use InputfieldSelector to create a $pages->find() query. If the edited page is matched by the selector then the field is shown. Show only if page is matched by selector As above, but the selector string may be entered manually. Show only if custom PHP returns true Enter custom PHP/API code – if the statement returns boolean true then the field is shown. $page and $pages are available as local variables – other API variables may be accessed with $this, e.g. $this->config In most cases $page refers to the page being edited, but note that if the field is inside a repeater then $page will be the repeater page. As there could conceivably be cases where you want to use the repeater page in your custom PHP the module does not forcibly set $page to be the edited page. Instead, a helper function getEditedPage($page) is available if you want to get the edited page regardless of if the field in inside a repeater or not. $edited_page = $this->getEditedPage($page); Required The settings inputfields are the same as for Visibility above, but are used to determine if the field has 'required' status on the page being edited. https://github.com/Toutouwai/CustomInputfieldDependencies http://modules.processwire.com/modules/custom-inputfield-dependencies/

Tense Tense (Test ENvironment Setup & Execution) is a command-line tool to easily run tests agains multiple versions of ProcessWire CMF. Are you building a module, or a template and you need to make sure it works in all supported ProcessWire versions? Then Tense is exactly what you need. Write the tests in any testing framework, tell Tense which ProcessWire versions you are interested in and it will do the rest for you. See example or see usage in a real project. How to use? 1. Install it: composer global require uiii/tense 2. Create tense.yml config: tense init 3. Run it: tense run For detailed instructions see Github page: https://github.com/uiii/tense This is made possible thanks to the great wireshell tool by @justb3a, @marcus and others. What do you think about it? Do you find it useful? Do you have some idea? Did you find some bug? Tell me you opinion. Write it here or in the issue tracker.

Hi community, i'am not a pro in module creation and i need someone, who build it better. What my stuff at this time does: there is a page "Standard". This Page can upload into OR select Images from "Image Library". The pages inside "Image Library" are simple pages with a imageField (single) inside. The page "Standard" looks like this: "Select existing Images" ist a pageField. The Inputfield is a AutocompleteField with preview oh the selected pages (from "Image Library"). "Image (add if not exists)" is a imageField (multiple) this two fields togehter and some hooks are the core of my project. select a image form the list, or upload a new one. The Module has to parts: The new Autocomplete Inputfield for FieldtypePage and a processing for the imagefield via hooks. Lets start with the ImageField: Upload a Image(s) like everytime in Processwire. After hit "Save": a "Page:saved" hook is checking if the image is already in the Library is checking the basename. if basename already exists, the code compares the two images by pixelanalysis(!) if in Library already: then add the existing Page with this image to the PageField field if not: create a new page with template "Image", add the image there, and add the new page to PageField after all: remove the image from this page (because we linked the image via a page) The pageField is a clone of the existing InputfieldPageAutocomplete, but i extended that with little new function: display images in ___rendeListItem() and the javascript-version after AJAX loading. In my module, you can use as a new label specific string img:{a_image_field.url}:img. This pageField automatically controls the imageField. The selected Parent and Template is the path for new Pages and there Templates. I'am testing a lot with this new components. Works fine. I Like this solution for pages where many images are allways the same (like a product-catalog). Download the zip and have a look. Installation Follow this steps: Install module "InputfieldPageAutocomplete2" install module "ImageUploadOrSelect" create a Template "Image" now we need a unique name for three fields. For example: "loremipsum". create a field of type image, call it "imageuploadorselect_imagetarget_loremipsum". this field is single image field. no array output! add the field "imageuploadorselect_imagetarget_loremipsum" to template "Image". create a field of type image, call it "imageuploadorselect_imagestemporary_loremipsum". this field is multiple. array output! add this field to a template you decide. For example "basic-page". create a new field of type Page, call it "imageuploadorselect_pages_loremipsum". set up this field like in the image above. Parent: a page you decide (where pages with template "Image" will be created) Template: Image Labelfield: custom Custom page label format: {title} img:{imageuploadorselect_imagetarget_loremipsum.url}:img Inputfieldtype: "PageAutocomplete2". add this field to template from step 8, where the imageField also is. I would be very happy if someone could help. How i sad before, i'am not the pro. I looking for somebody who could help me to merge this stuff in one module to share it in the community. I commented all the things in the files. There are a lot of detailed information. Have nice weekend! modules.zip

Google's Matt Cutts: Source: YouTube

In some modules I am conditionally loading JS to the module config page like this: if($this->input->get->name == $this->className) { // load script }

Works very nicely. Thank you again @kixe

With a little experience in PW: Yes it is. Have a look at 'JqueryWireTabs' module. There is a small readme file. Check out this. Furthermore you need to instantiate 'WireTabs' via JavaScript.

Great - now you could target using ".InputfieldRepeater[data-min="1"][data-max="1"]" in your CSS. Be aware that you will need to set display: none, and also remove the padding on .InputfieldContent too. In this regard a hook would be better to add skipLabel (and setting field->label="" as skipLabel works only this case afaik) with PHP.

So to answer the question of your entry post: namespaced files are never compiled. The compiler is mostly meant for 2.x to 3.x transition. As pw 2.x is namespaceless the compiler does only work on files without namespace (also makes things easier to control). So you would probably be fine if you could push all the 2.x / 3.x differences into a separate class without namespace. <?php class Bridge extends Wire { public function getNew($shortname) { switch($shortname) { case 'InputfieldWrapper': return new InputfieldWrapper(); default: throw new WireException("Classname $shortname isn't setup or is invalid."); } } }

your post kinda proves that it is a good idea to hide the label. because in my example it is already hidden that's the original setup: the whole dark line is unnecessary and counterproductive!

If there's a CSS class that identifies that it's a one item only field then you can easily hide with CSS (eg admin.css with aos).

you can now use repeaters for that! @tpr maybe hiding the label when using it with limit 1/1 would be an option for AOS?

static:: (/late-) binding will result in each class doing their own calculation. You probably would want to use self:: so it's really a one time calculation for all of your classes.

How about storing the result of the function selection in a static variable, so the computation does only happen once per request. The namespace won't magically switch mid request.

@godmok, what is the maximum number of words you can put into this search query before you hit the MySQL limit? I would have thought that would be a lot of words; more than any person would type into a search input. I have a site that explodes and loops over all search terms using the %= LIKE operator, searching within 12 fields. I can throw whole paragraphs of text into the search input without coming up against any MySQL limit.

@Macrura, I also haven't looked in detail at Qualtext's module, and there are some similarities to both Selectize and Media Manager. But at a glance I can see some differences from Selectize: Image upload > page creation is included in the module. Uploaded images are pixel-compared for uniqueness to avoid duplicates. The ajax-loading features that come with extending InputfieldPageAutocomplete would be useful if you have thousands of image pages. Ajax-loading is possible with the jQuery Selectize plugin but not offered out-of-the-box in your PW module (please correct me if I'm wrong there). So a very worthy contribution to the PW module ecosystem I think.

i didn't study your posts, but i'm pretty sure what you are doing is all easy to accomplish with the Selectize input field; i do that all the time, in fact i have (e.g.) a media select field that dynamically shows all of the media in my media library, including the media type (image, file, audio, video) and can dynamically show images if/when they exist, as well as image dimensions, and any other info. Maybe take a look at this and see:

Just take a look at these changes: https://github.com/LostKobrakai/MarkInPageTree

Hi @Qualtext, Nice job on the modules! Most of us around here are not true pros, and I don't think you need a pro to finish off your modules - you're doing great so far and you're nearly done. Just stick at it. You've probably seen it already, but this is the docs page that is particularly useful for module development: https://processwire.com/api/ref/module/ The bits I quote below are from this page. It isn't necessary to merge everything into a single module file. It's not unusual for a single module release to actually contain two or more modules. Put both modules inside the same directory, decide which is the primary module and have that module install the other automatically by using the "installs" property in the getModuleInfo() array. This takes care of item 1 or 2 in your list of installation steps. Another thing you could do to finish off your modules for release is add code that creates some of the required pages and templates. You can use the ___install() method to do this. In your list of installation steps I think your install method could potentially take care of the following items: 3,4,5,6,7,9. Items 8 and 10 you leave up the user. Search the forum and API docs and look at the code of other modules to understand how to create templates, fields and pages via the API. Give your auto-created templates/fields/pages names that are unlikely to be already in use, e.g. prefix them with the name of your module class. The labels/titles can be anything though. Here are some links to start with:

Never thought that the "Always show pagelist actions" could be beneficial to me but I was wrong. While setting editor access, it is handy to see whether they are able to add new pages to a page or not, without needing to hover the pagelist item. Btw, here's a trick I use to simplify setting up roles. I use the same "basic-page" template for several pages, and some of them may have children, some not. But you can't set it page level, only at template level. What I do is create a new template "basic-page-nochildren" and set it's fieldgroup to "basic-page" (need to set $config->advanced to see this feature on the template edit page). Then assign these templates to pages that shouldn't have children, and because of the same fieldgroup, they will also have the same fields as "basic-page". Update: don't forget to make the template "basic-page-nochildren" viewable by creating a template file for it, or set the "Alternate Template Filename" to "basic-page" on "basic-page-nochildren" template (Files tab)

I've found the problem. There is a method getCoreBranches which returns the branches already loaded in session if the second parameter is false. But it is never called with the second parameter set to true: https://github.com/ryancramerdesign/ProcessWireUpgrade/blob/5333322703f0f47a6d6454e8fdb3107db330eec4/ProcessWireUpgradeCheck.module#L171 So I changed temporarily the call and it works now. But I gues it should be enough to relogin.

Definitely working here. Have you done a Modules > Refresh? Maybe it is caching the source?

You could group some config fields inside a fieldset and set it to collapsed. $fieldset = $this->modules->get("InputfieldFieldset"); $fieldset->collapsed = Inputfield::collapsedYes; // add some fields to $fieldset

Not sure what your goal is, with all child pages from a parent you mean all siblings, right? Do you want to select them? Use the page field: Create a field: Details Tab: Input tab: Add the field to your template. Now the Siblings are listed on your page edit screen:

It's now available in the modules directory: http://modules.processwire.com/modules/process-admin-actions/ It also includes a few new actions. The first post and the Github ReadMe give a small description of each action. Hope you all find something useful among them. Again, please feel free to contribute some actions, or if you have an idea but don't know how to build, let me know and maybe I can put it together.

This is not a bad idea, I'd like to see a tutorial/guide of how to implement a REST API with common best practices and possibly the correct way of getting the image/repeater fields and show how to use query selectors with limits, pagination etc.

What you are describing is already what PW is for the most part. Though maybe there's additional helpers that could be added to support the front-end developer as you mentioned, I'm not sure. But what simpler context for a REST API could you have than what PW already provides? My experience has been that this kind of module is counterproductive – I deleted the web services module I'd built awhile back because I thought it costed people time rather than saving it. Maybe what's needed is a guide showing you how to implement a simple REST API on your own, without any module, since PW already makes it easy. But I appreciate your comments and will certainly look further into both options. That's basically a theme – what WordPress, Drupal, etc. are for. I'm not against the idea as something for us to collaborate on as a community, but from the core standpoint, it's the opposite of what the core aims to provide. Great ideas regarding the "community" profile, and I think it makes a great community thing, just not a core thing. I don't want to blur the line between PW and platforms like WP, Drupal, etc. Though I do think it's good to show that PW can do these things too. But if we had community efforts like this (and more diversity of profiles separate from it) the core really wouldn't need anything other than a blank profile. Though until that time, I do still think it's good for the core to demonstrate the diversity of output possibilities at the simplest level. These are still on the roadmap and have been for awhile. What gets implemented depends on resources, but front-end image resizing seems like it's got good potential for the near future, while front-end $pages API may take longer (but I still hope to accomplish that for 2017). Chances are I won't be the one developing the front-end image resizing stuff, as the ideas were brought in by another person, and I know little about it. But it is also one of the features that gets me very excited, so hopefully we can get some momentum going on this soon.

@ryan I have a suggestion regarding the Roadmap. Why not providing a REST API as a pro module or in the core? Headless CMS are on the rise and there's a huge market of Front End developers (Angular, React, VueJS) that would love this. Caching and JWT auth integration would also be appreciated. At the moment setting up a REST API requires a little bit of set up, which may be trivial for a PHP developer but a little difficult for a Front End developer. For example looping all fields, by default won't show image fields or repeater fields, you have to add specific code to get them properly.

Congratulations on release Ryan! Yesterday I spent some time to browse the API Explorer on demo site and I have to agree that ProcessWire documentation is top notch! Huge improvements over what we used to have and way ahead of most projects.

Very useful! I use it in combination with opening hours. For this reason I have created a repeater with 7 repeats (one for each day). In this case it prevents the customer from deleting or draging a weekday from the repeater list.

I also have a copy of the script that optionally handles deletion of the source variations too. I'll post that when its had some more testing.

Although this thread is somewhat «old», I'll add my two cents here from my experience as a new user: Following a short tutorial that taught how to add Meta-Tags for every page, I found two things: how to make a FieldsetTab and now to make fields global. To my surprise, I was able to make the fields global, but not the FieldsetTab. Which results in one template having a nice Tab grouping the Meta-Tag fields together and on all other pages they just linger around somewhere. This ain't a dealbreaker, but it surely isn't very handy either. All the suggested workarounds in this thread are just that: workarounds. I totally agree with bernhard and his usecases that such a functionality would be great to have and in some circumstances is even a necessity. And no, the template setup batcher isn't really an option, either, it's just another workaround that's unintuitive and cumbersome to use. It already hit me when I was introduced to PW that for bigger projects one accumulates a ton of fields and it occured to me that it gets pretty messy pretty fast. Grouping fields logically would be another great feature that would make the clusterf*** I witnessed on some of the projects that were showed to me much easier to handle. I'm far from being an expert in PW but one of the things that I read over and over by all the PW evangelists is its flexibilty. A.k.a. if you need it you can build it. But something that simple (and quite frankly very obvious) can't be built? I'm baffled, really...

When I'm importing data, I usually add a ProcessWire field called legacy_id. Any import script will set this value to the actual ID from the item in the old dataset. It helps the script easily and accurately find existing imported items, and you can keep this around for a little while after so you can trace it back if you need to.

There is one thing that needs a bit attention when importing data. We need to check if a record was also imported by a previous run of the script, otherwise you may end up with numerous duplicates. while($row = $result->fetch_assoc()) { $title = wire("sanitizer")->text($row['title'], array("maxLength"=>128)); // fetch and sanitize the title $p = wire('pages')->get("title={$title}"); // check if it already exists if(0 < $p->id) continue; // move on to the next record if it exists $p = new Page(); $p->template = "dam"; $p->parent = "something"; $p->title = $title; // use the sanitized title $p->save(); }

$myDB = new Database('localhost', 'username', 'password', 'db_name', 3306); $result = $myDB->query("SELECT * FROM my_table"); while($row = $result->fetch_assoc()) { $p = new Page(); $p->template = "dam"; $p->parent = "something"; $p->title = $row['title']; $p->save(); }

Users don't represent viewable pages on the front-end so you may want to connect them with some other template by way of URL segments. i.e. $username = $sanitizer->pageName($input->urlSegment1); if(empty($username)) throw new Wire404Exception(); $page = $users->get($username); if(!$page->id) throw new Wire404Exception(); // prevent superuser or users that don't have a specific role from being viewed if($page->isSuperuser() || !$page->hasRole('some-role-you-want')) throw new Wire404Exception(); $page->of(true); // now you can continue just as if this were the user template // as $page now represents a user As for finding users by role, try adding "check_access=0" or "include=all" to the selector. Those user pages are going to be protected from normal access, so adding one of those to the selector makes them accessible to the find().