Kiwi Chris

I'm not sure whether it's an issue with the current version of the core (3.0.203), or some other interaction, but currently I'm getting a weird issue. All users, regardless of what branch they're restricted to, are being restricted to the same branch. ie branch restriction is happening, but regardless of what branch is specified, they all get the same branch. [edit] I seem to have found the source of the problem. It is an interaction between Multisite module and @kixe version ofAdminRestrictBranch. What seems to be happening, is that when a user logs in, they will get the full page tree of whatever domain they have logged in under, regardless of how AdminRestrictBranch is configured. In some ways that's desirable: log in under a domain, and only get that domain's page tree, but it's also a security issue, as if a user knows another domain in the same multisite setup, and logs in with the login that's supposedly restricted to the page tree for another domain, they can see the page tree of the other domain.

Thanks for sharing an interesting use of comments. I think I would find the hook code useful as I have FormBuilder and I can think of scenarios where I could use this. As a matter of interest, if you want to aggregate meta data from all comments and get an average rating for a given piece of meta data, what's the most efficient way to achieve this?

The ProFields Combo field and Table fields create SQL tables behind the scenes, but they're still fieldtypes, so are expected to be added to a ProcessWire template and are linked to the page tree. Sometimes that's not necessary or desirable. With regards to creating custom tables, I'm quite happy writing SQL statements for this, or using the generated CREATE TABLE statements with a database export from mySQL, or for that matter even other dialects of SQL, with a bit of editing if necessary. It's not hard to write a CREATE TABLE statement initially, then an ALTER TABLE statement if subsequent changes are needed. I think this would play nice with your RockMigrations module to generate SQL schema changes in code, and I don't want to turn ProcessWire into mySQLAdmin or Adminer which is installed with Tracy Debugger, but it would be nice to have an end user friendly UI to view and edit custom SQL tables in the ProcessWire admin. You have made me thing of something I hadn't considered, about how to migrate SQL listers and editing forms, if the InputField settings or fields to display in a lister change, but if they're accessible via the API, it should be possible to manage migrations in a similar way to ProcessWire native fields and templates.

@ryanFieldtypeCombo comes pretty close, but like you say, you define the table structure with the fieldtype. Also as a fieldtype it needs to be associated with a template, that links into the ProcessWire page tree, which isn't always desirable with SQL tables from an existing database. I'm thinking there would probably need to be two configurable Process modules. An ProcessSQLLister and ProcessSQLForm module. Names are just suggestions ProcessSQLTemplate could be another option however as it's not an output template, it's an admin UI for editing arbitrary SQL data. ProcessSQLLister would be similar to Lister Pro, except for selecting a source, you'd select an SQL table, then choose what fields from the table to display in the lister. Dealing with lookup fields which are similar to page reference fields, but can refer to an arbitrary database table would probably be the biggest challenge, but the basic lister should be pretty straightforward. Edit functionality would depend on a related ProcessSQLForm being defined for the specified table. ProcessSQLForm would involve picking an SQL table, then selecting fields from the table to include on the form in the order desired, and mapping and configuring a sane InputField type depending on the SQL field type. @kixe has already made FieldtypeSelectExtOption which can handle lookups from arbitrary SQL tables, so that InputField should be able to handle relational reference fields, and core InputFields should be able to map to other SQL fields types. For both, access control at the table level would be desirable. While access control at the field level would be technically possible, I don't think it's necessary at least initially, especially if it adds complication since the fields are SQL fields rather than ProcessWire fields. I can try to mock something up, but if someone else beats me to it, then feel free to go ahead. I think ProcessWire has all the nuts and bolts to do this, it's just a case of putting them together.

There weren't very many CMS/CMF platforms either. I started out with SSIs to start reducing redundancy and duplication, then ended up starting my own CMS around 2000, but I picked a loser in terms of development language, and I realised trying to maintain a CMS for a modest number of clients on my own wasn't really efficient use of time. Someone introduced me to ProcessWire in 2015, and since then nearly all my websites have been converted to it. Web development and database development have progressed together for me, so ProcessWire's separation of content and presentation, and strong access control are critical for me. I evaluated my other CMS platforms before I settled on ProcessWire and I simply didn't like them as they either had a steep learning curve or were too output focused or both. I wouldn't use Word to try to build a relational database, nor would I use WordPress. I think if there is one major thing still on my wish list, it would be the ability to have a UI using ProcessWire inputfields to create data entry forms for arbitrary SQL tables. A common scenario for me is converting offline databases (often Microsoft Access) to cloud based alternatives. Usually it's possible to restructure everything within ProcessWire's pages model, but sometimes I just want to be able to dump the data across and build a UI quickly with no need for data to exist within a page model. I've been playing around a bit looking at building module(s). I'd love the goodness of Lister/(Pro), but instead of picking a template, pick an arbitrary SQL table and specify fields from it, set access control etc in the same way Lister Pro woks, and then have I guess what I'd call an SQLTemplate where you'd pick an arbitrary SQL table, select fields from it, and for each one specify an inputfield, within the contraints of the SQL field type. Of course none of this data would be accessible within ProcessWire's page structure out of the box, however there's already $database->query() to execute an arbitrary SQL query and return a result set, so using arbitrary SQL data within templates is already easy, so the only bit missing is a UI to manage arbitrary SQL tables as easily as ProcessWire pages in admin, but it's already halfway there with inputfields that don't care where their data comes from.

There is an optional module in the core ProcessForgotPassword that you can install to enable people to reset their passwords if they forget. With regard to preventing even super-user role from changing any password other than their own, I think it could be done, but would require a hook in site/ready.php I'd imagine adding a hook before InputfieldPassword::processInput should be able to check the current user, and if they're not the same user as the password belongs to, then abandon any changes. I may not have the right hook method. A hook before Pages::save might be another option, as everything including users are 'pages' in Processwire, so the logic would be something like if($user->name != $page->name && $page->template == 'user'){ //Prevent page saving. } Someone else can probably help give a working example, or if I get time I can have a try and update my post once I've got something working.

In case anyone else finds it helpful, I've been having major issues with both the original deprecated and later version of the module described in this thread not working properly with the latest builds of ProcessWire (>=3.0.200) and it seems like this module hasn't had much love in a long time, but after poking around on Github, I found a fork by @kixe that works for me. https://github.com/kixe/Multisite/blob/master/Multisite.module

Interesting discussion, and I'll add a rather ironic perspective. I inherited a largely non-functional website project that someone else had built in Craft, about 3 years ago, and at the time I found the Craft documentation wasn't particularly clear, whereas I worked out how to use ProcessWire after about 20 minutes of reading the documentation. I converted the whole project to ProcessWire, and actually got the project functional. I had to write several custom modules and deal with a lot of hooks and set up CRON jobs to interact with a third party API, and I found ProcessWire a pleasure to work with. That said, I can understand that there are pain points for some people with ProcessWire, and it's always good to look at other systems to see how they do things in case there's something useful that could be incorporated into ProcessWire. My personal preference other than ProcessWire is Umbraco, which is built on ASP.Net rather than PHP, but in many respects is similar, so I don't have a problem jumping between PHP for ProcessWire and Razor syntax and C# for Umbraco. It also is an open source project, but with commercial add-ons like a form builder (which makes ProcessWire FormBuilder look cheap). Now that .Net and SQL Server run on Linux, it's potentially even more appealing to me, although ProcessWire is still my first choice. Currently I'm a solo developer, but as my workload grows, and also clients are starting to ask for an insurance policy in case something happens to me, the potential to be able to manage collaboration on projects is something that's increasingly on my mind, and out of the box, this isn't something that ProcessWire handles, although there are third party solutions like RockMigrations by@bernhard

It is possible to use pre-built themes with ProcessWire, but since you can't be sure in advance what fields someone will create, rather than building a ProcessWire specific theme, any well documented HTML theme should be easy to adapt to ProcessWire with not much effort. Mostly I think people build sites from scratch, but I did have someone once who wanted to use a theme, and had a limited budget, so it was actually quicker and cheaper to adapt an off-the-shelf HTML theme for them than build from scratch.

How about something like this? This way your editor can recognise the HTML tags as well as the PHP tags. The <?= ?> tag is a PHP shorthand for echo ... that you can insert within HTML. For PHP logic you need the full <?php ... ?> tag. You'll notice I've left a couple of echo statements in because they're short, and it's not really worth closing the PHP tag and opening another one for such short sections of HTML code. <div class="row mb-2"> <?php $items = $pages->find("homepage_item=1"); foreach($items as $item) { // $item === $pages->get($item->id); ?> <div class='col-md-6'> <div class='row g-0 border rounded overflow-hidden flex-md-row mb-4 shadow-sm h-md-250 position-relative'> <div class='col p-4 d-flex flex-column position-static'> <h3 class='mb-0'><?= $item->title?></h3> <?php if($item->arbitrary_publish_date) { echo "<div class='mb-1 text-muted'>$item->arbitrary_publish_date</div>"; } else { echo "<div class='mb-1 text-muted'></div>"; } ?> <p class='card-text mb-auto'><?= $item->summary ?></p> <a href='<?= $item->url ?>' class='stretched-link'>Continue reading</a> </div> <div class='col-auto d-none d-lg-block'> <svg class='bd-placeholder-img' width='200' height='250' xmlns='http://www.w3.org/2000/svg' role='img' aria-label='Placeholder: Thumbnail' preserveAspectRatio='xMidYMid slice' focusable='false'><title>Placeholder</title><rect width='100%' height='100%' fill='#55595c'/><text x='50%' y='50%' fill='#eceeef' dy='.3em'>Check it out!</text></svg> </div> </div> </div> <?php // echo $item->title; } ?> </div>

That's exactly how migrations files work with Entity Framework in .Net, but you've got to write that manually. I'm OK with that as it's not much to write. For new, changed, or deleted fields, it builds the migration automatically from the current definition of system state based on what's changed. That's exactly what I'd want. The main situation in ProcessWire where tracking data can be useful is with pages used as input for list items. I think I want both; a full description of system state that can be used to install a new instance of a given configuration, but also migrations so that an existing installation can be synchronised with a specific state. Maybe it's not the best approach, but that's similar to how Entity Framework on .Net works, and I work with that as well, so having a similar workflow to something I'm already using would keep things simple, but I understand there may be other solutions that are more efficient for other people. One of the key points for me as well, is I want to be able to do this at the module level, in addition to or instead of the site level.

Some people are wanting continuous upgrades to complete sites, but the kind of scenario I'm facing for the first time, is potentially identical, simultaneous upgrades required to multiple sites with different data, but on an extensible modular level. I've been thinking along the lines of having a method to build a full state, but whenever any objects in that state change, having some way to track what's changed since the last build. Building the full state looks to be relatively easy; specify what fields, templates, and pages are required, and in what order to satisfy dependencies, and then dump JSON files with definitions of all the objects required. Handling changes since the initial build in a reversible way is more of a challenge. I think if I did want reproducible upgrades to whole sites, that would be easily achievable by simply specifying the module dependencies in a configuration file, as they would encapsulate all the fields, templates, and pages required for a given site configuration, I'm moving towards the idea that everything other than the core would basically end up being a module, which in some cases may be responsible for nothing more than maintaining a set of fields templates, and possibly pages (eg for lists) for a specific task. Existing module dependency capabilities mean I can handle if a module depends on existing fields, as I can simply make it depend on the module that installs and maintains those fields. EG, module 1 installs a base set of fields, templates and pages. Module 2 requires some of the object data installed by module 1 but extends on that with additional functionality including its own fields, templates, and possibly pages. Module 3 also requires data from module 1 and extends on it in a different way. All sites will have module 1, but will have either module 2 or 3 but not both. I don't want or need to migrate an entire site, as that would get too messy if I start deploying a number of similar sites, but each with unique user data and sub-components. I still want to be able to use the UI though for rapid prototyping, and then build a deployment configuration once I've tested things out. Obviously changing things via the UI doesn't automatically add dependencies to a module, but that's fairly insignificant to achieve. Microsoft's Entity Framework Core specifically has an issue with this. It can generate automatic migrations with schema changes, but a renamed field or class results in a drop and create, rather than a rename, and their documentation recommends manually editing auto-generated migrations to deal with this. Obviously this problem isn't unique to ProcessWire by any means. ? The way things work there, is class definitions are complete, self-contained defintions of the schema, but separate migration files handle getting to that state if the current schema doesn't match the class definitions. Although .Net is a different platform, I wonder whether the way Entity Framework handles migrations could provide some insight into how to build a workable system for ProcessWire?

I posted over in this thread how to get a JSON definition of each required field, template, and page, using core functions, but that doesn't resolve knowing whether a change has been made. I wonder if it would be possible to store a hashed list of the state of objects at a particular build? A hash might be more useful than a timestamp in a collaborative environment, as what got modified rather than when it got modified is probably more relevant. It should be possible to iterate over the list of objects, compare hashes and build a migration file containing a list of those objects that have changed since the last build. This will not solve all scenarios, but could be a good start. Entity Framework in .Net Core from Microsoft does something like this, and the documentation specifically states that the migration file will need manual editing for some scenarios, specifically if a field has been renamed, as the migration will include code to drop the original field and create a new one, rather than code to rename the existing field, which would obviously result in data loss. If Microsoft can't figure out how to do fully automated migrations with all their resources, then it's obviously a significant challenge, however I like the idea of having automation to produce a migration file that is a starting point which in simple cases may be usable as is, but in more complex cases, at least reduces the amount of code that needs to be written manually.

The concept of RockMigrations makes a lot of sense, but what seemed to make it hard, was it depended on manually building object definitions for migrations in code. It turns out there are ProcessWire core methods to export field, template, and page definitions as JSON, so that makes it a lot less code to write. Where I'd like to get to is have a list of field, template, and page dependencies in a module configuration, and be able to do something like $module->build(); to generate JSON files for all those dependencies in the module directory. Modules already have install() , uninstall() and upgrade() methods so they could look for any object dependencies in the module config and create (or remove) them as required. Here's a working proof of concept I've been playing with in Tracy console. Although I prefer to use the UI when I can, due to the issues around dependencies between fields, templates, and pages, manually specifying an array with the objects in the order they need to be created avoids the issues others have run into of having to make multiple passes to satisfy all dependencies. I could make it smarter by checking the modified timestamp for templates and pages (and hopefully soon fields if Ryan adds it to the core), to only generate new JSON files for objects that have changed since the last build. $requiredObjects = array( 'competitionImage' => 'field', 'compGrade' => 'field', 'competition' => 'template', 'compId' => 'field', 'competitionCalendar' =>'template', 'competitiontopics' => 'page', 'media' => 'page', ); $modulePath = $config->path('MyModule'); $pageExporter = new PagesExportImport(); foreach($requiredObjects as $objectName => $objectType){ switch($objectType) { case 'field': $object = $fields->get($objectName); break; case 'template': $object = $templates->get($objectName); break; case 'page': $object = $pages->find("name={$objectName}, include=hidden"); break; } if($object){ $file = $modulePath . "data/{$objectType}s/". $objectName . '.json'; if($objectType != 'page'){ $data = wireEncodeJSON($object->getExportData(),true,true); }else{ $data = $pageExporter->exportJSON($object); } file_put_contents($file, $data); }else{ //Object doesn't exist! echo $objectName; } }

I've sometimes had this kind of issue when I intended to assign something to a variable to output later, and instead output it with an echo statement. Also HTML code in a template will immediately render instead of being assigned to a PHP variable if you don't use PHP output buffering. Check the source code of the output.

Tracy was useful in testing out what I'm trying to achieve. I'm trying to get away from copying and pasting though. I used the Tracy console, and this code is on the track of what I want: $modulePath = $config->path('MyModule'); //moduleFields is an array of field names foreach($moduleFields as $fieldname){ $testField = $fields->get($fieldname); $data = wireEncodeJSON($testField->getExportData(),true,true); $file = $modulePath . 'data/fields/'. $fieldname . '.json'; file_put_contents($file, $data); } This gives me a nice directory of field definitions that are required by a given module. ProcessWire already handles module dependencies including module versions with the requires property in getModuleInfo(), so if I define fields that are used in multiple places in a base module and specify that as a dependency of other modules that install other fields, then I can make sure I end up with all the fields that I need. Because I'm using a manually created array of field names, if there are fields that depend on other fields, I can list them in the right order to satisfy dependencies. Fields like page reference fields can depend on a template as well, so my array might need to specify both object name and type to install all the dependencies in the correct order, but I think I'm on track to being able to build a reproducible configuration I can easily deploy to multiple sites. I think it might not be too hard to build and admin module to provide a UI to build the dependency configuration files for custom modules either, as ProcessWire already supports adding and reordering items in lists in various Process modules. Edit: The reason I'm outputting one JSON file per object rather than just one big JSON file as the built in exporter gives you if you select multiple fields, is that I think it will be better for source version control, especially if a modified timestamp property is implemented for fields, and if there's a need for multiple collaborators on a project. Unmodified object definitions don't need to be regenerated. Additional Edit: Usually a module provides some kind of functionality, but there's no reason why a module can't just exist to install/uninstall a bunch of fields and templates, and otherwise just sit dormant. If it's not an autoload module, it's not going to do anything unless it's called from somewhere, and a module seems like a good way to encapsulate a whole lot of stuff. With the right design around dependencies and inheritance, it should be possible to change 'skins' or 'themes' for a site; something that's not possible with site profiles, as they're basically just a dump of a specific site state. eg, you could have baseModule that installs xyz fields and templates, then themeModule1 and themeModule2 that each provide different front end presentation, but depend on baseModule, so there can be certainty that all the fields they need exist.

I've found what seems to be an undocumented method of the Field class that's used by the built in field import/export that I think could be useful in automation. $field->getExportData() returns details of the object, but needs a little bit more work to turn into a JSON object, but builtin ProcessFieldExportImport shows how to do that. There's a corresponding $template->getExportData() method. I tried this: $testField = $fields->get('headerImage'); echo wireEncodeJSON($testField->getExportData(),true,true); and I got a nice JSON object with the field definition in return. I'm lazy, and forgetful, so I like using the admin UI to build my fields and templates, because it reminds me of all the properties of a field and what they do, right there on screen. Because I'm forgetful, where the UI gets a bit less useful is exporting fields, as I've got to try to remember which ones I changed. Adding a modified property and sorting by this as I previously suggested would help, but if I want to deploy the same configuration to a bunch of sites, manual export/import isn't really scalable. With this, I can potentially be lazy and forgetful, as I don't care how a field is made, I can simply grab it's definition and write to a JSON file, but I don't have to try to remember what fields are required for specific functionality as I can simply provide an array with a list of fields (and templates) required in a module, and let it generate them from the JSON files. I think what would be useful at the core level would be proper documentation for these import/export methods that already exist, and maybe a wrapper function so that it's possible to get directly as JSON data rather than requiring an extra step. eg $field->getJsonData() or something like that. I'm sure these JSON files could also provide field and template definitions for Bernhard's RockMigrations.

Templates have a modified property, but fields don't. This might be a useful and simple core feature to implement that could make it easier for anyone wanting to track changes. The Templates Export function shows the modified field, but it's sorted by template name. For quick manual exports, having the option to sort by modified timestamp would be an improvement. Once fields have a modified property, they also need to have the option to have the export function list them by modified timestamp. I see the base Wire class that everything else in the core extends has change tracking properties and methods, although currently there doesn't seem to be any built in method to enable persisting that with fields and templates when they're changed via the UI. Up to date, I haven't really required the sort of version control others are discussing, but I have a couple of sites now, where I'm looking at bundling up functionality as modules for automated deployment to other sites, and the manual exporting of fields and templates doesn't really cut it, but I've built my data structures via the UI, so having an efficient way to convert that to code that can be used for multiple deployments would be useful. With Visual Studio, I'm used to working with the option of using either visual designers or declarative code to build apps, and either way end up with code that can be included in version control.

The JSON that this feature generates for import/export mostly works for me, however the issue is having to manually select fields/templates via the UI. I notice that templates include a timestamp for when they were changed in the data field of the templates table, but fields don't. If both did, then it should be possible to get fields and templates that have changed since the last build time of a module or template. I use the admin UI, and don't want to write more code than I have to. Specifying what fields and templates that a module depends on in code and letting the system pull a config file with the definition of those fields and templates from the database would be UI friendly, but not rely on having to remember what fields or templates are required for a specific purpose, but not require much code either. This is similar to a database first workflow I have with SQL Server and ASP.Net Core. I can reverse engineer any tables I want from SQL Server to get a class definition, so I don't need to worry if the definition of something was manipulated outside my code; I can always grab the current definition without having to write any code. For those who have a licensed copy of Padloper 1, it's interesting to see how it creates the fields and templates it needs. It appears to be using JSON files based on the field and template import/export feature, but has its own code to import them. With a timestamp and possibly a version number added to the data in the fields and templates table, I wonder if that would make a hybrid UI/code based update model easier to work with? Of course for more complex migrations, RM is more capable, but I wonder if even there, it can grab the field and template definitions if they're exported as JSON?

This is potentially progress, as it suggests ProcessWire is at least being given control. ProcessWire throws an internal server error instead of displaying a message if something went wrong. Maybe check site/logs/errors.txt or exceptions.txt also, if you haven't already, in site/config.php add $config->debug = true; as that should display errors.

Does your Apache install have mod_rewrite enabled? If the home page is loading, but no other URLs are working, it sounds as though URLs are not being parsed. Also check permissions and ownership on directories and files. Directories should be 755, files 644.

Further to this, I've posted a feature request to Github, for a new method getColumns in WireDatabasePDO class, as this would enable: $database->getColumns($table) which would be helpful for getting a list of custom table fields and their types. there's already a getTables method and tableExists method, also a columnExists method, but currently no getColumns. I might be able to have a go at building a module myself to map custom table columns to inputfields, and of course I could write a method myself, but if other people are accessing custom tables, it would seem to make sense to have a getColumns method in the core. Copying the columnExists method, removing the WHERE condition and returning an array of the results rather than a boolean is probably all that's needed to implement a getColumns method.

I resolved the problem in a bit of an odd way. The 'deprectated' version of the module that I was using mostly worked, except links to site admin somehow ended up broken. Soma's module didn't work at all. I was able to patch together some bits from the newer module to ignore admin urls, and that got the older module working again fine on my site(s). It got it working for 3.0.184 but I can confirm it broke again with 3.0.189.

Is anyone else having issues with the @Soma version of this module (or the original for that matter) on the latest ProcessWire build? (3.0.189). I had a ProccessWire install that was working fine with the original module on 3.0.146, but on upgrading it broke. I've tried downgrading to 3.0.184 and upgraded to the more recent multisite module, but multisite still seems broken. The home URL works, and menu links for sub-pages are generated, but clicking on any of them returns the 404 page, and entering any domain other than the 'main' domain goes to the home page of the main domain.

If you're trying to duplicate a site, and don't have access to mySQL, then there are couple of modules that may be helpful. https://processwire.com/modules/process-database-backups/ This one can be helpful if you have an existing ProcessWire installation that's working, but need to restore data from a backup. https://processwire.com/modules/process-export-profile/ This one is useful if you're starting a completely new install of ProcessWire and you want to recreate an existing site structure during the install process. This will include templates, site modules, and page structure. You need to copy the exported profile to the new site profiles directory before you install, so that it allows you to select the profile during the install process. This will recreate the database structure. You will need to be able to set up a blank mySQL (or MariaDB) database and assign a database user with full access to it. There are other migration modules if you have a development site and a live site, and you only want to transfer changes.