Leaderboard

Or maybe better update the docs so that they can reference blog posts. We have many important explanations in blog posts and the should be linked from/to the docs imho ?

? How to provide solutions to the community for free forever working on ProcessWire ? ? Apply to the following job, do physical activity to prevent hypertension and improve mental health ?

We need to think about pros and cons when choosing. The pro arguments for 1 is that you have all data in a page tree visually related and that you can easily delete all related data deleting the corresponding order branch. As always, these pros are also the cons for the the opposite solution (3). Choosing 3 you can more easily see the lists of payments and fulfillments records. You can delete orders without deleting connected payments and fulfillments records if you need, but you also have to deal with the housekeeping when deleting by yourself. If you build the dedicated UI for all that in admin it might not even matter. As for me, feel inclined to go the 3rd root and do not see any arguments going the 2nd.

Turn on Guest Dumps - "Enable Guest Dumps" button on the Panel Selector.

Just thinking loud: Maybe it's enough to have some links to the related blog post in the docs. Sometimes I'm missing some code examples, so I'm searching through the blog and almost every feature is well documented and explained there, too.

Another reason for doing some deep thinking about the entity model before choosing. If payments can only ever belong to an order (and only one order) then they should be children of the order otherwise they risk being orphans. If payments can cover more than one order, then they should stand alone, but you need to do serious thinking about how they are allocated to each order if the amounts don’t match exactly. This might be achieved via an “allocation” field (float or decimal) in the order and the payment. And/or you might need to split orders down into order lines. An accurate understanding of the business model is required. Plus how it might evolve. Then do the entity modelling. Lastly decide how to implement in PW. And don’t forget that @Robin S‘s excellent ConnectFields module is just the biz for maintaining many-many relationships (e.g. between the two allocation fields referred to above).

Yes, the blog is a PW website. I've had the honor to write one post there some time ago ? I agree that it would be nice to have it on github so that everybody can contribute. But we have lots of blog posts and converting all of them would be a lot of work I guess. But realistically I think nobody would ever contribute a lot except from maybe reporting typos... So I doubt it would make a huge difference if everything was hosted on github.

If anyone is looking for a workaround: Using JS fastclick solves this issue for me. This seems to be an iOS related problem. If you google for "iOS double tap link issue" you'll find plenty of threads. Mostly they have to do with CSS hover pseudo elements but this was not the case here.

@StefanowitschAt the moment there's no option to do that. I've asked somewhere earlier in this thread about it and would like to have this function, too. ?

Hey @kongondo, do you know a rough release date for the discount feature? Looking forward using it (or a workaround) by the middle of this year. Or is here anyone who already build an addon/hook for this? Kind regards, Guido

Thank you, that worked flawlessly! I was a bit scared of manually updating 4 production sites this way, but I managed to complete the task without any real issues.

Is there a simple way to turn the cookie banner active/inactive in the module settings? I would like to prepare a default banner for my projects that is not shown by default.

Exactly. I'm happy that you see and understand the potential and that you share that ? Definitely ? Thx for the comment! Having everything in one huge migrate.php does not only have the drawback of getting messy quickly. It does also mean that your migrations get slow, because whenever you change anything in that file all migrations will run, no matter if they are necessary or not. If you have everything in separate files on the other hand you get cleaner code, easier to understand chunks and RM will only trigger the migrations that have changes since the last page load, which makes page loads usually be ~1s here even when migrations run. Yep! ? If you understand the principle once, then you will instantly understand every project you are working on that follows the same simple principles.

ChatGPT is soon to replace Google, Stackoverflow and Quora for answering questions like these. I have used it to either confirm or throw speculation on topics and directions of research. I have asked it very technical academic questions in certain fields and it has given balanced views for just about everything, including outsider views and newer untested views on certain problems. Very fun. It has even been able to tell me when a problem that I thought still existed has already been resolutely solved. Such a time saver! My main comment, though, is that the marriage of page classes and migrations is truly groundbreaking in terms of modular design and in particular the ability to bring over single files that can instantly put in (or remove) scaffolding for demos. This has been AWESOME for live brainstorming and troubleshooting or providing clients with examples of how extensible the system is and how quickly modifications and improvements to functionality can be built out. This has made me more excited about using RockMigrations - I was a bit on the fence when the automation was centralized in migrate.php because of how unwieldly automation scripts can get in other applications I use - but bringing things that involved scaffolding into their respective page classes allow me to really just use migrate.php for mod installations, configuration, general hooks and other core modification processes. This is way easier to navigate, share and especially train on. This method is very easy to coach new devs on also.

@kongondo ?? Oh, looking at the code, I thought you code pass it an order page!! How embarrassing that it's that obvious. I genuinely want to bury my head!!! Sorry for wasting your time bro. Can I help with your documentation perhaps? I could add to it and you could correct my solutions as you go? ?

Note to anyone using potentially using this module: A page-edit-redirects permission has been added to the core - https://github.com/processwire/processwire/commit/dafceffc6f5d2d10c395faa1586ef0993633e6de - and once this hits the master branch I intend to rework this module so that it provided a list of redirects in the system. As the permission can be added to any user role, management of those redirects will happen in the page editor instead of the 'cloned' redirects editor this module currently provides. Cheers, Chris

On this side, I don't really find the spambots or seo bots to be much of an issue, so I mostly ignore them unless they get too aggressive. It's instead the vulnerability scanners that tend to be the issue here. They are fine when they are throttled. But when they are unthrottled (as is usually the case), they eat up a lot of resources. Here's just one basic example: a vulnerability scanner might send through thousands (or tens of thousands) of URL variations looking for SQL files that it can grab, with dozens of different names each, like db.sql, database.sql, backup.sql, [domain].sql, database-[domain].sql, db-[domain.sql], [domain]-db.sql, and so on and on and on. Then add all the extension variations, .sql, .sql.gz, .sql.tar, .sql.tar.gz, and then add every URL with a trailing slash in the site as the prefix path for every check. So just a scan for SQL files in-the-open might account for tens of thousands of requests. And it'll try to do them all in a very short period of time, making the server like ours scale to meet the demand. Yet this is just an example of one vulnerability check out of thousands that it'll do. Once a vulnerability scanner gets started, it'll run for potentially days. But I usually block them well before that. Once I get an email from AWS about things scaling, I watch the logs pretty closely and then start blocking IPs. But the goal is to have the module just block them automatically. What the module does is that it allows you to define suspicious patterns in GET or POST requests, or user agent strings (and it comes with several patterns to start). For example, you might have patterns to match things like wp-login.php, those SQL request variations mentioned above, requests for .py, .cfm, .rb, .exe files, or others that you don't use on the server, requests containing SQL commands in the query string... these are just obvious examples. Then it lets you define a number of strikes till the IP is out. So for every pattern match, the IP gets a strike. So if I set it to "3 strikes and you are out" then once it gets 3 pattern matches, the IP is blocked for a period of time, also defined with the module. If additional strikes occur while an IP is blocked, the block time gets reset so it starts over, ensuring it's always blocked that set amount of time from the last strike.

@wbmnfktr Have you given Jeffrey Star's 7g firewall a try? Very simple install straight into your .htaccess file.

Just hit into this recently, seems very concerning... is this something that needs to be fixed or has already been in later PW verisons?

on php 8.2 i have the same errors: for a temporary fix until it is updated i just added these lines to Padloper.module: public $padloperDownloads; public $outOfStock; // added for 8.2 public $productNotFound; // added for 8.2 public $checkYourOptions; // added for 8.2 public $session_id; // added for 8.2

Following steps: Download the latest stable version of PW here Unzip the files Rename index.php > index_new.php and wire folder to wire_new Upload the files via FTP to your website root folder Rename ./index.php to ./.BAK.index.php and ./wire/ to ./.BAK.wire/ on server side Rename ./index_new.php > ./index.php and ./wire_new/ to ./wire/ Refresh the whole site > you maybe forced to relogin. Reload the modules by clicking the button on example.com/processwire/modules/ in the upper right corner After that you could use the ProcessWireUpgrade module to upgrade the other modules. Steps are also documented here: https://processwire.com/docs/start/install/upgrade/ if you have troubles have a look right here: https://processwire.com/docs/start/install/troubleshooting/#troubleshooting-upgrades Cheers ?

Hi @Kiwi Chris I've added a config setting to prevent migrations if you don't want them to be triggered automatically: $config->noMigrate = true; https://github.com/baumrock/RockMigrations/#running-migrations For adding this setting only to your local dev setup see https://processwire.com/talk/topic/18719-maintain-separate-configs-for-livedev-like-a-boss/

@snck I am currently working on implementing Repeater Matrix support. It is basically working but needs some more thorough testing. ATM the setMatrixItems() method seems to be working well. If you like, you can grab a copy from https://github.com/gebeer/RockMigrations/tree/repeatermatrix and test it out. This is how you create a Repeater Matrix field: // first create the blank field $rm->createField('repeater_matrix_test', 'FieldtypeRepeaterMatrix', ['label' => 'Product Content Blocks', 'tags' => 'products']); /** * Set items (matrixtypes) of a RepeaterMatrix field * * If wipe is set to TRUE it will wipe all existing matrix types before * setting the new ones. Otherwise it will override settings of old types * and add the type to the end of the matrix if it does not exist yet. * * CAUTION: wipe = true will also delete all field data stored in the * repeater matrix fields!! */ $rm->setMatrixItems('your_matrix_field', [ 'foo' => [ // matrixtype name 'label' => 'foo label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], 'bar' => [ // matrixtype name 'label' => 'bar label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], ], true); Still need to test the other methods for removing/adding items etc. But this one should work. At least it was working in my tests. When testing is completed I will make a PR so @bernhard can implement.

The latest version of RockMigrations comes with a console on the module's settings page. What does that mean? It is now easier than ever to create custom "site-profile" like installation scripts that you can just copy and paste into that console. Add or remove the lines that you need or don't need, check the checkbox to run code on save and hit the save button!! ?

Another thing is, you can re-use custom page classes in new projects and have their fields/templates created automatically. Develop them only once, copy them over to a fresh PW install, and there you go.

https://processwire.com/api/ref/page/get-unformatted/ $timestamp = $page->getUnformatted('event_start');