Leaderboard

Another German Processwire „Review“ “When web development has to be quick“: https://www.golem.de/news/processwire-wenn-webentwicklung-schnell-gehen-muss-2209-167784.html

I'll share my youtube videos in this thread and if you have questions this is the place to ask. You can also subscribe to this thread to get notified when I post new videos ? Here is the link to my channel: baumrock.com/youtube --- Hey! I've just published my very first ProcessWire video. It's about RockFrontend: https://processwire.com/talk/topic/27417-rockfrontend-??-take-your-processwire-frontend-development-to-the-next-level/#comment-225666 Here is the video: What do you think? Do you understand what I'm trying to explain (despite the many ääähms und öööhms...)? ? What about the length?? I really didn't plan do get to 40mins... Did anybody even watch it till the end? ? Would it be easier to follow when having a small thumbnail in the bottom corner when working on the code? Or better without? Is it worth the effort of creating a video or would a readme be just as good? ? Any tips for better sound/lighting? I'm not really knowing what I do, so any ideas for improvements are very welcome ? Better with or without background music? So many questions... So much to learn... ? But it's fun and I'm a bit proud ?

Hello all, I have released RockFrontendTailwind, an extension module for RockFrontend. It extends Bernhard's module and adds an installation profile for site development with Tailwind CSS. Obviously RockFrontend is a required dependency for my module to work. This module aims to give you a quick start with a Tailwind based project. What RockFrontendTailwind does: A folder "rockfrontendtailwind" will be installed in site/templates. That folder contains all the configuration files needed to get you started with a webpack-based build pipeline for JS and CSS with webpack tailwindcss postcss with postcss-preset-env (for autoprefixing) babel (for transpiling) So rather than just building the CSS with Tailwind, the build pipeline also takes care of transpiling your Javascript based on configuration in a .browserslist file. Of course, the setup is opinionated. But people who are comfortable working with webpack can easily adjust / extend the configuration to their liking. The default configuration watches your JS and CSS files and compiles them into site/templates/assets main.css and main.js by default. All paths are configurable through a .env file. Live reloading during development is not part of the webpack configuration since this is handled by RockFrontend already in a very efficient way. Also a _main.php file including a very basic boilerplate for a typical setup will be placed insite/templates. It includes examples on how to render your JS and CSS assets. More detailed instructions over at github. Adding new profiles to RockFrontend through your own modules is quite straight forward thanks to the clear structure in @bernhard's module. RockFrontendTailwind can serve as a boilerplate. The only important thing is that the "profiles" folder structure remains the same. The module is currently in beta but runs very stable. It will eventually be released as an official module in the directory soon. If you want to give it a shot, I shall be happy to hear your feedback. If you are looking for a standalone webpack build pipeline with webpack-dev-server, you might want to have a look at https://github.com/gebeer/tailwind-css-webpack-processwire-starter Happy Coding!

Thx for sharing @zoeck It's always a little disturbing to read comments on such posts... So many wrong assumptions and judgements... It's such a shame... ProcessWire is such a brilliant and powerful tool. I've been working with PW extensively for several years now and still sometimes get the feeling that I'm just scratching the surface... And with all that power and complexity (beauty) behind the scenes ProcessWire still looks like something that even an intern can read and understand at first sight. How genius is that? And how wrong is this guy with his judgement?! But I can't blame him. I was in the same situation 8 years ago... I think that is a quite common reaction. And I wonder if we could do something about that. Or if we should? I don't know ?

I have just released version 2 of RockMigrations: GitHub: https://github.com/baumrock/RockMigrations Modules Directory: https://processwire.com/modules/rock-migrations/ Please star the module on GitHub if you like it ? Are you unsure if RockMigrations is the right tool for you? @Jonathan Lahijani in a very nice PM ? Read the full post here Read the full post here Read the full post here QuickStart The example code uses bd() calls for dumping data. You need TracyDebugger installed! Put this in your site/migrate.php /** @var RockMigrations $rm */ $rm = $modules->get("RockMigrations"); bd('Create field + template via RM'); $rm->createField('demo', 'text', [ 'label' => 'My demo field', 'tags' => 'RMDemo', ]); $rm->createTemplate('demo', [ 'fields' => [ 'title', 'demo', ], 'tags' => 'RMDemo', ]); Reload your site and you will see the new field and template in the backend and you'll see the message in the tracy debug bar.

I have setup a starter kit for developing PW sites with Tailwind CSS. You can find it at https://github.com/gebeer/tailwind-css-webpack-processwire-starter I know, I'm a bit late to the party with Tailwind. In fact I only discovered it a couple of months ago and found it to be a very interesting concept. It took quite some time to get a pure webpack/postcss/tailwind setup that features live reloading dev server, cache busting, supports babel as well as autoprefixing and works well with PW. For the cache busting part I developed a small helper module that utilizes webpack.manifest.json to always load the assets with the correct file hashes for cache busting. No more timestamps, version numbers or the like required. The little helper can be found at https://github.com/gebeer/WebpackAssets Having used it for the first time in production on a client project I have to say that I really enjoy working with Tailwind. The concept of using utility classes only really convinced me after having put it to practice. During the work on the client project, some quirks with webpack-dev-server came to surface. I was able to solve them with the help of a colleague and now it is running quite stable in both Linux and Mac environments. I am fascinated by the fast build times compared to using webpack/gulp or gulp/sass. Also the small file size of the compiled CSS is remarkable compared to other frameworks. So this will be my goto setup whenever I am free to choose the frontend framework for a project. If anyone feels like they want to give it a try, I shall be happy to get your feedback

Capturing the amount is about manually trying to prevent fraudulent transactions, because by not finalising the whole transaction in one go, the shop owner can intervene and decline the payment. This way there is no need to do a full refund later on, which is costly. On the other hand, a person manually checking each transaction takes time, which is also costly... You can probably learn more here: https://stripe.com/payments/payment-methods-guide 2.1 For e-commerce and marketplaces Recommended: Cards, wallets, bank redirects, "buy now, pay later"

You can choose on your implementation if you want to charge the user's card immediately ("capture") or only reserve the funds for later capturing (via Stripe admin or API). The only problem is that it doesn't make much of a difference to the user (Stripe event advises that many users won't see a difference on their CC statement between "reserved" and "captured" amounts). Even if an amount is "only" reserved, the client can no longer dispose of these funds.

yes, new_su has user id 1065

Hey @gebeer thx for that great message, really happy to hear that ?

The last of the PHP 7.x series, PHP 7.4, will become fully unsupported (no active support + no security support) on 28 November 2022. At this point (around 2.5 months from today), the minimum PHP version requirement for Padloper will be PHP 8.x.

Where's that recommendation? I'm not sure I understand the question. Do you have an example or use case?

Thank you for all your valued feedback so far. This is an opinionated setup, like almost all of webpack setups are in a way. I'm using this as a working starter and therefore tried to keep it as lean as possible, only concentrating on tailwind, postcss, babel. If I needed to add other libs like Alpine etc. it can be easily extended.

What about we make this some kind of universal profile which works with webpack, bun, npm, yarn, vite... whatever. Or at least use this a guide for setting up all of those different setups. I never really used any of these tools - at least six months or so ago - right now I use NPM due to other tools I use now and therefore kind of started to like it (and as it's super portable through all OS I use, have to use or play around with). As soon as I am back at home I could provide a NPM/TailwindCSS/AlpineJS/browser-sync setup. Pre-Version of the mentioned above can be found here: https://github.com/webmanufaktur/processwire-addon-tailwindcss-alpinejs-barbajs

That's true. Sadly I am a performance junky and interested in new and shiny things, and so I try out almost everything. Another hint: Use bun instead of npm for installing npm modules. It is sooooo much faster. It can do much more, but I use it just as a npm replacement for now.

Hi @gebeer. Using webpack nowadays feels a little bit outdated for me, because with vite (from the creator of vue.js) setup is so much simpler and faster, and it comes with first-class support for most frameworks like Tailwind or vue out of the box. But it can't do all things webpack does (not yet). Two or three years ago I used a similar approach to what you did now, as you can see in my jmartsch/acegulpandpack: A set of gulp tasks with JS transpilation, webpack, SVG Sprites and minification (github.com) repo. With vite you use native ES modules instead of transpiling and bundling every time something changes. This makes the development process much (MUCH) faster. If you ever seen it in action, you would not like to go back to webpack. If you guys are interested in a modern build environment for your CSS and JS, I could see if I find the time to write a tutorial for it.

Instead of having extra fields and saving extra data, you could make use of the $page->references() method, I mentioned above. You could utilize this method inside a ProcessPageEdit::buildFormContent hook and add a Markup field that holds the titles (and even links) of the referenced pages. Just an idea.

Did you have a look at $page->references() method? This gives you all pages that reference this page. In the page edit screen you can see those in the "Settings" tab under "What pages link to this page". With this method available in your template php maybe you don't even need your hook. And there is @Robin S's module ConnectPageFields that handles those cases. You might also want to take a look at @Martijn Geerts' FieldPageSync Module that also does something similar.

You can get user created and modified for a page with <?php $page->createdUser->name; $page->modifiedUser->name; $page would be $child in your code