Jump to content

LuisM

Members
  • Posts

    46
  • Joined

  • Last visited

Everything posted by LuisM

  1. Bump up to v0.6.0 Breaking Changes renamed AbstractRepository to AbstractPagesRepository added new ProcessWireService / ProcessWireServiceInterface as wrapper to access ProcessWire in a centralized way and to reduce wire() function calls. replaced all wire() function calls with using ProcessWireService
  2. Bump up to v0.5.0 I added a tutorial for a simple Symprowire Blog Application. You can find the tutorial here: https://github.com/Luis85/symprowire/wiki/Symprowire-Blog-Tutorial To keep up with development and organize the project I added a GitHub Project and corresponding Issue Management. You can find it here: https://github.com/Luis85/symprowire/projects/1
  3. Thank you Teppo for that detailed answer. Really appriciate it. My first take was similiar to Wireframe. Adding a Template as alternate Template file and replace the render accordingly. But it didnt felt quite right, taking the tools Symfony provides into consideration. I now let Symprowire act as a drop-in solution to replace ProcessWire rendering completly. What this basically means is, ProcessWire will no longer be in charge about anything URL or rendering related. As of now Symprowire will intercept the Request and manage routing decoupled from ProcessWire. So ProcessWire will step back and act as a Data/Service Provider for Symprowire. What I actually did here is separating into more or less 3 layers. ProcessWire as Data and Server Provider Symprowire as Businesslogic Backend MVC style powered by a Symfony Architecture a separated Frontendlayer served by Twig Templates ProcessWire Admin will be used as Data Editor / Content Management System and Symprowire will consume this data and do stuff with it before handing over to Twig.this This would describe it best I guess. I actually use Wireframe as Output Framework in the Project im working on πŸ™‚ I am still not sure if this should be a possibility or an option in Symprowire. Its tempting to let the Developer decide, but on the other hand I mainly create Symprowire to give a somewhat strict structure and to have Phpunit tests in the not so far future. Which would be hard to integrate if just parts could be tested. Decisions decision decision... πŸ˜• Another reason I am into this is the clear and concise way Symfony handles the Request/Response, it just makes so much sense for me to combine this both worlds. Take the very very strong parts CMS/CMF wise from ProcessWire and combine it with Symfony. I dunno πŸ™‚ just feels to be like this Dont worry, I knew you would give great insights the moment I tagged you πŸ˜„ Have to dig into TemplateEngineFacotry code now πŸ˜‰
  4. Working Full-Time on the Module for this week after getting it running its just good old Symfony Development to make the Glue hold tight on ProcessWire. I plan to build a Blog with Symprowire next to see if everything works as expected. I added a small Project over at Github to keep you informed. Will continue to post release notes. For now, I edited the 1st Post as this would be my Base to develop the Blog.
  5. Release v0.3.0-rc1 - added Webpack Encore Support - removed Symprowire Autload condition. Symprowire is now configured to server every request except admin - implemented recommended template structure into lib/twig - added more context and information to the HomeController - added $user and $session as Global Twig Variable // both as ProcessWire Objects - implemented example Webpack Encore Application using stimulus.js served by lib/twig
  6. Oh hahaha, my question is more about, what would be the best method/hook to intercept ProcessWire rendering or routing to replace the Response completly.
  7. Looking forward to your experience @netcarver πŸ™‚ What I actually dont like at all right now is how I hand over the Request handling. My idea is, to use ProcessWire as a DBAL and load Pages via a Repository to centralize modification, loading of PageData and use the Admin to create a Structure, Content and handle Templates and let Symprowire use Entities as simple DTO to reflect ProcessWire Templates. I think this will open up a clear Migrations path later on and will make Form creation easy with the symfony/forms component. Right now I add a replace hook on TemplateFile render() and the used frontcontroller template will allow UrlSegments to be set. I must admit, Routing is not something I have invested much tought into yet. Maybe you guys have some ideas what could work best here @teppo @bernhard @netcarver
  8. Release RC1 v0.2.0 -> https://github.com/Luis85/symprowire/releases/tag/v0.2.0-rc-1 added Session Handshake to integrate PW Session into Symfony added $page, $pages, $input, $session, $modules, $users as member to AbstractController added Symprowire autowire Services outside of userland into /lib/src and added own Namespace for the lib added Repositories (Pages, Modules, User) to the lib added UserRepository to HomeController::index() as Dependency Injection for Demonstration / as Example
  9. I just finished to clean up the repo and pushed Symprowire as stand-alone module to GIT. I marked the commit as RC-1 The Framework should work right now like every other Symfony App handling wise, with the exception of twig templates bound to the processwire directory structure. Next would be to integrate ProcessWire Services like logger, input et all as Symfony Services and autowire them into the Controller. Stay tuned, oh and feel free to comment πŸ™‚
  10. @netcarver oh wow thanks for the Larawire mention. Didnt knew there where similar attempts but with Laravel. Anyways, I have a slow day in the office and wanted to clean up a bit. So meet PoC v.0.1.0. I completly encapsulated Symfony now to dont mess with ProcessWires file/directory structure and keep things clean. I think, this should be a good base to develop this thing further. Am happy πŸ™‚
  11. Symprowire is a PHP MVC Framework based and built on Symfony using ProcessWire 3.x as DBAL and Service-Provider It acts as a Drop-In Replacement Module to handle the Request/Response outside the ProcessWire Admin. Even tough Symfony or any other mature MVC Framework could be intimidating at first, Symprowire tries to abstract Configuration and Symfony Internals away as much as possible to give you a quick start and lift the heavy work for you. The main Goal is to give an easy path to follow an MVC Approach during development with ProcessWire and open up the available eco-system. You can find the GitHub Repo and more Information here: https://github.com/Luis85/symprowire Documentation The Symprowire Wiki https://github.com/Luis85/symprowire/wiki How to create a simple Blog with Symprowire https://github.com/Luis85/symprowire/wiki/Symprowire-Blog-Tutorial Last Update 16.07.2021 // RC 1 v0.6.0 centralized ProcessWire access trough out the Application by wrapping to a Service https://github.com/Luis85/symprowire/releases/tag/v0.6.0-rc-1 Requirements PHP ^7.4 Fresh ProcessWire ^3.0.181 with a Blank Profile Composer 2 (v1 should work, not recommended) The usual Symfony Requirements Features Twig Dependency Injection Monolog for Symprowire Support for .env YAML Configuration Symfony Console and Console Commands Symfony Webprofiler Full ProcessWire access inside your Controller and Services Webpack Encore support Caveats Symfony is no small Framework and will come with a price in terms of Memory Usage and added Overhead. To give you a taste I installed Tracy Debugger alongside to compare ProcessWire profiling with the included Symfony Webprofiler So in a fresh install Symprowire would atleast add another 2MB of Memory usage and around 40ms in response time, should be less in production due to the added overhead of the Webprofiler in dev env
  12. I had your workflow in mind when creating the Module πŸ™‚ But needed a baseline to get it going. I will update the Product Requirements, just hadnt tought enough yet how to merge the different approaches. My inital thought was to let the user define Modules he want to manage with the module, build an array of Modules and Folders according to the user configuration and scan affected folders. Which will result in a structure like /site/migrations /site/modules/XYZ/migrations On a sidenote, I also want to add Template and Field changes done via the ProcessWire Backend under Migration Control just to support a easy "click-and-collect" Workflow. For example you are building some Templates via UI to test things out on your local machine, Migrations will be added automagically and after a Push to your GitRepo you will have your executable Migrations in place.
  13. Bernhard, thanks for your detailed and well tought answer, really appreciate it. I definitly see where you are coming from. We are working both on very different topics, you are working on a multitude of projects and you need to keep track of your modules and the various different combinations and connections between them. I am glad I dont have to deal with this πŸ˜„ My usecase is a bit different as I am working on a single Installation with a well defined set of Modules and the same functions for every single user/customer. Your approach to deal with Migrations on a Module Base makes sense, yes. Thing is, I really dont like to mix Business Logic, Domain specific Logic and Application Logic hence my file based approach to solve my first need. My second need would be to put Modules under Migrations Control like you do. My primary thought was to create a /site/migrations/ folder and let the User decide which Module he wants to set under Migrations Control and act accordingly. So moving the Module bound migrations folder into the site scope. I dunno yet πŸ™‚ but I will definitly support a usecase as you have in the future, just because I would need that feature, too πŸ™‚ Regarding the granularity of Migrations, yes, it could end in a mess. My reasoning to seperate the different types of Migrations is to force the developer to atleast think about execution order and implications in his database change. You are forced to discipline yourself so to say, to avoid a mess πŸ˜„ #me #myself and #i
  14. Pushed to Master renamed FlowtiMigration::createMigrationFile() to ::createMigrationBoilerplateFile() renamed FlowtiMigrationService::addDefaultMigrationValues() to ::addMigrationValues() Moved default Value creation in his own function, added default values array with all options cleanup You cann now define your defaults/globals for all Templates and Fields. To set a default Value just remove '//' for your particular option inside the src/FlowtiMigrationService class. I pushed my current default values, so please change them as you need them πŸ™‚
  15. thanks for the warm words webmanufakturer @wbmnfktr. I am happy to walk you trough the concepts of migrations if you want. The most complexity should be abstracted away with RockMigrations and a companion. As a note regarding my module, the FlowtiMigrationsService class has a function called addDefaultValues, I use this method to keep my migrations a lil bit lighter. Unfortunatly, I have to maintain 2 Versions of the module right now. The public version and our internal module. Therefore I forgot to empty the defaultValues Function. I try to push a cleaned up Version later today with a configurable AddDefaults method.
  16. A companion Module for RockMigrations to gather and execute Migrations in one place. !Alpha RELEASE! Hi there, I just wanted to share my take on Migrations and how I am using RockMigrations to make my deployments somehow manageable. First of all, a big shoutout to @bernhard for his efforts and accomplishments for our beloved CMS. We recently had a video-call and talked about our daily problems and how to handle them, with a focus on Migrations. As of now you might think 'Gosh, not another Migrationsthingy' but wait. Wouldnt it be nice to have a nice overview or some kind of list regarding Migrations and stuff and one place to manage them? Speaking for my own, yes I would like to have something like this. So yeah, here we are with a Companion Module for RockMigrations. Product Requirements I want to manage Migrations on the Application level (done) I want to have one place in my FileSystem to place my Migrations (done) I want to see in which state my Migrations are (done) I want to have an execution order, execute migrations one by one (done) I want to trigger Migrations via CLI (open) I want to group multiple Migrations into One Migration to create Build Versions (open) I want to Rollback Migrations (open) I want to create a deliverable build out of migrations (open) I want to track changes to templates and fields and create migrations accordingly (open) I want to manage Migrations on the Module level (open) Module Requirements ProcessWire 3.0.178 RockMigrations latest PHP 7.4 Composer Current release: v1.0.2Alpha How does it work? On installation the Module will create a new Database Table, here we will hold information about migrations states. Your Migrations are empty on first installation, so just click on You can now choose which Type of Migration you want to create, be it Templates, Fields or Pages and a according Action. Im still working on this function, so yeah its a lil bit confusing right now. The philosophy here is, every Type of Migration could be easily identified and we can Migrate on a very sepcific and granular base. As you can see in my Screenshot, I am using migrations to build an entire App from Migrations. After creating the new Migration File, switch over to your IDE and find a timestamped .php file inside modules/FlowtiCore/migrations. This file just returns a simple Array. This is all the Info RockMigrations needs to do his thing while we keep track of the execution. Easy. Values Arrays have to follow PW and RockMigration field naming Conventions. To make a Migration Executable set 'boilerplate' to false. After creation of your first Migrations your overview should be filled so lets go. We have to migrate our files in a specific order just to make sure we can create page_references and Parent/Child connections. To achieve this, Migrations are timestamped on creation. The older the higher the priority. To enforce execution order, every migration needs to have his predecessor executed and installed. How could this help my workflow? My workflow is based on Git, Webhooks and Git Events. So whenever I merge 'staging' into 'master', a build will be created and a deliverable should be pushed to a Server via SSH. The Problem with ProcessWire is the lack of support for such Workflows and Toolchains due to its User-Friendly Admin Backend which is fine for a simple website but not suitable long-term if working in a multi-tenant environment or with more developers in a dev-staging-test-production setup. My Goal is to provide methods and ideas to support such workflows but also support a User-Friendly Interface to work with migrations. I really hope it could be of use for someone. Installation I will add the Module to the Directoy once it reached a stable state. But you can get current version at GitHub https://github.com/Luis85/FlowtiCore Just clone it to your Modules Directory. The Module will create a new Database-Table on creation. The Default Name will be 'flowti_core_migrations'. To change this just edit const DATABASE_TABLE = 'flowti_core_migrations'; Inside the Module Class. Thats it, from there on just create new Migration Files, edit them and execute them.
  17. Thanks Teppo, helped me already a lot. I think I should dive deep into your framework and have a look at your solutions/implementations πŸ™‚ Bundling my dependcies into the repo is not an option πŸ™‚ What I want to achieve proper dependency management on a Module base dependency management of the whole project including modules A proper way to build and publish modules / profiles for easy consumption The third part would be the hardest part I guess. I started to work on a module, based on deployphp/deployer to somehow have the possibility to get a proper Build Pipeline from local -> dev -> staging -> prod Another thing I did, was to integrate vlucas/phpdotenv to handle different Environments based on, you guessed it, the particular environment. But first things first, Dependency Management. I played around to split my codebase into git submodules, which will give me a new lot of problems to manage them in the long term, but it seems to be the way to go. The root cause for all of this, is my usage of ProcessWire as a backend for a multi-tenant system with a plethora of problems on its own, which I will write some stuff about in the future. And on a sidenote, I dream to composer require ProcessWire and just use it as a Frontend Service.
  18. A serializer module for ProcessWire Pages. This module will add a new method to all pages, called serializer(), which returns JSON. https://github.com/Luis85/FlowtiPageSerializer ## Dependecies symfony/serializer symfony/property-access ## Requirements ProcessWire 3.x Composer ## Installation cd site/modules git clone git@github.com:Luis85/FlowtiPageSerializer.git cd FlowtiPageSerializer composer install ## Usage $page->serialize() will return the serialized Page Object as a JSON string representation containing all accessable fields calling $page->serialize('field_name') returns the Page Object with just this field $page->serialize(['field1', 'field2']) will return the choosen fields This is my initial commit, just cobbled together a wrapper around the symfony/serializer component which i plan to use for data serialization and deserialization. The module can just serialize a given page and limit its output a field string or an array of strings. Supports only json output right now. Supports only 1 dimension of data, so no reference titles / .dot syntax. Can someone please enlighten me how to setup a proper composer setup for PW Module Development btw?
  19. Hi @Peter Falkenberg Brown sounds like you should have a look at this: https://processwire.com/blog/posts/multi-instance-pw3/ and hook into your Pages::saveReady method on Site1 to move your partials to Site2. What comes to mind when trying to copy your files/images via CLI is the mentioned problem with IDs. I think you should avoid manually moving the files and let do PW the handling. Im in a hurry right now. But what about a "copyPage" function inside the hook, which calls your 2nd PW Instance and creates the new Page in Instance2 with the Values of Instance1?
  20. you should have a look at the /site/config.php and set the Database Credentials accordingly.
  21. Well to quote Mr. Wilde I would second this. On my Job I had to venture in the Lumen/Laravel ecosystem a bit and really liked the Migrations approach they take. (https://laravel.com/docs/7.x/migrations) I really missed a proper migration integration when I started some new PW projects in the past. @LostKobrakai's approach was therefor my way to go. But ProcessWire is evolving and the lack of support he could give is a strong driver to switch.
  22. @LostKobrakai @bernhard sorry for the Off-Topic here, as I know both of your modules and follow both of your ProcessWire work for quite some time now. Would you mind to elaborate a bit on why you are not using PW anymore and what you have choosen instead?
  23. <div class="row"> <?php foreach($pages->find("template=spiel") as $spiel) : ?> <ul> <?php foreach($spiel as $field => $value) : ?> <li><?= $field ?> <?= $value ?></li> <?php endforeach ?> </ul> <?php endforeach ?> </div> Will output all the template fields in a <ul> for each Page. The caveat is, it will also output system fields. To get only your "custom" fields you could iterate the pages fieldgroup like this <div class="row"> <?php foreach($pages->find('template=spiel') as $spiel) : ?> <ul> <?php foreach($spiel->fieldgroup as $field => $value) : ?> <li><?= $field ?> <?= $value ?></li> <?php endforeach ?> </ul> <?php endforeach ?> </div> Which should output the corresponding Field with Value. To make the code a bit more readable I usually use the <?= $var ?> shorthand for <?php echo $var ?>. Some may like this Syntax, some does not.
  24. @teppo thanks for the mention in the last Weekly, much appreciated πŸ™‚ I recently pushed a new Version to Github and changed the MarkupTables with DataTables. I am well aware that the module isnt that polished someone might expect. I more or less hacked it together to fullfill some very specific needs I had. But, I plan to work on it from time to time. One thing which came to my mind was to integrate the recently published LogStash Module. Im always open for suggestions πŸ™‚
  25. And the next piece of information... Have you ever asked yourself on mondays, what should I do now with my project? Could I start with $method1 or would I like to do $method2? The right answer is, none of them! PLAN YOUR TIME AND TASKS! So far we have learned about basic conceptional work, estimation matrix and components/sub-components. The next logical step would be to use this knowledge and start to manage ourself. Lets say we have 183 Tasks as a result from all our work we have done upfront. Great. We also know how long each and every task would possible take. Better. We can now use a method called TimeBoxing. If you are familiar with Scrum you probably know about sprints. Which is nothing else than a timebox. I dont want to dig deep into the Scrum Framework. So lets take this method and use it for ourself. The typical dev timebox in my teams runs for 2 Weeks. So on mondays we plan what we want to achieve in the next 2 weeks. How can I timebox myself? Lets assume you work 40h a week, for a 2-week timebox we have 80h pure worktime. Typically you dont work 8h straight on your tasks. Maybe your phone rings, you have to answer some emails or you help a colleague. We assume a "task efficency" of 80%. So 80% of our time could be put straight into tasks. Which means 80h * 0.8eff = 64h of effective Worktime for our project in a 2-week timebox. Lets have a look at our tasks now. There are 183 Tasks in our "Backlog". Wow thats a lot. Lets start to prioritize them. What is essential for our project and so on. Once done, great. But there are still 183 Tasks?! You remember our estimation we did? Create a new Backlog for the next 2 Weeks. This could be a Excel file or what ever. Take all your prioritized tasks which fit into your 64h. Congratulations you have now planned your very first timebox. Your timebox should now include so much work to keep you busy for the next 2 Weeks. The core concept of project management is to break complex systems into smaller much more easier and understandable fragments. Therefor, see yourself as a project which has to be managed πŸ™‚ An example Project Backlog and Timebox Backlog down below. Left is the timebox, right is the project
Γ—
Γ—
  • Create New...