Leaderboard

We're in the last steps of phasing out the project I was using it on. Most parts had been replaced years ago since we moved away from processwire with that project. The module's approach to access is nice, but iirc there were some bugs in the master implementation and we actually would've needed a bit more flexibility out of it (still needed code to create those dynamic roles). I'd still suggest it over expensive runtime access checks if it aligns to a projects access setup. We've been using it because our access was not only scoped by roles, but also by customers. So a manager would only have access to manager pages, which belonged to a customer assigned to that manager. Customers weren't static, but also defined by pages within the system. Things also weren't segmented into individual page trees, though iirc the modules for segmenting by page tree didn't exist at that time as well.

@kongondo awesome ok. I’m keeping a little doc of bits that I pick up on which I’m hoping will be constructive. it’s not a major issue being that I can edit the variations independently, it’s just that those master product pages with such high amounts of variations crash as one would expect. Fantastic job I must say! I tip my hat to you sir. You deserve every success coming to you with this project!

Do you have access to the PHP code? Try searching the directory /site/templates/ for “WireMail”. If you don’t find anything, search all of /site/ (but not /core/). You’re probably looking for something like this: $m = new WireMail(); $m->to($mailTo); $m->from($mailFrom); Change the $mailFrom bit to 'noreply@yoursite.com' or whatever. If you’re uncomfortable, post the code snippet and the file path, and we’ll be able to tell you if you’re breaking anything. If a module like FormBuilder is used, this may actually be configurable in the ProcessWire backend.

Hey @Guy Incognito Thankyou for your comment, that was the approach i followed. In the end I listened to @bernhard's advice. And so far it has been very successful for my use case.

Done! ? Thanks. https://processwire.com/talk/forum/62-padloper-pre-sales/

This is a temporary board for Padloper 2 pre-sales issues. Is is intended for general pre-sales questions and more specific Padloper 2 topics such as technical/coding questions, bug reports, documentation, feature requests (wishlist) or anything related to Padloper 2. For paid support for Padloper 1, please continue to use the existing VIP Support Board. This open board for Padloper 2 is necessary as it allows non-Padloper 1 users access to a support forum. Please note that once Padloper 2 is officially released, these boards will likely be merged into one. VIP Support will continue but it may happen in an open board with priority given to those with active subscriptions. Padloper 1 topics would be archived (but accessible). Thanks.

I could not have it said better than @MoritzLost did and totally agree. But maybe you can move your post to the new thread?

Hi @alexm. Pete is currently helping me with this. Hopefully this week, we'll have a 'pre-sales' forum that anyone can access. We'll use that for issues, wish list, etc. Ideally, we could have done issues in GitHub but Padloper is not an open project. Both pagination and lazy-loading have not yet been implemented. They are high on my todo list, especially the latter.

Thank you @TheMick- it looks like I did miss that. It sounds like it would work, although I admit it's a bit beyond me - I'm not an experienced programmer. I was hoping to avoid writing functions. I can't remember what I did in the end on my particular project - I think I just decided to use a reasonable number of images that would look OK on 1 page and didn't bother paginating them. If I need to go back to that I will definitely take another careful look at the solution you mentioned and implement it for my situation. Thank you for bringing this to my attention, as other people who come across this thread will now be able to direct themselves to the solution you mentioned ? ?

For anyone interested, I have created a set of placeholder images to be used for webshop projects and such. Should be useful for fellow Padloper 2 testers :) Download it from over here: https://szabesz.hu/_dl/pw/shop/dummy_webshop_images_v1.0.0.zip Note: some items have color variation images included as well.

@bernhard YAML is preferable because it's declarative instead of imperative. This has a couple of side-benefits, like cleaner diff views in git, no formatting issues or different styles and no 'noise' in your commits (all only relevant if you have a git-based workflow with pull requests). But the big thing is that it makes it impossible to create environment-specific configuration, which is exactly what you don't want. If you embrace that the configuration is the source of truth for the entire site state (excluding content), you won't need this anyway. Take your example where you switch a field based on whether the languages module is installed - I would flag this in a PR and consider it an antipattern. Whether a site is multi-language or not should be part of the configuration. If it isn't there's no way to guarantee that the code which works in staging will also work in production, so at that point you're doing all the work for controlled deployments and version control but not getting the benefits. Another downside of PHP is that it's onedirectional by default. With YAML, if a deployment fails, you can just roll back to the earlier version and apply the configuration of that version. With PHP, this may work if the PHP migration is just one single $rm->migrate call with an array of configuration (so basically it is a declarative config). But you have no guarantees that it will, and if you have any logic in your migration that depends on the previous state of the site to migrate to a new state, this migration is irreversible. Migrations do have their place - if you really need to perform some logic, like moving content from one field or format to another. But besides that, declarative configuration files are preferable.

YAML is easier to read and write as PHP and less error prone (Yeah I know, we are devs, but there might be unexperienced devs / users that try to accomplish something fast). Indeed I agree, that PHP would offer more possibilities, but I think most times YAML or another configuration markup are enough. Every developer ist different here. Some might prefer writing directly to the file to change things or add new fields/templates, others prefer to do it via the admin. Update: I would like to shift this conversation to a newly created thread, because we are getting off-topic of sharing out setup/tools.