Leaderboard

A little I wrote about template rendering in ProcessWire. https://www.spiria.com/en/blog/web-development/tutorial-processwire-style-rendering-strategy/ Comments are welcome.

v0.0.14 is now available This is quite a significant enhancement in hookability so that now (for example) scripts can be run automatically after installing a migration. See the help file for full details. Brief outline is below. Available hooks Many of the ProcessDbMigrate methods are hookable: ___execute() – Display the Database Migrations setup page ___executeNewPage() – Create new migration ___executeGetMigrations() – refreshes all migration pages ___exportData($migrationPage) – creates the .json files for a migration ___removeFiles($migrationPage) – removes the .json files for a migration ___installMigration($migrationPage) – installs a migration in the target ___uninstallMigration ($migrationPage) - uninstalls a migration in the target ___lockMigration($migrationPage, $migrationFolder) – locks a migration (in the source) ___unlockMigration($migrationPage, $migrationFolder) – unlocks a migration (in the source) ___previewDiffs($migrationPage, $comparisonType) – previews migration changes where $comparisonType is one of: export, install, uninstall, review Placement You can place your hooks in site/ready.php. In this case you will need to check the name of the migration page before running – e.g. wire()->addHookAfter('ProcessDbMigrate::installMigration', function ($event) { $migrationPage = $event->arguments(0); if ($migrationPage->name == 'my-migration') { ///code to run } }); and then you use $migrationPage to further reference the migration page. This approach keeps all your hooks together and you have to remember to sync the site/ready.php as well as your migration files. Alternatively (the recommended approach), you can place a file called ready.php in the site/template/DbMigrate/migrations/my-migration/ directory, in which case your script would be $this->addHookAfter('ProcessDbMigrate::installMigration', function ($event) { // code to run }); and you can use $this to reference the migration page. This approach keeps all your migration-related data & code together and you only have to sync the migration folder. It also means that your migration-specific ready.php code will be displayed at the bottom of the migration page. Also, if you ‘remove migration files’ it will remove your custom code as well (usually you will only be doing this as preparation to delete the migration, so that is what you want). With the first approach, your hook will remain in site/ready.php. Usage Of the available hooks, installMigration and uninstallMigration are likely to be the most useful. For example, a hook after ProcessDbMigrate::installMigration could be used to carry out database-wide changes following the amendment of the structure. Say you have changed an address field to split out the post code into a separate field. The migration definition will specify the new field and the changed template. The hook (after ProcessDbMigrate::installMigration) will then include the code to extract postcodes and place them in the new field. You could place code to undo this as a hook before ProcessDbMigrate::uninstallMigration, so that executing the uninstall exactly reverses the install. --------------- UPDATING - NOTE If you are updating the module (as opposed to installing for the first time), after a 'modules refresh' you will need to go to the bootstrap migration page and install it in order to pick up the new field which displays the migration-specific ready.php file.

Announcing the current status, planned release, roadmap and preview of Padloper 2. Status Feature freeze. Full multilingual support. Only PHP 7.2+ supported. Support for ProcessWire 3.0 only. Backend support for modern browsers only (that support JavaScript ES6 modules). Current Work Finish work on admin/backend. Work on installer and uninstaller (including configurable availability of some features). Work on UI/UX improvements. Start work on documentation with special focus on technical documentation. Continue work on Padloper API and data/model component. Roadmap Please note that these ARE NOT hard and fast targets. The roadmap may have to be adjusted to accommodate technical and non-technical constraints. Q1 2021 Inbuilt support for (latest) PayPal (full rewrite, no external modules required). Additional work on Padloper API. Invite a limited number of early alpha testers (fully-priced product). Soft and closed release of Padloper 2. Q2 2021 Start work on relaunch of Padloper website. Inbuilt support for Stripe (no external modules required). Future Plans Support for more Payment Gateways. Support for order, customers, etc imports and exports. Support for AdminThemeReno and AdminThemeDefault. Separate fully-featured frontend shop module. Consider support for multiple currencies. FAQ 1. Have you abandoned this project? No. 2. When will Padloper 2 be released? First early alpha release is scheduled for Q1 2021. This target may change depending on circumstances! Access will be by invite only for this first release. 3. What is the pricing model of Padloper 2? Three licences: Single Site, Developer and Agency licences (12 months’ updates and VIP support). 4. How much will Padloper 2 Cost? No price has been set yet. It will cost more than Padloper 1. 5. Can we upgrade from Padloper 1? No. 6. Will existing users of Padloper 1 get a discount for Padloper 2? No, this will not be possible. Apologies for the earlier announcement. It was unrealistic and unworkable. 7. Can we pay for Padloper 2 in advance? No. 8. Does Padloper 2 render markup/templates in the frontend? No. Access to all data you need to build your shop’s frontend is via the Padloper API. 9. Can we keep sending you ‘Are we there yet’ messages? No, please. Preview Here is a video preview of the current state of the backend/admin of Padloper 2. Please note the following: This is early alpha. There are bugs! It even includes WIP/notes!! FOUC, misaligned things, etc. The video shows the near-raw implementation of Vuetify UI. The UI/UX improvements work is yet to start. What you see here is the development version. Some of the incomplete features may not be available in the early releases. Most of the features you see will be optional to install.

I have been using exactly that workflow for a long time now, with total success in medium to complex projects. Additionally I add components and partials using wireRenderFile or wireIncludeFile and that's all I have needed. It's important to note that all my projects are one man projects.

Just to be sure - maybe it's not a PW Issue. Did you check the E-Mail Headers?

Many thanks Horst, confirmed my thinking. After happily and messily playing around, a tiny voice deep in my memory whispered "sandbox" ...sheesh. Been a while since I played around with sandboxed iframes, but the little voice from the past was right. Simple addition of sandbox to the iframe automatically prevents get/set of cookies. So I could get it doing what I wanted by adding: <iframe sandbox="allow-same-origin" src="..."> Apologies for not remembering sooner, I will be busily head-desking over in the corner now ?

You need to request the page with a new session. Maybe you can embed a special page, (not the regular front end page), where you fetch the page via WireHttp? Or, a bit dirty, you name the iframe with a unique id that you check and pick up in the front page via JS and if it is detected, hide all elements you don't want to show there.

That was one of the first games I had on PC!! I was like 10 or something, I couldn't believe there was such a funny game haha, it really opened my eyes to what could exist as a videogame. Now I'm thirsty for some table melting quality grog.

I get shivers when I hear Monkey Island tune. That is epic ?

Quick update... Finally figured out to get React/NextJS to work with a basic (minimal field types to convert to JSON) PW site. Giving self a pat on the back when I discovered Svelte ? Svelte felt (I'm a poet & didn't know it ?) so much more like PW - JS, HTML & CSS with 'state management' and no shadow DOM. The only problem was routing. I'd spent far too long figuring out React/NextJS routing and Svelte offered no immediate solution. The old (like 2yrs) way of routing was called Sapper. Development on Sapper has ceased with all efforts now focussed on the new way, SvelteKit which is in pre-beta (? ). Anyhoo, went with SvelteKit and got it working. I've only scratched the surface on what's possible with React/NextJS and Svelte. Both offer Server Side Rendering (SSR) making the site SEO friendly & fast-loading. Given a choice, I'd choose Svelte every time. With both React/NextJS and Svelte using @Sebi's AppApi with customisation depending on the framework, I: created a home page that pulls the data from the PW home page created a 'slug' page that pulls the data from the PW page url and displays it in a component based on the PW page template as returned in the page JSON, and shows the correct route in the URL from a nav menu In both cases, the page layout is not a PW template but a conditional component file. Anyone else tried Svelte with PW? Your thoughts & comments welcome

I had a go at something like this a few years ago, exactly after I played a bit with the Perch trial. It didn't gain much traction and I never got to develop the concept further, but what I had was working flawlessly.

This site https://cantinetoscane.it/ wants to map the wineries in Tuscany where to make visits and tastings, I state that it is still under development, I did it in my spare time during this strange year, the translations are approximate, a lot of content / images are missing, there is structure and public data of the companies. I just wanted your opinion waiting to finish it. I also have to fix the design as I write css and html for work. Processwire is great!

Today I had this informational E-Mail in my inbox and simply want to share: ---------------------------------------- Hello from the staff at Let's Encrypt. On September 30, there will be a change in how older browsers and devices trust Let's Encrypt certificates, resulting in a minor decrease in compatibility. If you run a typical website, you won't notice a difference. Devices and browsers running up-to-date software will continue working fine, and we've taken steps to make sure the vast majority of older devices will too. If you run a large website, or need to support less common software (particularly non-browser software), you'll want to read about the details at: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ In either case, no action is required from you. We're letting you know so you can provide answers to any questions your site visitors may have. Since 2015 we've served the world with 1.6 billion free certificates, each one providing security and privacy to people on the Web. It's work that's 100% funded by charitable donations since we are a nonprofit. If your company is interested in sponsorship, please email sponsor@letsencrypt.org. If you can make a donation, we ask that you consider supporting our work today: https://letsencrypt.org/donate/ Thank you. - The Let's Encrypt team ----------------------------------------

Great work @kongondo. This looks fantastically feature-filled. You've obviously made a massive investment in this module, especially from a behind the scenes technical point of view. It is a shame in one sense it isn't built out if processwire pages, but it's obviously more powerful or efficient to have escaped the limitations of that setup. My only concern personally is the UI. I do prefer it over the standard UIkit setup of Processwire but I think myself and my clients would prefer they were closer visually to make it more of a seamless experience. I like the siderbar though, I can't think of a PW paradigm you could have used for that. Could you explain the difference between order notes and order comments though? Great works, thumbs up. Tell me where to send the money.

This module does provide two different added functionalities to FormBuilder. 1. The module does allow users to set default "From" email addresses for emails send to administrators. There's a global address, which is set in the modules settings, and a additional field in the settings for "Send an email to administrator(s)", where one can set a form specific emailaddress to override the global one. Both of those are overridden if you chose to use the "Email from field" setting and the returned value is not blank. 2. The module does add an additional syntax for the textfield where administrator emails are set. If you have a pagefield in your form, where one can choose from the potential users, that should be emailed about your form submission, you don't need to write extensive conditional lines like this: personInCharge=SomeUser?someuser@example.com personInCharge=AnotherUser?anotheruser@example.com You can simply add a email field to the template of those users and use the email provided there. !personInCharge?email The syntax says get the user(s) from the field "personInCharge" and send email(s) to the addresses provided by the "email" field of the selected page. https://github.com/LostKobrakai/FormBuilderEmailExtentions Thanks to madeprojects.com for letting me share this. They'll pay the time I spend to build it.