Leaderboard

I think you may have downloaded the dev branch at an unlucky time. Looks like this issue which has since been fixed. If you’re on that version, try updating.

Padloper 2 documentation can be found here. This is WIP but has the very least to get your started. It is a bit rough around the edges. We'll improve it as we go along. At the very least, I suggest you read these sections: Getting Started API, especially the finder, cart & checkout and session order chapters. Frontend. With respect to the API, the most important thing to know about is the $padloper global variable. It is your gateway to nearly everything (finding things, carts, checkouts, orders, etc.) in Padloper (2). Please do let me know if you find any errors. I am also working on the starter (demo) site repo. This and the docs should hopefully help move you along. If I get a minute, I might throw in a quick demo video. No promises though ?. Happy reading ?.

Ah, but it wasn’t fruitless at all! Now you have the error message: “Page name does not contain restore information”. What is $trashedPage->name? It’s supposed to be the page’s ID, a period, the parent’s ID, another period, the sort position, an underscore, then the actual name, e.g. “2048.1999.4_felt-cute-might-trash-later”. ProcessWire needs this info to know how to restore the page. If it’s not there, something must have gone wrong when the page was trashed, but you can probably just add it manually. If everything else is good, the restore button should then appear in the page tree. It would be neat if ProcessWire showed this info to superusers. It could just be where the restore button would otherwise be, or the restore button could be deactivated with the note appearing on mouseover.

@Jan Romero, guess what version the site is on: 3.0.191 ? I always use the dev version for new sites and never ran into any issue. There's always a first for everything. ? Thanks a million, I searched the web and the forum up and down but didn't find it. You saved my day.

Once my PRs are approved the latest version of this module will make it possible to set the main color via an inputfield:

Nope, that was my first idea ? Yeah, it should, but it detects PRODUCTION on my dev setup! Great! That works and solves my problem ? I'm using different configs for dev/production so that's a perfect solution ?

Hi @bernhard - a few questions / comments. 1) Does it work if you select DEVELOPMENT instead of DETECT? 2) DETECT should take care of determining whether you are in a local dev environment vs a remote server. 3) The Output Mode panel will tell you what mode has been detected. 4) Does it help if you put this in your config.php? $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, ];

Several updates have been pushed to the module. The latest one concerns the fireOnRefresh method / strategy. If you are using this technique together with bootstrapping ProcessWire be sure to test everything as this change might introduce different behaviour than before! From the readme: Note about fireOnRefresh() Prior to v0.0.82 the fireOnRefresh did NOT fire in bootstrapped environments. This is because ProcessWire by default runs as guest user when bootstrapped and the fireOnRefresh method did not attach any hooks if the user was no superuser. That was a problem for me because a $modules->refresh() did not trigger any migrations when invoked from the commandline. To solve that issue v0.0.82 introduces another concept: fireOnRefresh fires always after Modules::refresh even for guest users. If you need to prevent RockMigrations from firing actions that where attached via fireOnRefresh you have two options: Setting a constant: define("DontFireOnRefresh", true) Setting a config property: $config->DontFireOnRefresh = true; Note that the setting must be available to RockMigrations BEFORE the action gets attached via fireOnRefresh. This is best explained by examples: define('DontFireOnRefresh', true); include("index.php"); // fireOnRefresh is triggered here $modules->refresh(); // this will not trigger any migrations We define the constant before ProcessWire gets loaded and therefore any module attaching migrations via fireOnRefresh will actually NOT attach any migrations because the flag to prevent that is present when the triggered from init() or ready(). include("index.php"); // fireOnRefresh is triggered here $config->DontFireOnRefresh = true; $modules->refresh(); // this WILL trigger all migrations! In this example the migrations will be triggered because the migrations have been attached BEFORE the config setting was set. In other words the flag was set too late for RockMigrations to realize it.

Ah I see, I have a hook that auto generates names for these pages so that was the culprit. Checking for status 'trash' before doing the name change solved this problem.

Just a quick question: I cannot see any sign of promotional coupons/discounts in the screenshots nor in the text of the docs. When do you think you might be able to start working on it in the future, the earliest? Regarding the projects I need to work on, coupons/discounts and Stripe payment is the only major missing bits I could spot so far. It would be great to see them being implement during the beta period. As far as coupons/discounts are concerned, first and foremost I am thinking of a developers' API (and/or hooks?) upon which we can implement virtually anything we might need to. Usually my clients do not even want to touch this area in the webshops I manage, so for me there is no need for an admin GUI at all. Sure, being able to manage coupons/discounts in the admin will be a must for many, but to start with, a versatile way to tap into the calculation of the Total price would be preferable as most of the time I am asked for promotional methods which often not pre-made in any system out there at all. And this also includes adding gift items to the cart, and sometimes such gifts are not even sold in the store, being promotional gifts only. So I am mainly interested in an API which allows us to modify the Cart / Coupons / Subtotals / Shipping / Insurance / Total based on any custom requirement. Meaning adding any customs cost as well, when required. I hope this makes sense :)

Give a look at this blog post: https://processwire.com/blog/posts/pw-3.0.153/

This week there have been various small core updates and fixes but the biggest change was to the installer in 3.0.191. Last week we removed all but the site-blank profile from the core, cutting in half the size of the core. And because of this, the installer now needed to provide more direction about downloading and installing other site profiles. So it now does that and it also links to a new page that describes all of the past and current site profiles, along with additional details on how to create and install site profiles. Speaking of creating site profiles, the Profile Exporter module was also updated this week. It is now PW 3.x exclusive and is updated to recognize and work with various aspects and $config properties that are specific to 3.x. ProcessWire 3.0.191+ and the Profile Exporter module now support a custom /site/install/finish.php file which is a template file that is called when installation of a new ProcessWire and site profile has finished, but before it has cleaned up the installer. It is a plain PHP file that has access to PW's API and the installer, so it can do pretty much anything you could do from a regular template file or module. I added this because I noticed a few issue reports for the Profile Exporter module were requesting support of one thing or another, and I found that nearly all of them could be added just by having a profile-specific finishing file, for those that want it. So if you want your site profile to perform any other types of customizations on top of what you can already do with a site profile, this is the place to do it. This is where things are at this week but perhaps we'll continue to go further with the installer in supporting more things too in the new year, as there have been several good ideas. Thanks for reading and I hope that you all have a Merry Christmas and/or Happy Holidays!

Happy New Year! Hope that you all have a great end to 2021 and start of 2022. No major core updates to report this week, just a few minor issue fixing commits, so no version bump today. The dev branch is getting close to 100 commits (and at 7 versions) above the master branch, and with even more improvements/fixes/optimizations than that. So we may try to get a new master/main version out in early 2022, as I'd really like to get more master versions out in 2022 than we did in 2021. Some portion of our audience does not use the dev branch where most of the activity happens, and so it might be nice to share more of that activity on the master/main branch. That's one of many things I'm thinking about as the New Year approaches and am certain 2022 is going to be a great year for ProcessWire and the community. Hope that you have a great weekend and Happy New Year!