Jump to content

Kiwi Chris

Members
  • Posts

    246
  • Joined

  • Last visited

  • Days Won

    4

Kiwi Chris last won the day on April 11 2022

Kiwi Chris had the most liked content!

Profile Information

  • Location
    New Zealand

Recent Profile Visitors

2,675 profile views

Kiwi Chris's Achievements

Sr. Member

Sr. Member (5/6)

371

Reputation

  1. I didn't have anything in the migrate file to install the module, but I did have code to create a lot of fields and templates and create some pages which all got created. I wanted these to be under the control of migrations, but assumed (incorrectly) migrations would only run on installed modules, ie once the module is installed I do want the migrations file watched and run if there are any changes, but if the module isn't yet installed it doesn't make sense to run its migrations. An easy way to get it to work the way I want is to do a conditional check at the start of the migrations file to see if the module is installed or not, and only run the actual migration code to create fields and templates if the module is installed. That way I won't get a bunch of fields and templates installed for an inactive module.
  2. I'm not sure whether it's intentional or not, but I started experimenting with deploying a site setup to a clean, blank copy of ProcessWire with RockMigrations I dumped a copy of RockMigrations and a custom module with a migration file in the format MyModule/MyModule.migrate.php I installed RockMigrations via the admin UI, and was wondering why it was taking so long. Afterwards I checked, and found it had gone ahead and installed all the modules, fields, files, and created pages in the custom module's migrate file, even though the module itself was not yet installed. I'm not sure whether that's intended behaviour? If it is, I need to make sure I don't upload a module with a migrate file unless I want the migration to run as soon as I upload it. My assumption was that RockMigrations would start watching and running migrations in a module's directory once the module is installed, but possibly I assumed wrong. Apart from being surprised that the module's migration file ran before the module was installed, it was very nice to see a whole app with multiple fields, templates, modules, and pages constructed before my eyes, and it's way more modular than exporting site profiles, since I can build a base functionality in one migration file and then add components in others.
  3. Something like this could work. There are two possible scenarios I can think of. A site profile migration or a module migration. In either case, it's still necessary to be able to manually specify the order of the fields and templates because of possible dependency issues, but it should be possible to generate the field and template definitions (for those who want to, rather than coding them).
  4. That's a significant issue, and I tend to think it's better to have migrations generated manually rather than fully automated, but I think possibly more automation is possible. Here's my first ever migrations file, that works nicely for me. //Modules $rm->installModule( "FieldtypeLeafletMapMarker", "https://github.com/madebymats/FieldtypeLeafletMapMarker/archive/PW3.zip" ); //Fields include __DIR__ . '/fields/fields.php'; //Templates include __DIR__ . '/templates/Discipline.php'; include __DIR__ . '/templates/Member.php'; include __DIR__ . '/templates/Show.php'; include __DIR__ . '/templates/ProductionRole.php'; //Web Templates //include __DIR__ . '/templates/contact.php'; include __DIR__ . '/templates/ProductionRole.php'; include __DIR__ . '/templates/location.php'; include __DIR__ . '/templates/pastShows.php'; $rm->createPage('Website', 'website', 'basic-page', 'home'); $website = $this->wire->pages->get('name=website'); $rm->createPage('Past Shows', 'past-shows', 'pastShows', $website); $rm->createPage('About Us', 'about-us', 'basic-page', $website); $rm->createPage('Contact', 'contact', 'location', $website); In each of those template definitions, I have: $rm->createTemplate('...'); $rm->setTemplateData( ... ); I did combine the field definitions into one file, but I could have done them individually. I still have full manual control over the order of migrations, but my migrations file itself is pretty small, and each template definition file is self-contained, and I think it makes the code cleaner. It's not as efficient maybe as running $rm->migrate with all the templates in one big array but it works, and I can control the order. It made me think, if I'm using this sort of structure, then the getCode method of RockMigrations, instead of being used just to display the code on screen, could build the definition files for me. A way to have some manual control if definitions are combined in a file would be to have some sort of Migrations build file for a module, which specifies the fields and templates in the order that they need to be processed. In my module migrations file, I've specified the order manually, but I've kept the definitions separate. The way I'm using this is in association with modules, so I wonder whether the way to do it is to hook into the module UI, check whether the module has a migrations build file, and if it does, offer a button to generate the module migration based on the specification in the build file?
  5. This is perfect. I've thought of an enhancement to RockMigrations that would be useful because I'm lazy. In the showCopyCode method, instead of copying and pasting, an additional option would be an 'export' button, and a path field. I'd still need to write a migration file, as the order of field and template migrations is important, but if I simply list the fields and templates as includes in order, then it would make the migration file more concise, and I could still trigger a migration by updating version details of file, but without having to keep copying and pasting into a file. eg, if I want the definition for myTextField to be associated with ProcessHelloWorldModule, then I could set a path site/modules/ProcessHelloWorldModule/fields/ and dump the definition there by button click. I've been having a play and here's a mockup although it doesn't do anything yet. I'm not sure whether it actually needs its own save button, or whether to hook into saving the field and save the RockMigrations code to the path specified. I've never worked with modifying field/template editing before, so I'm not sure how to persist the save path. Of course I can do this manually, by copying and pasting each field and template definition into its own file but I think this might be a time saver for people who like to use the UI, but also want to use migrations.
  6. A quick question before I go ahead and set up migrations files: I like using the ProcessWire UI to edit my field and template properties, and RockMigrations gives me all the code to copy and paste into a migrations file, so this is nice and easy, but I want to make sure on my development instance that I don't accidentally overwrite field or template definitions by triggering a migration when I've yet to copy and paste updates from those fields into the migrations file. I do want the migrations to run automatically on the deployed site I think though, as the migrations file(s) will only get updated on the deployed site when they're ready to run. I think I'd prefer to include the migrations in page classes, as that keeps all the definitions of an object in one place and nice and modular, just I don't want to accidentally trigger these on my local development environment before I have all the fields and templates modified with any changes I've done via the UI. What's the best way to handle this scenario?
  7. ProcessWire does and doesn't do this. You initially have to edit your HTML templates to define the structure of pages on your website, but after this, all the editing of the content can be done either on the front-end or back-end without having to edit HTML directly. Most other CMSs do the same, just some come with a lot of predefined themes to get you up and going where someone else has created the HTML templates. Both the strength and weakness of ProcessWire is that it doesn't come with a lot of predefined themes. That's because ProcessWire doesn't try to decide for you how your site should be structured, and third-party themes for other CMSs typically depend on the CMS having a specific structure to data. That might seem like a good idea, until the moment you try to do something that doesn't fit the assumptions the CMS has made about how data should be structured, then it turns into a nightmare to try to make it do something different. ProcessWire makes virtually no assumptions about your data, which is why it requires some knowledge of HTML to make templates to start with, but it's much easier to change than other CMSs, and once you've got your HTML templates, it's very easy to edit content without needing to know anything about HTML, and is arguably more intuitive for editing content than some other CMSs that involve some clunky and inconsistent plugins and add-ons to do anything beyond the basics. I guess you could use the analogy, ProcessWire is a box of Lego bricks. You've got to do some construction, limited only by your imagination. Other CMSs are like a ready made toy. If it's the toy you want, then they're quicker and easier, but if you got a toy car, and really wanted a helicopter, then trying to change it is going to be hard. With ProcessWire it can be a car or a helicopter, but you've got to build it.
  8. I think this could work both ways. One of the things I really like is that it's possible to use the admin UI to design your fields and pages, but RockMigrations then gives you the code generated to copy and paste into your migrations file. If you start prototyping using the UI, and intended to add it to a migration but forgot to, having an indication that a field or template isn't included in a migration is just as useful as indicating that it is. This would be particularly useful when adding RockMigrations to an existing site, as it makes it easier to see quickly what has been see up to be managed by migrations and what hasn't been.
  9. Something like? $database->exec('ALTER TABLE pages AUTO_INCREMENT = 1');
  10. This looks great. I'd been considering building something similar myself as I have a need for it. I do have a need for it to integrate with an existing site, but from the looks of the latest Rock Migrations, there's an easy way to get the configuration of fields and templates to paste them into a migrations file, and that's something else I've been meaning to have a play with, so I might set up a local version of this profile, install Rock Migrations, and see if I can build a migration that allows me to apply this to an existing site.
  11. @kixe Your fork of the module doesn't allow issue reports on Github, so I'll mention it here. There is a hook into AdminRestrictBranch module if present to automatically restrict the page tree to the root of the domain in multisite mode. if ($this->wire('modules')->isInstalled('AdminRestrictBranch')) { if (method_exists('AdminRestrictBranch', '___getBranchRootParentId')) { $this->addHookAfter('AdminRestrictBranch::getBranchRootParentId', function ($e) { $e->return = $this->rootPageID; }); } else $this->warning('AdminRestrictBranch::getBranchRootParentId() is not hookable'); } Where this has an issue is that if a user is only supposed to have access to page tree belonging to domain A as defined in AdminRestrictBranch, and then logs in to domain B, the branch restriction defined in their user profile or role is overridden by the hook in multisite. This means if any user knows other domains under the same installation of ProcessWire using Multisite, they can log in and access the page tree of those domains, even if AdminRestrictBranch is configured to otherwise prevent them from accessing them. A quick fix is to comment out the hook code. A better fix would be to check whether a user or role already has branch restrictions in place defined by AdminRestrictBranch, and if so, defer to those restrictions, but if not, provide default behaviour as exists of restricting to the root of the domain.
  12. Oops! Sorry @adrian I just realised I got my module mentions back to front. I'm using your 'official' version of AdminRestrictBranch, and the Multisite version by @kixe There does seem to be some interaction going on between them that's causing unexpected results. It's not necessarily a fault with AdminRestrictBranch, it looks like an issue with Multisite module as it hooks AdminRestrictBranch::getBranchRootParentId , but it's still worth mentioning here in case someone else runs into the same problem, so that they're aware of potential issues using the two modules together. I found an easy fix was just to comment out the hook code in the Multisite Module.
  13. 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.
  14. 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?
  15. 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.
Γ—
Γ—
  • Create New...