Jump to content

Kiwi Chris

Members
  • Posts

    225
  • Joined

  • Last visited

  • Days Won

    4

Kiwi Chris last won the day on April 11

Kiwi Chris had the most liked content!

Profile Information

  • Location
    New Zealand

Recent Profile Visitors

2,342 profile views

Kiwi Chris's Achievements

Sr. Member

Sr. Member (5/6)

341

Reputation

  1. 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
  2. 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.
  3. 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>
  4. 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.
  5. 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?
  6. 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.
  7. 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; } }
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...