Leaderboard

Sites Manager 16 September 2018: FOR NOW, PLEASE DO NOT USE THIS MODULE IN A PRODUCTION SITE. A RECENT ProcessWire UPDATE HAS BROKEN THE MODULE. I AM WORKING ON A FIX. ################ Sites Manager is a module for ProcessWire that allows Superusers to easily create/install ProcessWire sites on the same serverspace the module is running in. Only Superusers can use the module. You can create both stand-alone and multi-sites. Single/Stand-alone Sites Stand-alone or single-sites are sites that will run in their own document root/directory with their own wire and site folders, .htaccess, index.php, etc. In other words, a normal ProcessWire site. Multiple Sites Multi-sites are sites that will run off one wire folder (shared amongst two or more sites) each having their own site folder and database. In this regard, it is important to note that Sites Manager is not in itself a multiple sites solution! Rather, it is a utility that helps you create multi-sites to be run using the ProcessWire core multiple sites feature. For more on this core feature, see the official ProcessWire documentation, specifically the solution referred to as Option #1. Option #1 approach requires the site admin to initially install ProcessWire in a temporary directory for each new site. The directory then needs to be renamed as site-xxx, where ‘xxx’ is any name you want to use to differentiate the installation from other sites, before it is moved to the webroot. For instance, site-mysite, site-another, site-whatever. In addition, the /wire/index.config.php file must be copied/moved to the webroot. Each time a site is added, the index.config.php has to be edited to add ‘domain’ => ‘site-directory’ key=>value pairs for the site. This process can become a bit tedious. This module aims to automate the whole multi-site site creation process. The module is based off the official ProcessWire installer. Creating a site is as simple as completing and submitting a single form! You also have the option to type and paste values or reuse a pre-defined install configuration. The module will: Install a ProcessWire site in your named directory, applying chmod values as specified Move the directory to your webroot Update/Create a Superuser account as per the submitted form, including setting the desired admin theme and colour For multi sites, update sites.json (used by index.config.php to get array of installed sites) For multi sites, the only difference in relation to the core multi-sites index.config.php is that this file is slightly different from the one that ships with ProcessWire. Download from GitHub: Sites Manager (Beta Release) Features Install unlimited number of sites in one (multi-sites) or independent (single-site) ProcessWire installs. Install by completing a Form, Typing or pasting in configurations or using pre-created install configurations. Choose an Admin Theme to auto-install along with the site installation. For single-sites installation, download, save and reuse ProcessWire versions of your choice. Install and maintain site profiles for reuse to create other sites. Create install configurations to speed up installation tasks. Client and server-side validation of site creation values. Edit uploaded profiles (e.g., replace profile file). Lock installed sites, configurations and profiles to prevent editing. Bulk delete items such as site profiles, installed site directories and/or databases (confirmation required for latter two). View important site details (admin login, chmod, etc). Links to installed sites home and admin pages. Timezones auto-complete/-suggest. Pre-requisites, Installation & Usage Please see the documentation. Technicalities/Issues Only Superusers can use the module. ProcessWire 2.7 - 3.x compatible Currently using ProcessWire 2.7 installer (install.php) For multi-sites, potential race condition when sites.json is being updated on a new site install vs. index.config.php accessing the json file? Not tested with sub-directory installs (for instance localhost/pw/my-site-here/) Currently not doing the extra/experimental database stuff (database charset and engine) Future Possibilities Install specified modules along with the ProcessWire install Profile previews? Credits @ryan: for the ProcessWire installer @abdus: for the index.config.php reading from JSON idea @swampmusic: for the challenge Video Demo Demo showing how quick module works on a remote server [YMMV!]. Video shows downloading and processing two versions of ProcessWire (~takes 7 seconds) and installing a single/stand-alone ProcessWire 3 site using the new Admin Theme UI Kit (~2 seconds) on a remote server. Screens 1 2

Really cool project. I am used to developing individual sites that with separate wire directories but it gets tedious to update each and every one of them, and not to mention duplicate /wire/ directories. I was thinking of moving to the official multi-site solution, but I'll start with your module. Thanks for sharing it with us. Although for simple configurations this may not matter, I've found out that using PHP files for configuration files are much easier to handle, and doesn't need parsing at all. It's as simple as this: <?php // mysite.config.php return [ 'site' => 'mysite', 'domain' => 'mysite.com' ]; <?php // ConfigReader.php $configs = []; foreach(configFiles in configDir) { $configs[] = include(configFile); } https://github.com/mrkrstphr/array-config To export as php configuration files you can use http://php.net/manual/en/function.var-export.php Major disadvantage is that it's php only whereas JSON is almost universal.

I fully agree with Lance. Firstly, a HUGE thank you to Ryan for doing this. It was badly needed and the only thing that held me back on converting some of my legacy ModX sites. I love PW and this was the missing piece for me. I can't thank Ryan enough for turning his attention to this sorely lacking functionality that almost every other CMS has. However, I'm very sad that this isn't a pro module. Rather than being part of the core to "guarantee" attention and updates (as others above have indicated), I would have preferred this to be a paid module to ensure such attention and updates. That's not to say Ryan won't be maintaining this module in a reasonable fashion, just that this is a huge enough component of a CMS that it absolutely could have warranted being a pro module and there are many of us that would have gladly paid for it. I will gladly use this module, provide feedback on bugs, questions on customizing, etc. and hope that all such things are attended to in a timely manner. While I appreciate that it is *FREE*, Ryan, please consider making it a pro module. I'm sure you have your reasons for not doing so and I guess I'm just worried it won't get the attention it deserves. It will be critical to many of my membership sites that I will now convert to PW and thus I'm worried about future development on it. Things like images support are crucial and if this was a paid module, may be higher up Ryan's priority list.

There must be a misunderstanding here. When you upload a file in WordPress, it lands in /wp-content/uploads/... Also, modules normally write all sort of files into /wp-content/... Am I missing something? Normally in WordPress no "files" are stored in the database, the most complex thing in the db is JSON. If you are talking about hosting companies trying to force you not to use your webserver for file sharing – well – that is a different story... I would not worry about files being an issue. A WordPress site with lots of plugins usually means 10000-30000 files, whereas a ProcessWire site with lots of modules is 2000-5000 files, excluding uploaded media files, of course.

pw give us the flexibility to customise the admin part. for backend part to avoid the admin's user confused about the 'Pages' concept, I just simply rename the Pages label into Dashboard.

https://www.baumrock.com/portfolio/individuelles-crm-und-controlling-tool/ I'm happy to share my biggest and most interesting ProcessWire project so far with you It's a 100% custom office-management solution that helps my client to keep track of all their contacts, projects and finance/controlling stuff. Conception was done back in 2016 and the software is productive since begin of this year. My client is very happy with the result and so am I. Some technical insights: Everything is done inside the PW Admin. I'm using the Reno Theme with some custom colors. In the beginning I was not sure if I should stay with the pw admin or build my own admin-framework but now I'm VERY happy that I went with PW Almost all of my custom Process Pages use my RockDatatables module - there are still some limitations but without it, this project would not have been possible For the charts I used Google Charts and chartjs - both play well together with the datatables and make it possible to display filtered data instantly: also my handsontable module was created for this project to have a nice and quick option for matrix data inputs: Lister and ListerPro were no options as i needed much more flexibility regarding data presentation (like colorization, filtering and building sums of selected rows): invoices are highly customisable as well and easy to create. PDFs are created by php and mPDF by the way: all data is dummy data populated via my Module RockDummyData have a nice weekend everybody

Using Database class is actually quite straightforward. It's nothing but a wrapper around PHP's PDO class with some PW specific features. You prepare a SQL statement using prepare() method, then bind input values, execute() it and fetch() the results. <?php namespace ProcessWire; // sanitization $tableName = inputPost()->text('table'); $columnName = inputPost()->text('column'); $id = inputPost()->int('id'); // this is where you'd sanitize user input to prevent SQL injection $table = database()->escapeTable($tableName); $column = database()->escapeCol($columnName); $q = database()->prepare("SELECT `$column` FROM `$table` WHERE id = :id"); $q->bindValue(':id', $id); // always bind values instead of concatenation // $success = false; $values = null; try { $success = $q->execute(); $values = $q->fetchAll(); } catch (\Exception $e) { wire()->log($e->getMessage(), Notice::log); } if (!$success) { // handle error } if ($values) { // use values } To see how PW utilizes this class, check out Fieldtype.php, FieldtypeMulti.php, PagesEditor.php and PagesLoader.php from the core.

@benbyf, What you need is an inputfield that extends InputfieldTextarea and implements at least render() and processInput() methods. Using some JS and a process module you can let user select a folder and save it to the textarea. Start by creating a class that extends InputfieldTextarea, and add a button that fires up a modal to an intermediate process module. You use this module to show a list of folders that user can select using DropboxAPI. then when you get the input from the modal (check out JavaScript files for pwimage and pwlink CKEditor plugins, and ProcessPageEditImageSelect and ProcessPageLinkSelect modules), you save it to a (hidden) textarea (that you rendered in render() method). Using processInput() method you then validate the folder path, clean it up and send it to PW to save on the DB.

exactly what i was talking about here: see also @abdus comment on top of page2 i don't like site profiles. i think they are far too unflexible mostly because of the reason kongondo said. a possibility to define modules that get installed by default would be great! maybe this module could be extended to a kind of advanced PW installation kit? for example it could also be nice to use it to install a single-site setup in a different directory on the server (in other words, having the possibility to choose wheter the new site should be installed as single or as multisite). it would also be easy to choose the core version to use for single-site setups by defining the URL like this: https://github.com/processwire/processwire/archive/3.0.36.zip or that https://github.com/ryancramerdesign/ProcessWire/archive/2.7.2.zip thanks for creating and sharing this module with us kongondo!

No, they are not different. I have not used ProcessExportProfile (but I've been thinking, how nice we have it; it will play nicely with ProcessMultiSites). I assume though that it exports the same type of profiles that ship with ProcessWire (the site-default, etc). so it should work. What I meant is that, say, you have a blank profile. You want to use that to install several sites. Those sites have different module needs. When creating a site you will be able to paste or select module class names to fetch (live) and install along with the site creation. I haven't thought it through properly and it would mean a delay while the modules are being downloaded.

To live on the bleeding edge

Created a Process Module for this .

Hi @MrSnoozles Have you seen this thread

I've been using bootstrap for the last three sites. However, I'm not getting on with the lack of mixins so I thought I'd give uikit 3 another go with the many hooks available. Thanks for the tips @AndZyk

Yeah, I had similar thoughts when drafting the module. This is quite easy to accomplish. Actually, one other reason the module is alpha is that it could end up being more than a multi site thingy, hence I would need to change the Class name. Cool idea. I'll have a think.

so why do you do that?

Cool stuff! The profiles you mention: are they a different format from the profiles produced by ProcessExportProfile? Just wondering because you said... ...but site profiles from ProcessExportProfile can include modules, so wasn't sure.

That's the normal behaviour. Have a look at this thread for a solution:

OK, so the host provider told me that I had done something wrong (had chosen the wrong server) when creating the database, then just a minute later they informed me that they have corrected the error. (?) This made it possible to log in to phpMyAdmin, and import my db without any problems, but the frontend was still inaccessible giving me 404 error (as far as I got it, it was some kind of mismatch between index.php and config.php). No magic helped there, so I deleted all the site files via FTP, then reuploaded them. Of course, here I needed to modify config.php accordingly (as I reuploaded a localhost installed site). After this step, my frontend came alive & working. Still struggling with some minor issues, but that is for another day.

I have to agree that I don't think this module needs to be part of core. But I do think that it needs to remain in active development, even if that means it becomes a Pro module. Modules like ListerPro (which I love and use all of the time) bring value to a project, but they aren't necessarily defined as a project requirement by the client. However, if a project requires the functionality of Login/Register/Profile, this module may mean the difference of a client agreeing to use ProcessWire over another CMS. To me, that's a game changer, and is why it has been on my wishlist for some time. I've already started using it for a community project that I've wanted to build, although I'm hoping that it will play nicely with images very soon.

This module has been out 2 weeks, if in 6 months it is full of bugs and security issues and nothing is being done let's revisit this post. There should be positivity around this, not negativity.

@ryan is usually pretty adamant about extending the core for a feature that very few people will use. So I doubt he'll agree on that. Because it would mean rewriting a good chunk of the core and breaking many 3rd party modules, or having to maintain a separate set of underutilized classes. Feel free to open up an issue, though. If you study PagesLoader class you can figure out how PW fetches fields from their respective tables and maybe develop a module that works aside the current implementation. I, for one, wouldn't mind using something along the lines of: $list = $db->pages->posts->where('title.length>5')->fetch(['title', 'name', 'body']);

Yeah I agree. It's too verbose for starters. But you're free to use any PDO / ORM library over ProcessWire's. You can get database credentials with $config->db<key>, and use it anyway you'd like. But unless you're using custom tables, you'll have to join multiple tables to get a meaningful output from pages/templates/fields, all of which PW provides out of the box for you.

Jupp, but I generally think PDO does not have a nice Api, and is cumbersome to work with. That's why I was suggesting to unify it and make it easier to work with. It definitely should stay conform with pdo. But I think concatenating strings to create a query is just not a great developer experience. If you could pass arrays and the library would do the query concatenation would be amazing. (i'm on the phone now so I can't post code, but I will try to add an example of how this feature could improve code cleanliness compared to pdo)

Hi, I ran into this issue a while back and remember fixing it but haven't pushed to master. I will have to look into it. I think it might work on the dev branch, not sure though. Edit: yup it's fixed on the dev branch. I use it on a production site, but I appreciate any quick testing in your environments, so that I can merge it into master, if no further issues arise. Thanks for reporting!

ProcessWire's database abstraction is the best of all CMS systems I know.

sometimes it can be a little tricky, that's true. but usually it is not. do you know the rendernav function of the default site profile? /** * Given a group of pages, render a <ul> navigation * * This is here to demonstrate an example of a shared function and usage is completely optional. * * @param array|PageArray $items * @param int $maxDepth How many levels of navigation below current should it go? * @param string $fieldNames Any extra field names to display (separate multiple fields with a space) * @param string $class CSS class name for containing <ul> * @return string * */ function renderNav($items, $maxDepth = 0, $fieldNames = '', $class = 'nav') { // if we were given a single Page rather than a group of them, we'll pretend they // gave us a group of them (a group/array of 1) if($items instanceof Page) $items = array($items); // $out is where we store the markup we are creating in this function $out = ''; // cycle through all the items foreach($items as $item) { // markup for the list item... // if current item is the same as the page being viewed, add a "current" class to it $out .= $item->id == wire('page')->id ? "<li class='uk-active'>" : "<li>"; // markup for the link $out .= "<a href='$item->url'>$item->title</a>"; // if there are extra field names specified, render markup for each one in a <div> // having a class name the same as the field name if($fieldNames) foreach(explode(' ', $fieldNames) as $fieldName) { $value = $item->get($fieldName); if($value) $out .= " <div class='$fieldName'>$value</div>"; } // if the item has children and we're allowed to output tree navigation (maxDepth) // then call this same function again for the item's children if($item->hasChildren() && $maxDepth) { if($class == 'nav') $class = 'nav nav-tree'; $out .= renderNav($item->children, $maxDepth-1, $fieldNames, $class); } // close the list item $out .= "</li>"; } // if output was generated above, wrap it in a <ul> if($out) $out = "<ul class='$class'>$out</ul>"; // return the markup we generated above return $out; } another hint that may help: sometimes it is a lot easier to use the has() method to check wheter to append an active-class or not. for example: // create a pagearray that has all the parents of the current page + the page itself, but not the homepage (id=1) $active = $page->parents('id>1')->append($page); // loop all items foreach($menuitems as $item) { // set menuitemclass active if the current item is part of the "$active" pagearray $cls = $active->has($item) ? 'active' : ''; // echo the item echo "<li class='$cls'><a href='{$item->url}'>{$item->title}</a></li>"; } ...would make the code much more readable than a lot of if-statements. also recursive functions help a lot to make the code cleaner.

Thanks @bernhard, that did not work as expected. I ended up using this multiple times. if($item->template->name == 'basic-page') This works as expected, but the only downside that a basic-page has to be the parent. On this site that will do just fine. It is rather inefficient, but this is a Multi language site so the menu title have to come from the pages.

Tracy Debugger

Hello, out of the topic, but what module is this? Thanks.

just replace your find() with a count(). find() returns an empty pagearray so the IF statement is TRUE:

$manufacturers = $pages->get("$page->rootParent")->find("pageManufacturer!=''"); // $count = $manufacturers->count; $count = $pages->count("has_parent=$page->rootParent, pageManufacturer!=''");

Not "as if" but it is WireArray. No need to loop, just use the method ->first()

great to hear that hm... what do you think of splitting it into 3 parts: some kind of advanced pw-installer a process module to handle multisite installations a single php file that grabs the pw-installer similar to the online installer from soma (https://github.com/somatonic/PWOnlineInstaller/blob/master/grabpw.php) hm... thinking about point 3 i'm not sure if that makes sens, but i'll leave it here for discussion. maybe it would be easier to do a git clone kongondos-great-pw-installer than creating an index.php, copying some lines of php that basically would do the same as my mentioned git clone?! what do you think? i think it would be great to make the installation process as easy as possible and on the other hand more flexible than the one we already have (yes, i know we already have site profiles and whoever likes them please continue using them ). so if the installer was able to install a list of modules it could also install point 2 of my list! i also think that this installer should be able to load standard setups of a pw-site from any url. be it a json file or some php-setup like abdus mentioned - don't know what would be better. but imagine an installer with one inputfield at the top that says: this would make it possible to save your own basic pw-setups as simple gists share setups with others (eg on the forum for debugging, similar to the concept of VMs) and all you would have to do was to put in an URL form the basic setup (that the browser should remember), choose admin username + password and database connection info. done maybe a lot of what i want is already doable by adrians module toolkit? but still i think the process of installing pw in general can be optimized. or am i just missing some great options we may already have (like wireshell for example)? or can we use composer like this?

Yes, this a recent trend which is against all common sense but we don't live in a world where common sense rules...

It only stores path and metadata for the files. Actual files go to site/assets/files folder. Migration is quite easy, just dump the database, import into remote server, update database credentials in config.php, upload files, check file permissions, and done. Or use Site Profile Exporter module

Looks great! Makes me eager to set up a multisite

I'm already having the latest graphics driver. I don't think that's possible to roll back to an older version of Chrome but I've just installed the latest beta version of Chrome 62.0.3202.45 and the issue is gone. Btw the images are blurry on the beta so I will uninstall it and wait for an update on the stable version. At least now I know that they fixed it. I will post again on the next stable version.

@Ivan Gretsky, if you have Imagick installed you could use this function I wrote a while back for easy ImageMagick effects: It does quite a nice blur. But now that supporting IE is less of an issue you could also try a CSS filter.

Thanks for tracking that down. Would you mind posting a new message on the Pro Drafts module board please ?

The other useful tool here is the Module Disabler panel in Tracy: https://processwire.com/blog/posts/introducing-tracy-debugger/#module-disabler-panel Alternatively if you decide to uninstall modules, make sure you have ModuleSettingsImportExport installed so that it takes care of backing up module settings so you can restore when you reinstall a module. Sorry, lots of self-promotion there

^ I like this a lot. The same reason as I liked the reno theme, the sensibly used horizontal space. My first reaction was: I just tried the demo here: https://processwire.com/blog/posts/uikit-3-admin-theme-updates/#Comment41064 And clicking on the big P logo did indeed open a sidebar, but on the right. Now I couldn't use this at all, clicking on the left, and then having to drag the mouse over to the other side of the screen... however, it may be possible for it to open on the left instead. A logo means 'Home' to pretty much every internet user on the planet. I would not expect in a million years for it to open a sidebar and I'm baffled by this design choice. Another bugbear of mine is having a scrollbar in a weird position. I am so used to it being on the edge of the window, having it further in is super annoying and the added tree here is for, I'm not really sure why it's here actually. I chose to edit the 'Home' page, what do I need the tree for? ...so the first thing I would do with this theme would be to lose that bar on the right. I'm editing a page, I don't need to see the tree, but: ...the scrollbar is still inset unfortunately. I'd lose this sidebar feature completely, i don't see how it adds value to the editing experience other than to distract. My ideal would be something simpler, like this (badly cropped, edited and joined) with options not repeated as much in a top bar and a sidebar: (Yes, it takes inspiration from the WP interface) ======================================= Now I don't intend for this to be one huge moaning session, the new theme certainly looks funky, so great work and thanks for the hard work on that! However, in terms of usability (especially for clients that aren't computer savvy who will be confused by things flying in all over the place), I'd personally stick with Reno with the fixed sidebar and all options shown:

Major speed improvement ! I have been in dialog with the Tracy core dev (David Grudl) for the last few hours and he has come up with a way to have all the advantages of the current version ("Master") of the Tracy core (including the AJAX bar), without the potentially huge speed penalty - the old ("Legacy") version was always much faster. On some servers, the new version was painfully slow at times. For those interested, the slowdown was due to the use of $_SESSION to store the content of the debug bar. This was sometimes huge (especially will all the custom panels this PW implementation has). This new version doesn't use sessions for the main bar and because the AJAX bar doesn't show the custom panels, the size of the session is kept MUCH smaller. This is brand new, but so far I don't see any side-effects, but please start using it and let me know if you come across any problems, or just feel free to comment on how much better it is! Maybe even drop David a thank you if you feel inclined.

@suntrop, I've updated my hook to include sorting by labels wire()->addHookAfter('ProcessPageEdit::buildFormSettings', function (HookEvent $e) { $page = $e->object->getPage(); if ($page->template != "my-template") return; $templatesField = $e->return->children->get('id=template'); $templates = $templatesField->getOptions(); // sort first asort($templates); foreach ($templates as $tid => $tname) { // remove incompatible fields $template = $e->templates->get($tid); if (!$template) continue; if (strpos($template->tags, 'my-template-compatible') === false) unset($templates[$tid]); } $templatesField->set('options', $templates); });

Starting with the modules or plugins, despite being productive initially, causes more issues in the long run. This is also, I think, the major disadvantage of WordPress. Majority of the backend is inaccessible to beginners, and the core is obnoxiously complicated. How can showing some posts be so difficult (you know, "the loop"). This forces you to use plugins over plugins and the only thing you learn in the process is how to prevent them from spontaneously disintegrate. I agree with what @Peter Knight said. Even though there are modules for most scenarios, I enjoy recreating those modules by hand, because I get to practice coding and explore new/better/faster approaches, and I also get familiar with the inner workings of ProcessWire. Maybe in the future I'll get bored of building things from scratch but then I'll have built an array of modules, templates, snippets, and will know exactly when to use which.

This fork of AdminBar (https://github.com/teppokoivula/AdminBar) can be very useful in this situation. Style it to match your site and it's a very quick way to give logged in users the ability to edit and add new child pages. It won't ever be as flexible as building your own frontend form and processing using the PW API, but it's very easy when you have complex forms to reproduce, especially if there is image upload and ASM type select fields to reproduce. This screenshot shows that you can add a "New +" child page when viewing the main portal parent. This screeencast shows editing an existing entry:

hi @The Frayed Ends of Sanity and welcome to the forum, of course you can change it! the easiest would be some css: #LoginRegisterForm > h2 { display: none; /* or */ font-size: 14px; color: red; font-weight: normal; } you can also hook into buildRegisterForm() and remove the description of the form. you can also add a markup inputfield to your form for any other HTML you need. or you can modify the markup on the client side via JS (of course that would not be the cleanest solution but sometimes easy fixes have their place...)

Hi, It is discussed somewhere in this thread. The problem is that a request like that is a request to the home page, and so the 404 event will not be triggered, and so Jumplinks cannot intervene and do the redirect. You will need to use .htaccess to redirect all of those requests to something that Jumplinks can handle. Unfortunately, this will result in two redirects every time, but it's something you would need to work with in order to use Jumplinks. In your .htaccess file, add the following on line 99 (just below AddDefaultCharset): RewriteCond %{QUERY_STRING} ^main=(.+)$ [NC] RewriteRule ^$ /rq [R=302] When you request example.com/?main=something, it will be redirected to example.com/rq?main=something, and then you can create a jumplink for it.

Hello @Dee Welcome to ProcessWire! As stated above, it is recommended that you familiarize yourself with the "manual" (more like semi-automated) standard installation process. I wrote a step-by-step guide for cPanel, you might want to check it out: http://szabesz.hu/blog/install-processwire-in-a-subfolder-on-shared-hosting-cpanel_ins-sub/ In my tutorial I explain how to install websites running "side-by-side" from the same cPanel account, you might want to stick to it. When I'm writing about the "Regular Site Profile", just use this one instead: https://github.com/dadish/pw-skyscrapers-profile as currently this is the only easily installable up-to-date version of Skyscrapers Profile. Please read the "Warning!" in its readme to make adjustments as described (FieldtypeMapMarker dependency). The other profile I recommend exploring is the "Regular Site Profile". These two should give you an idea of how things are wired together with ProcessWire. Have fun with ProcessWire and just ask for help should you get stuck.

Status update: JsonNativeField version 0.0.4 now has configuration options for all field types in the field's input settings. Coming up next is some more data validation (i.e. "don't shoot your foot" checking) both in the UI when switching input type and in the module code when saving to and loading from the db. This will be the major step towards moving the module from alpha to beta stage.