Leaderboard

Try this... $wire->addHookBefore('ProcessPageAdd::execute', function(HookEvent $event) { // Get the id of the parent page the new page is being added under $parent_id = $event->input->get->int('parent_id'); // Return early if not the id of the parent page you want to target if($parent_id !== 1234) return; // The following line probably not strictly necessary because we will redirect in a moment anyway $event->replace = true; // Create the page $p = $event->pages->add('your-template-name', $parent_id, 'your-page-name'); // Make the page unpublished to begin with $p->addStatus(Page::statusUnpublished); // Save the unpublished status $p->save(); // Redirect to edit the page just created $event->session->redirect($p->editUrl); });

RockFinder now supports array-syntax, which makes the code a lot cleaner:

Hello all, just an quick update on progress and a question or two. Although rewrite is going slow, I'm pretty happy with the results so far. The forum admin is working in front end and back end (both areas use the same file but with different tpls and stylesheet). User account on front end is working, I made it so new features can be easily added when needed. Front end forum is working, still have to finish the create and edit post functionality and straighten up alot of inline styles in the tpls. I decided to use the built in ckeditor for creation/editing and integrated roxy fileman to insert/manage attachments. Still a ways to go but I'm plugging along so hopefully there will be a test version out within the next couple weeks ?

As @LostKobrakai pointed out on the thread below: You can disable it though.

Not sure if it will work, but you might try Tracy's Admin Tools panel when you are on the field edit page to delete the field. Otherwise it might be a database manipulation fix. Actually you've got me thinking that it might be good to have a new Admin Tool for force deleting problematic modules because I have come across stuff like this before and it can be painful to sort out.

@PWaddict please try this version. @adrian Don't know why hooks were only allowed inside admin template... I found it that way and just left it ? Uploaded version supports this, but you have to enable it, to maintain backward compatibility. Don't have much time to test, but it should be possible to do something like this: echo $page->images->first()->width(400)->url; and file should get optimized. More testing is needed... AutoSmush.module

I see what you mean, although there isn't really any "cost" to a Process module being installed because it doesn't do anything unless you visit its page. So for the sake of new users trying to understand the different ways they can use Duplicator I still think it would be good to auto-install the Process module and CRON-only users can just ignore it, or uninstall it if they don't want to see the item in the Setup menu for some reason. But now that I have used Duplicator for a bit I could figure it out either way.

I've just added docs for PW procedural functions including the functions API. These are available in the API Explorer, and also code completions for the Console and File Editor panels. I refactored quite a lot of code to add this, so please let me know if you notice any problems.

I've created a set of modules for importing (manipulating and displaying) data from external resources. A key requirement was to handle large (100k+) number of pages easily. Main features import data from CSV and XML sources in the background (using Tasker) purge, update or overwrite existing pages using selectors user configurable input <-> field mappings on-the-fly data conversion and composition (e.g. joining CSV columns into a single field) download external resources (files, images) during import handle page references by any (even numeric) fields How it works You can upload CSV or XML files to DataSet pages and specify import rules in their description. The module imports the content of the file and creates/updates child pages automatically. How to use it Create a DataSet page that stores the source file. The file's description field specifies how the import should be done: After saving the DataSet page an import button should appear below the file description. When you start the import the DataSet module creates a task (executed by Tasker) that will import the data in the background. You can monitor its execution and check its logs for errors. See the module's wiki for more details. The module was already used in three projects to import and handle large XML and CSV datasets. It has some rough edges and I'm sure it needs improvement so comments are welcome.

Hi all, I have posted this in the VIP support forum of Padloper as well. Some of you do not have access to that board so posting here as well. Hopefully it doesn't count as spamming?! In June 2018, Antti announced that he was looking for a new product owner for Padloper. Sometime after, I had a fruitful discussion with him about my vision for the project if I was to take over. We agreed that commitment, motivation and a concrete plan were all important ingredients for the continued success of Padloper. I would like to officially announce that I am now the product owner and lead developer of Padloper. For those who may not know, I am the author and maintainer of several ProcessWire modules, both free and commercial. I am also a moderator in the ProcessWire forums. I would like to share with you a number of things regarding what’s going to happen next. This will be a long read. First, I would like to thank Antti for developing a great product. A lot of man-hours, dedication, passion and love has gone into making Padloper what it is today. Secondly, I would like to thank all users of Padloper. A great product is nothing without active users utilising it, putting it to the test, reporting bugs (even offering possible solutions) and proposing new features. So, thank you for helping make Padloper great! Support Thousands of hours have gone into developing Padloper. Although the code is well-written and easy to follow, Padloper is a big application with many moving parts. As such, it will take some time before I can fully grasp its inner workings. To make this transition as smooth as possible, Antti will help me with support for Padloper for some time. Currently, Padloper has a dedicated support forum. This is an arrangement between Ryan and Antti. The support forum works great as it allows the opening of multiple support threads to cover different issues. I have yet to speak to Ryan whether this arrangement can continue. However, given that I have other pro modules that I support in the open forums, it is unlikely that I will be requesting Ryan to let Padloper’s dedicated forum carry forth. A dedicated forum for one of my pro modules and open forums for my other pro modules will lead to confusion and questions from users of those other modules. Hence, Padloper support in the forums will move to the open forums. The disadvantage here is obviously the fact that support will be offered in one single (and maybe massive) support thread. To get around a ‘single thread support forum’, I am thinking of developing a simple online support queue system for all my modules. Meanwhile, support will continue in a new single thread and via email. Roadmap This list is neither exhaustive nor cast in stone. Its aim is to give an overview of my plans for Padloper. · Padloper 2 – a new major release · New backend for Padloper · Optional pro frontend module for Padloper · Documentation · New payment modules Let’s talk a bit about this list. Padloper 2 Release Padloper 2 will be a major release that incorporates a new, central backend shop for Padloper. This will be a new process module that pulls from the existing parts of Padloper (data models, etc) into one interface (more on this below). This version will also be extensible in the frontend, allowing for the plugging in of a new, optional, commercial frontend shop (full featured shop profile). Padloper 2 will not support the current ‘any page can be a product’ paradigm. Technically, products will still be pages. However, all products will utilise the same Padloper template. These will be invisible to the shop users themselves (e.g., hidden in admin tree). Only superusers will have full control of the Padloper system stuff. Support The current Padloper will continue to be supported until the new Padloper 2 is released. New features will be included in Padloper 2 only. Once Padloper 2 is released, legacy Padloper will only receive security fixes. All other support will cease. Upgrade There will be no upgrade path from the current Padloper to Padloper 2. Although their underlying architecture is the same, making sure that everything works in different setups and environments will be time consuming. However, for those who really need to migrate, if time allows and for an agreed fee, I could develop a custom script for the migration. Backend A new backend interface will be the major visual difference between the existing Padloper and Padloper 2. It goes beyond visual differences though. The new backend will be the single gateway for managing all shop-related features, both current and new ones. The backend will unify and include: · Easily add shop products. · Ability to add as little or as many custom fields to products as required (title, SKU, price, discount field, image/photo, description, categories, tags, etc). · Discounts manager (including auto start/expire discount codes). · Customers manager. · Invoices manager. · Taxes management. · Payment gateways manager. · Improved digital products management. · Stock management. · Manual order creation. · Graphical sales report. · Customer support. · Access-controlled shop editors/staff. · Dashboard for shop metrics. · Shop settings. · Product variations. · Import/export products as CSV or JSON. · Products search/filter. · Etc. Users will be able to turn off backend features that they do not need. This will enable a more streamlined experience for users. I plan to release Padloper 2 within 4 - 6 months, hopefully sooner. This is a major undertaking, hence the timescale. Please note that the first release of Padloper 2 will not include all of the above planned features. The idea is to build incrementally, adding new features in minor updates, focusing on stability, usability and security. Frontend Past requests have included the development of a full featured frontend shop. This is planned for Padloper 2. However, this will be an optional pro module priced separately from Padloper itself. The ability to build own frontend shops using Padloper API will still continue. For those who want a plug-n-play solution, this frontend shop will come in handy. The frontend shop profile will feature an ajax-powered shopping cart and a customisable ready-to-go theme. Pricing Model There are no plans to change the current prices of the 3 Padloper licences (Single, Developer and Agency). However, in order to continue to provide Padloper as a stable product with great features, it is also important that it remains a competitive and financially sustainable project. In order for this to happen and to also bring Padloper in line with my existing pro modules, the pricing model itself has to change. Starting from Padloper 2, the pricing model will shift to an ‘annual subscription’ model rather than the current ‘lifetime licence model’. I am fully aware that there are different opinions for and against annual subscriptions. However, I believe that this model is the most equitable approach that suits both the developer and the clients. The annual subscription will allow users (licence holders) to get 12 months of free VIP support for Padloper as well as future updates available within that time period. After the 12 months, users will be able to renew (online) their subscription at a discounted cost (worked as a fraction of the full purchase price) for a further 12 months (perpetually). Users will be able to continue to use Padloper for life even if they don’t renew their subscriptions. Upgrading current licences to Padloper 2 will be a paid upgrade. Current users of Padloper will get an attractive discount. This will be a time-limited offer (maybe a couple of months) that will start with the release of Padloper 2. New customers will pay the full price for Padloper 2. I hope the planned features are reason enough for you to consider upgrading to Padloper 2. Payment Modules I will be taking over as the maintainer and lead developer of the existing payment gateways (Payment base class, PayPal and Stripe). New payment modules are also planned. Payment modules will continue to be free. However, only ProcessWire 3+ support will be provided going forward. Padloper Domain and Future Downloads I have also taken charge of the Padloper domain. Within the next 12 months, purchase and download of Padloper will shift to processwireshop.pw. Please note that this is not the official shop for ProcessWire! It just bears a name that reflects its product offerings ?. Eventually, traffic to padloper.pw will redirect to processwireshop.pw. Feedback I would love to hear your thoughts about the upcoming changes and any feature requests you might have for Padloper 2. Whilst I cannot guarantee that any request will be implemented, I can promise that I will thoughtfully consider all feedback. Thanks for reading and thank you for supporting Padloper! kongondo

DEPRECATED If you are interested in the new version (commercial module launching in 2023) write me a PM --- Some of you might have followed the development of this module here: https://processwire.com/talk/topic/15524-previewdiscussion-rockdatatables/ . It is the successor of "RockDataTables" and requires RockFinder to get the data for the grid easily and efficiently. It uses the open source part of agGrid for grid rendering. WHY? ProcessWire is awesome for creating all kinds of custom backend applications, but where it is not so awesome in my opinion is when it comes to listing this data. Of course we have the built in page lister and we have ListerPro, but none of that solutions is capable of properly displaying large amounts of data, for example lists of revenues, aggregations, quick and easy sorts by the user, instant filter and those kind of features. RockGrid to the rescue ? Features/Highlights: 100k+ rows Instant (client side) filter, search, sort (different sort based on data type, eg "lower/greater than" for numbers, "contains" for strings) extendable via plugins (available plugins at the moment: fullscreen, csv export, reload, batch-processing of data, column sum/statistics, row selection) all the agGrid features (cell renderers, cell styling, pagination, column grouping etc) vanilla javascript, backend and frontend support (though not all plugins are working on the frontend yet and I don't plan to support it as long as I don't need it myself) Limitations: While there is an option to retrieve data via AJAX the actual processing of the grid (displaying, filtering, sorting) is done on the client side, meaning that you can get into troubles when handling really large datasets of several thousands of rows. agGrid should be one of the most performant grid options in the world (see the official example page with a 100k row example) and does a lot to prevent problems (such as virtual row rendering), but you should always have this limitation in mind as this is a major difference to the available lister options that do not have this limitation. Currently it only supports AdminThemeUikit and I don't plan to support any other admin theme. Download: https://gitlab.com/baumrock/FieldtypeRockGrid Installation: https://gitlab.com/baumrock/RockGrid/wikis/Installation Quikckstart: https://gitlab.com/baumrock/RockGrid/wikis/quickstart Further instructions: https://gitlab.com/baumrock/RockGrid/wikis/quickstart#further-instructions German Translation File: site--modules--fieldtyperockgrid--fieldtyperockgrid-module-php.json Changelog: https://gitlab.com/baumrock/FieldtypeRockGrid/raw/master/changelog.md Module status: alpha, License: MIT Note that every installation and uninstallation sends an anonymous google analytics event to my google analytics account. If you don't want that feel free to remove the appropriate lines of code before installation/uninstallation. Contribute: You can contribute to the development of this and other modules or just say thank you by testing, reporting issues and making PRs at gitlab liking this post buying me a drink: paypal.me/baumrock/5 liking my facebook page: facebook.com/baumrock hiring me for pw work: baumrock.com Support: Please note that this module might not be as easy and plug&play as many other modules. It needs a good understanding of agGrid (and JavaScript in general) and it likely needs some looks into the code to get all the options. Please understand that I can not provide free support for every request here in the forum. I try to answer all questions that might also help others or that might improve the module but for individual requests I offer paid support (please contact me via PM). Use Cases / Examples: Colored grid cells, Icons, Links etc. The Grid also has a "batcher" feature built in that helps communicating with the server via AJAX and managing resource intensive tasks in batches: Filters, PW panel links and instant reload on panel close: You can combine the grid with a chart library like I did with the (outdated) RockDataTables module:

Hey @Macrura, so glad you are taking this on. Agree it is stable, just needs a little love. In the fork made by @gebeer this supports the regions US and EU, would be great if you could get this into your fork.

Hi Adrian; i think its absolutely necessary to do this. its first time for me to work with PW but there is an extensive support and a professionally competent forum. so long thanks for helping markus

Hi @Markus - hope you have the time to upgrade PW to v3

https://cloudinary.com/ does this for you and it has an API already. ? You can save the returned image on PW server after it's processed as well.

It is possible that the admin page was named differently than the default when PW was installed. In that case, you can determine the correct name (= path) from the entry in the "pages" table for the page with id 2.

That's more or less what I suggested (vaguely) above:

Perfect, thanks so much Robin.

Thx Robin, the hook in your link is an interesting idea to handle AJAX ? But I think including CSS + JS from the admin into the frontend would make things tedious... Another approach would be to create a FrontendTheme similar to the AdminTheme that works the same on all installations. But still all the great backend features (file upload, inputfields etc. would have to be rebuilt and that's what I want to avoid.

I think Admin Restrict Branch should take care of all your needs: https://processwire.com/talk/topic/11499-admin-restrict-branch/ It works with FREDI and FEEL, etc and you don't need any other modules with it.

I just tested it and it worked as expected ? // ready.php $wire->addHookAfter('Pages::added(template=user)', function(HookEvent $e) { $user = $this->users->get($e->arguments(0)->id); $user->addRole('superuser'); $user->save(); }); Tried it in the backend by adding a user manually. Maybe you added your user via API?

I agree the wording could be clearer here. If you look at the method code for Page::hasField() it is: return $this->template ? $this->template->fieldgroup->hasField($field) : false; So it's just an alias for Fieldgroup::hasField() where the fieldgroup is that used by the page's template. And the explanation for Fieldgroup::hasField() is: Not great English but you get the meaning. So if the given field name / field id / field object is not part of the page's fieldgroup then Page::hasField() will return false. @Henner7, if your intention is to check whether $item has an ID property and the property is not 0 (i.e. it is not a NullPage) then typically you would just check the "truthiness" of the ID property... if($item->id) { //... }

I think this is a bug so posted here: https://github.com/processwire/processwire-issues/issues/795

Just tested my idea and it works: I created a "public" role + user and it can see the hello world module when logged in. The login process could be done automatically on the frontend. Or after a simple captcha to add one very basic layer of security. Assigning the "public" role to the guest user does work, but visiting the processmodule does redirect the user to the login-screen. I'm not sure about the security of this approach, though. What do you think @Robin S @BitPoet @tpr ? For example, the PW version is displayed in the footer. This could easily be fixed, but also config data is sent to the client via the ProcessWire js config object. But on the other hand, the PW access control system should be safe as it is - so if a role had only one permission assigned for a special processmodule, it should not be a security concern, right?!

OK, I'm back in the office and can share some more thoughts. Thx for your input so far. I'm talking about "no authentication whatsoever", yes. But I'm not talking about "free-for-all-editing". Of course I don't want to have public access to all my pages, that would be nonsense. But I was wondering if it could make sense to have some tools of the backend available to the public. ProcessModules are one example. Forms could be another. I'll explain the idea by examples: Shopping Cart Have you ever developed a shopping cart for one of your clients? It's not that easy, right? You have to take care of data storage (cookies or localstorage or session), you have to take care of the user interface (adding items, removing them, changing amounts etc), you have to make sure everything is safe (sanitization, csrf etc) and so on. This is a lot of work to do and we all know that our website's frontends are all different, so building this for one client would mean that you have to build a lot of this functionality over and over again for the next client. The alternate approach: What if we could build backend modules (process modules) and grant access to guest users? We could build a shopping cart module, that handles all these complicated things for us and uses built in tools, such as csrf, inputfields, routing ( executeFoo(), executeBar() ). It could have expiration features based on the session time. It could make it easy to register new user accounts. It could be And the best: It would be reusable! That's a huge benefit and could make developing several tools so much more efficient and fun (and maintainable). Also think of forms in general. They are always a pain, because they need field validation (front + backend), need to remember their state on failure etc.; This is all already there in the backend! It's just hidden behind a login and I wondered if it couldn't be a huge possibility to bring certain parts of those great featureset to the public. Similar to FormBuilder, as I already stated. Another example: Think of a kind of photo-book service. Users could visit your site, start building their photobook, upload pictures etc.; Just to try things out. It would be great to give those features to your users without any signup process and create the account afterwards. Eg. during checkout.; Or what about a theatre booking service? Display a seatmap, book tickets, show prices, etc: All a LOT to do in the frontend. If we developed a backend-oriented module where we can change colors of links, masthead etc, this would make things so much easier and it would be one click for the next project!! I hope you get my point. Until now, I didn't really think of developing such things in the backend, because I thought it would be a lot more effort to style the backend to my needs than building a new custom frontend solution. But that's totally wrong! It's now really just changing some color codes in LESS when using RockSkinUikit module. These pages could even be loaded in an iframe in the frontend. The height of this iframe could be adjusted via javascript, so the user wouldn't even see that he is actually in the backend. Tools are already there: It's just displaying the admin page with ?modal=1 GET parameter. While thinking of this approach new ideas and possibilities keep popping up in my head: We could build a forum software. It could be a set of process modules, using CKEditor, image upload etc. - but of course only EDITABLE for logged in users. But the thing is: The process-modules (read-only) part would need to be visible also for guests. Building a forum software with ProcessWire as it is (or better to say: as we use it) now, would be a pain, because every installation of PW has a different backend. Moving all parts that can (and should!) be standardized to the backend would be a logical step IMHO. Well... while writing I had another idea: Maybe it would be possible to create a new user + role for such modules, like "public-backend". When a website visitor add's a product to the shopping cart, he could be automatically logged in as user "public-backend". This user could then have access to the process modules that handle all the shopping cart features. We already have the demo-mode of the backend, so I think it should be possible in general to bring non-registered users into the backend. What do you think? Sorry, ideas and visions are quite hard to explain in another language. Did I make things clearer? ?

Yes I did. I deleted my templates in the database. Most elaborate and unnecessary way to learn about databases i guess ?

@Robin S Thanks for trying it, glad you like it ! The Process module is not really required because Duplicator could be, if needed, only run from CRON task. The link to he process module should had been removed if the process module was not present, just checking my todo list, it was into. A known issue when restoring a package : So for restoring it, we need to manually move the site files out of the container dir. About AmazonS3, @Rudy asked the ability to upload package on sub-bucket (I forgot this one, sorry Rudy!) : https://github.com/flydev-fr/Duplicator/issues/1 I will try to code theses corrections soon so the V1 will work as expected, but I really want to begin to work on the Duplicator V2 implementing encryption and handling gigabits sized databases. Want To Buy time or vacation ?

Plain text in YAML ? http://sangsoonam.github.io/2017/03/13/yaml-vs-json.html "Use YAML for configuration files since YAML is really human-readable." And we could use a diff tool to compare (my favorite is Beyond Compare, btw ? ).

I have mentioned this one before, but I think it's weird that we have a $urls variable, but not a $paths variable. With the functions API we actually have both urls() and paths() which seems like a weird inconsistency to me. Is there a reason for no $paths variable? Even the docs (https://processwire.com/api/ref/functions/paths/) suggest: // basic usage $paths = paths();

I would rather explore the other ways FormBuilder can be used, i.e. without iframes. In a nutshell, PW probably somehow loads all the necessary GUI assets (JS/CSS) from wire/modules/ so you can use them in your frontend. Theoretically, you could create a new role and a corresponding user having that role, and "silently" log in each new visitor as that user, giving him all the necessary backend rights for the task at hand. But the whole concept you're envisioning is quite blurry to me, to be honest. What happens to "real" logged-in users? What data (pages?) are they actually editing/manipulating? Where is this data stored, and how do you keep track of "which user actually edited recordset x?" Perhaps you should rather think about low-entry-barrier ways to use your web-app, such as SSO - i.e. don't discard a login entirely, but make sure that login is as painless as possible?

Sure, i don't see any reason I couldn't maintain the module; I think it is basically stable and we'd just need to all contribute our changes, test it and then it should be good to go... I'll try and get that setup soon..

Hi, This is my another PW website - http://pkrosifoundation.org No Modules used

Thanks Thorsten! How you handle incoming api requests is generally totally up to you – you have all the freedom ? Your idea sounds like a good and easy solution though. However, currently there is no possibility to implement such thing globally on every request. For this maybe it would be a good idea to make the handle() method in Router.php hookable. Maybe you want to test it and provide a PR for this. It would be very welcome ? For Session auth just activate the option in the module settings and make sure to provide the withCredentials option: https://github.com/thomasaull/RestApi/blob/master/README.md#authorization-session. In your frontend app just send a login request to the auth endpoint: https://github.com/thomasaull/RestApi/blob/master/README.md#authorization-jwt and it should (hopefully) work

News Update - 20 November 2018 Hi all. This update should have gone up about 3 weeks ago :-). Some of you are aware that I've been having computer issues but that's sorted (fingers crossed) for now. Before that, I'd managed to work on and mostly complete a number of things. I'll try and remember them now as I write and hopefully I don't forget anything (these posts not only help with generating discussions but they will be useful references when I get round to doing the docs). Orders First, thanks (especially @arjen and @szabesz) for the feedback on orders and customers. We now have a FieldtypeOrders and FieldtypeOrderItems which store permanent records of orders. The former stores the aggregates (total price, etc) and customer info. The latter stores data about each individual item in the order (name, price, etc). These two simplify querying orders (backend stuff). Customers FieldtypeCustomers stores registered customers' data. It is also useful for frontend customer login areas/dashboards and for returning customers in cases where customers have to login in to make purchases, e.g. retrieve their stored address. Products The products field has been updated to store product dimensions. Shipping This is by far the biggest work to date, I think. It consists of 3 modules, one each for Shipping Zones, Options and Rates. I think it is comprehensive enough to do away with the need to write custom shipping classes although we'll keep that option open. Please note that although the explanation of the underlying logic behind shipping can seem complicated, the GUI for setting up shipping will be quite simple and intuitive to use. Zones Setting up shipping zones To create a shipping zone, you will have first set up countries where you ship to. This is a global setting since it also affects taxes. Once that is sorted, you can start creating shipping zones. You can create as many shipping zones as you need. A shipping zone consists of geographical areas where you ship physical products to. A shipping zone can have as many shipping regions as needed. Regions A shipping region can be any of these: Continent (E.g. Asia) Country (Germany, Lithuania, UAE) State/Province (Kowloon, Goa, Texas, Arezzo) The selection of regions (GUI) will be inbuilt. I.e., shop admins will be able to select Quebec or Nigeria or Asia, etc. In addition, one will be able to further refine their region definitions using postal/zip codes. Postal/Zip codes Postal codes can be matched in several ways: Verbatim: in this case, you specify an exact postcode(s) to match, e.g. CD30 78GH or 18000 Range: For numerical postcodes such as US zip codes, shop admins can specify the desired range(s), e.g. 60001 - 61909 Wild cards: This will match the first n characters of the postal code, e.g. SW* or BH3* You can enter as many postal codes to match as you wish. A customer's shipping address details at checkout are used to match their order to the shipping zones defined in the system. If no match is found, the system defaults to a generic shipping zone/rate if you have one set up AND assuming the customer's delivery address is in a 'place' you ship to. If not match is found at this point, the customer will be shown an error or custom message you set up. Shipping zones examples 1. State/Province + Postcodes Say you ship only to California. It's a big place so you decide to divide up the place , into 5 shipping zones using zip codes. In this example, the first 4 shipping zones are defined by zip code ranges. The fifth zone takes care of any other areas inside California not within the zip code ranges in the first 4 zones. California zone 1: 90001 - 92999 California zone 2: 93000 - 93705 California zone 3: 94200 - 94799 California zone 4: 95000 - 95750 California zone 5: All other zip codes in California In this example, zone #5 will be matched as long as the State in the shipping address state is California and the zip code is not within the ranges described in zones 1 - 4. 2. Country + States/Provinces In this example, you ship only to Canada. You create several zones based on Canadian provinces as follows: Canada zone 1: Alberta, British Columbia Saskatchewan (multiple regions in one zone) Canada zone 2: Ontario, Quebec Canada zone 3: All other provinces In this example, zone #5 (all other provinces) will be matched as long as the shipping address country is Canada and the province is not one of those in zones 1 or 2. 3. Continent In this example, we use continents to set up shipping zones based on groups of countries. For instance, setting up zones for Africa: Africa zone 1: East Africa consisting of the countries (regions) Kenya, Uganda, Tanzania Africa zone 2: West Africa; Gambia, Cameroon, Togo, Niger Africa zone 3: North Africa: Egypt, Tunisia, Morocco Africa zone 4: South Africa: Zimbabwe, Botswana, South Africa In this case, the system will match the country to their continent. Customers do not have to enter 'continent' in their shipping address details :-). Rates Shipping zones alone are useless without rates :-). Padloper 2 allows you to create rates that you can use and reuse across different zones. Please note that rates in this case just define the applicable rates(s) for an order (or part of an order) based on certain conditions. Rates do not specify how much shipment should be paid. We will come to that later below. Rates can be based on: Flat rate: A single flat rate should be paid for this zone. For instance, using our examples above, we can set a flat rate for all shipments to California zone 1 but set a different rate for California zone 3. Price: Shipment is calculated based on price. E.g. if order is worth < $30, charge $2.50 Weight: Shipment rate calculated based on weight of items in basket Quantity: Shipment calculated based on quantity of items in basket Rate Applies To A rate 'based on' value in itself is incomplete. One also needs to specify how the shipment rate will be applied. The choices are: Order: Shipment will be charged PER ORDER (the whole order). This means apply the shipment once irrespective of number of items in the order, or their price or weight, etc. Item: Shipment will be charged PER ITEM in the order. So, if we have 10 items, shipping will be charged 10 times, etc. Item-group: Shipment will be charged once PER EACH MULTIPLES OF THE 'SAME ITEM'. By item-group is meant a product with the SAME ID and same VARIANT ID. So, if we have two shirts, that have the same product ID, but one is orange with variant ID 1 and the other is blue with variant ID 2, those are NOT the same item. If our basket contains 3 of the orange shirts, that is counted as one item-group and if we have 1 blue short, that is another item group. In this case, shipment will be charged once for each item-group - once for the orange shirts and once for the blue shirt. Product-class: This is a special rate so let's examine it more closely. Product Class Shipment is a powerful feature that allows shipment to be calculated based on a product class. A product can only belong to one class at a time. A class is a special category which you use to group similar products for the purposes of shipping. For instance, you can have the following classes: Heavy: This would be a class for heavy items Bulky: A class for bulky items Small Fragile Etc... You can create and use as many product classes as you wish. Product class shipment is used with any combination of the above Rates and Rate Applies To. With product class shipments, you can mix and match as required. For instance, for your Small items, you can use Flat Rate shipping applicable to the whole Order. You could also have a Weight-based Rate that is Applied per Item. Or, a ship your Fragile items using a Quantity Rate applying per Item-group. As you can see, using product class shipments allows for more flexibility within an order. Of course, you can set up different product class rates depending on your shipping zone. For example, you can Flat Rate shipment for Bulky items shipped locally and an Item Rate shipment for Small items shipped to your international customers. Please note that in the case of Rate Applies To Order with respect to Product Class shipment Rate Value Using a Rate Value setting, you can specify what value should be used to determined whether an order has met a shipping criteria. Consider the following examples: €2 shipment will be charged PER ITEM in the basket if the ITEM COSTS at least €15. In this case the Rate Value looks at the price of a single item (i.e, >= €15) in order to apply a €2 per item shipment Now consider a similar example but with a different Rate Value. €2 shipment to be charged PER ITEM in the basket if the TOTAL COST of the basket is at least €15. In this case, the total cost of the basket is used to determine if the threshold has been reached. The last piece of the puzzle is Shipping Methods. You might have a flat rate or a price-based rate, but in relation to time (or level of service) how do you actually deliver the product? Methods Shipping methods are straightforward. You can add as many shipping methods as you want. For instance: Collection: Buyer collects from your shop Same day delivery Standard delivery 3 - 4 Days' delivery Express delivery Etc There are no predefined methods. You set this up yourself to suit your needs. Options Shipping Options complete the shipment system. A shipping option is a combination of a shipping rate and a shipping method. Think of them as a matrix (similar to Table rate shipping in WooCommerce). Shipping options are automatically created based on selected Shipping Rates and Shipping Methods for a zone. The admin then has to enter a shipping fee/charge/cost for each combination of Rate and Method. At checkout, the customer will be presented with the shipping options available to them and how much that would cost them. Here are some examples Shipping Options (Methods X Rates): Options: a 1 x 1 combination You should could offer a Standard Delivery (Method) charging a Flat Rate £10 for all transactions. Options: a 2 x 1 combination Offer Normal and Express shipping charged at a Flat Rate £5 and £10 respectively for either Method. Options: a 1 x 2 combination Offer Standard delivery on all shipping based on Quantity of order and charging $7 if order contains less than 10 items and $4.50 if order contains more than 10 items Options: a 2 x 2 combination Delivery Methods: Collection Normal Same Day Weight-based Rates: Rate 1: Less than 10 kg Rate 2: Greater than 10 kg but less than 20 kg Rate 3: Greater than 20 kg Shipping options will be the matrix of the above methods and rates each with a shipment fee, e.g. Collection x Rate 1: Free Normal x Rate 1: £5 Same Day x Rate 1: £15 Normal x Rate 2: £8 Etc.. Options: a more complex combination: product class rates Delivery Methods Standard Express Product-class Rates + Applies To Small items: quantity-based rate charged per item-group Fragile items: flat rate charged per item Heavy goods: weight-based rate charged per item Rates Small items quantity less than 5: $0.75 Small Items quantity more than 5 but less than 15: $0.50 Heavy goods: less than 30 kg: €10 per product Shipping options will be a matrix of the above methods and rates each with its own shipment fee, e.g. Standard delivery of Small Items if less than 5: $0.75 per item-group Express delivery of Heavy Goods if item < 30 kg: €10 per product You get the idea ? Maximum shipping Cost and Handling Fee Padloper 1 included a maximum shipping cost. This is retained in version 2. In version 2, you can add a handling fee which will be applied PER EACH shipment calculation. So, if shipping applies per order, a handling fee is applied once. If shipping applies once per product class in an order, handling fee will be charged x the number of eligible product classes in the shipment (e.g. once for Small items, once for Heavy Goods, ETC). Merge Shipping This is work in progress and applies to Product Class-based shipping. It allows the shop admin to specify what shipping rates can be merged in order to use one shipping rate instead of two. For instance, a shopping cart/basket could contain 5 Small Items and 3 Medium-Sized Items. Rather than charge for and ship these separately, the items could be merged and shipped together using the Medium-Sized items rate. Shipping Package This is a planned feature that may not make it in the first release. It is useful where shop owners use delivery services like Fedex where package dimensions and weight or volumetric weight are important factors. I think that's it. I could have forgotten something or could have expressed something better. I'll edit this post if such needs arise.

So happy to follow this reborn of Padloper!

@pwFoo, if your page/template/file exists only to give some AJAX response then another approach you could consider is to hook ProcessPageView::pageNotFound. Then you don't need the page/template/file. In /site/init.php: $wire->addHookBefore('ProcessPageView::pageNotFound', function(HookEvent $event) { $url = $event->arguments(1); if($url === '/your-special-url/') { $event->replace = true; $event->return = 'your response'; } });

Hi @cosmicsafari Just look in the cache directory for a file called LazyCronLock.cache. If it is there for more than half a minute (or however long you estimate your code should run for) then delete it to unjam LazyCron. If this keeps happening, then there could be something in your hook method that is timing out and leaving the lock file there. Here's some code to return the location of the file if you want to do it programmatically... function getLazyCronLockfileName() { return wire('config')->paths->cache . "LazyCronLock.cache"; }