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!

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.

Tracy Debugger

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

$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()

@DV-JF I came across a similar issue. I'm using a page reference field to select several pages containing just 1 image per page. As Ryan describes in this post. I haven't checked for the frontend yet, but in the backend I'm getting the same error. So even though the image field in the referenced pages is set to contain just 1 image, I have to loop through it as if it's a WireArray. I changed your code in way that worked for me: foreach($page->rep_imgTitleBody as $item) { foreach($item->sing_img as $image) { $img = $image->size(600,400)->url; $out = "<img src=\"{$img}\" alt=\"{$item->title}\">"; } }; @MadeMyDay Is this an expected behaviour? I'm using ProcessWire 3.0.77 and PageTableExtended 2.3.3

@kongondo, It was a joy to wake up and see this effort you have undertaken! Good luck on making this work.

Sorry, my bad. It does store them in uploads. What I intended to say is that files in the Wordpress setup are ok, but recently on a non Wordpress site, my host deleted all my mp3 files that where displaying on the site as podcasts, stating they don't allow file storage, but they left the Wordpress mp3 alone. I'm now hosting files on Amazon s3.

Once again, you can do that by hooking processProfileForm(). Lets say you added a field 'images' to the system user template and you added the 'images' field to the module configuration, e.g. : then in ready.php : wire()->addHookAfter('LoginRegister::processProfileForm', function($e) { $form = $e->arguments[0]; // get the form foreach ($form->children as $field) { if($field instanceof InputfieldImage) { foreach ($field->getAttribute('value') as $value) { wire('user')->images->add($value); } wire('user')->save(); } } }); To show the image on the frontend, you can hook renderProfileForm().

Looks great! Makes me eager to set up a multisite

@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.

I used this line, (uncommented), to hide them. But maybe this will have side-efects if you use it together with core imagefields in your pages. Better to use it the way @PWaddict said!

@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.

I wouldn't start by installing a Module such as Blog etc. I believe for you, a better approach would be to gradually build your own from scratch. You'll learn a lot more that way. Start with a few individual pages based on a template called "blog-post" and add a few basic fields. Just title, summary and body would be fine. Once you can make and view them then try to create a blog overview or homepage displaying the title and summary of each and a link to each full post. Lets say that template is called blog-posts (plural) You'll get a real kick out of just being able to do that and you're just echoing simple tags and getting to know "foreach" statements. Then try to add a date field to each blog post and add that to both templates. Later you can try adding a main image, maybe even an author and then move onto tags and categories. I think you'll get much more enjoyment out of building your own and a better understanding of the fundamentals.

Install the Admin Custom Files module. On site/templates/AdminCustomFiles folder create a css file named ProcessPageEdit.css and add the following code: .InputfieldImageButtonCrop { display: none !important; } Then on the Admin Custom Files module settings at the "Activate for process" section select ProcessPageEdit, (Page Edit).

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...)

Hello @louisstephens, first of all great that you are giving UIkit a chance. I am coming from Bootstrap as well but UIkit is now my favorite framework so far. Here are a few points you mixed up: If you only have one item in a container you don't need a grid and instead can just use the uk-width-* classes. The class uk-grid-match is used for cards and makes your image stretched. Also it is not necessary if you only have one item. You should remove it. If you have a grid you should either define uk-child-width-* classes or assign uk-width-* classes to the items. Doing both is not very clean. If you care about validation, you should use data-uk-grid instead of uk-grid. Without the data attribute you get an error in the validation. Considering your logo: Even resized it will be very small on mobile devices. You should either think about a more compact logo or work with the picture element to show optimized versions. Regards, Andreas

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.