Leaderboard

Or a hook like this? (not tested much). in site/ready.php $wire->addHookAfter('ProcessPageAdd::getAllowedTemplates', function (HookEvent $event) { $allowedTemplatesArray = $event->return;// normal PHP Array $allowedTemplatesWireArray = new WireArray();// create new WireArray() for sorting convenience $allowedTemplatesWireArray->setArray($allowedTemplatesArray);// populate the WireArray with data // whatever sort you want -> id, name, or multiple props, etc // maybe even a $int = $template->getNumPages(); ? PERFORMANCE ISSUES? (would require looping through all templates) $allowedTemplatesWireArray->sort('-id'); // sorting by ID DESC $allowedTemplatesModifiedArray = $allowedTemplatesWireArray->getArray();// get PHP Array back from sorted/modified WireArray $event->return = $allowedTemplatesModifiedArray;// give it back for passing to ProcessPageAdd -> buildForm() }); You could also use PHP's sort functions to sort the $allowedTemplatesArray but it is simpler to user WireArray sort instead ?.

There's two ways I've tried in the past that worked: 1. Use a regex for your allowed url segments so it won't match "sitemap.xml" 2. Trigger a 404 manually from your homepage template file if the first input segment is "sitemap.xml"

@franciccio-ITALIANO You may also consider to you October CMS (Laravel based CMS) + Shoppoholic as ecommerce solution. There are also a lot of modules free and commercial.

Thanks for your input, @The G. There actually already is a way to solve this, thanks to the previous input from @horst: In the PrivacyWire Settings you can find the "Trigger a custom js function" field: Just add a function name there, which you want to get triggered (in this examle the function is called reloadAfterConsent ) Then somewhere in your code add the relevant function, e.g.: <script> var reloadAfterConsent = function() { window.location.reload(true); } </script> And voilá - your page reloads after every consent saving. One could make this configurable, of course. Would you like to set the duration or something else of the setTimeout?

I see. In that case if you want to learn a PHP framework then depending on your needs I would recommend: Codeigniter 4. Pros: if you are seeking something easy to learn. Small file base. Cons: when looking for a job opportunity, you are less likely to find one needing Codeigniter 4 knowledge. You need to implement your own Login/Registration, even an admin interface must be "built", eg: https://github.com/PemaRekdenDorjee/ci_admin Symfony: Pros: probably the framework used by most "professionals", so job opportunities are abundant when you reach that level. Also, it is reusable PHP components based, so those parts of the system you do not need must not be downloaded/used. PrestaShop core developers already started to refactor PrestaShop by using Symfony. Cons: you get sort of "bare-bone" components and you need to implement your own Login/Registration, for example, even an admin interface must be "built". Laravel: Pros: also widely used but not as part of other frameworks, instead, mostly as the bases of custom sites/applications. It this sense it is "similar" to ProcessWire. You can also find ecommerce, admin, forum and other open source "addon-on solutions" for it. Cons: huge(!) file base, for a small site – for example – it is big overkill to use Laravel, see: https://www.google.com/search?q=Laravel+is+huge CakePHP: Pros: relaitively speaking it is not based on a lot of files, but with 30k+ files it is not "slim". Easy to learn and in this sense similar to Codeigniter. Cons: a bit of a system of the past. Yii: Pros: widely used framework by "professionals", good for job opportunity seeking. You can find admin/ecoomerce extensions for it, or ecommerce systems are based on it. Cons: file base is not small, though it is usually smaller than Laravel. The others: you can also investigate them, similar to what I did above. As for PrestaShop: it is probably the most versatile PHP based ecommerce solution out there, but it takes a lot of effort to learn it, especially if you want to implement modules for it. Basic module development is easy tough, but the hard thing comes when you need to study the internals of this complex system which is being rewritten, so you need to keep up with all the changes, too. Cons of PrestaShop: some things like displaying prices on the frontend cannot be customized enough. If you are lucky it suits your needs, if you are not, then you cannot set it up the way you want. Similar issues are present in other areas of PrestaShop. While it is highly configurable, it is easy to find that there is no way to configure things the way you require. Also, instead of "hooks", it provides overrides to customize the inner workings, which is a limited method compared to a system with a well defined hooking system. The very best thing about ProcessWire is that what you have learned about it years ago can still be used almost 100% today. This cannot be said about most PHP framwworks out there, includnig the ones I picked above.

This module allows you and your site editors to protect a page (and optionally its children, grandchildren etc) from guest access directly from the page's Settings tab. You can also limit access to certain roles. http://modules.processwire.com/modules/page-protector/ https://github.com/adrianbj/PageProtector It makes it very easy for editors to set up various password protected areas on their site, or to simply protect a new page or section while they are still working on it. Ability for your site editors to control the user access to pages directly from Settings tab of each page Include whether to protect all children of this page or not Optionally allow access to only specified roles Option to protect all hidden pages (and optionally their children) Ability to change the message on the login page to make it specific to this page Option to have login form and prohibited message injected into a custom template Access to the "Protect this Page" settings panel is controlled by the "page-edit-protected" permission Table in the module config settings that lists the details all of the protected pages Shortcut to protect entire site with one click In addition to the admin interface, you can also set protection settings via the API: // all optional, except "page_protected", which must be set to true/false // if setting it to false, the other options are not relevant $options = array( "page_protected" => true, "children_protected" => true, "allowed_roles" => array("role1", "role2"), "message_override" => "My custom login message", "prohibited_message" => "My custom prohibited access message" ); $page->protect($options); As alway, I would love any feedback / suggestions for improvements. Hope you find it useful! Page Protection Settings (settings tab for each page) Module Config Settings

We’ve got several updates on the dev branch this week, but I want to finish one more of them before bumping the version to 3.0.150, so will likely do that next week. The biggest change this week is the addition of a new core class called FieldsTableTools. This will be used internally by the $fields API variable for manipulating field table schema in the database, and its methods are accessed from $fields->tableTools(); Though this is one you probably won't be using from the API unless developing Fieldtype modules, so if you just want to know what the benefits are, feel free to skip to the last two paragraphs. Initially these methods are primarily focused on managing unique indexes for fields, though will expand to manage other schema manipulations as well. An example of its utility is also included in this week’s commits—our email fields (FieldtypeEmail) now have the ability to enforce uniqueness at the DB level. If you edit an email field (Setup > Fields > email) and click on the Advanced tab, there’s now a checkbox there to enforce unique values, ensuring that a given email address cannot appear more than once (i.e. not appear on more than one page). The same ability will be added to text and integer fields (FieldtypeText and FieldtypeInteger) as well, but we’re starting with the email field because it’s needed for an update hopefully wrapping up next week: the optional ability to login to the admin with your email address. Having a unique index on a DB column is actually a pretty simple thing, but as it turns out, it takes a lot of code to support the ability in an existing installation. That’s because we have it as something you can toggle on and off (on that Advanced tab), and when you toggle ON a unique index, there can’t be any duplicate values in the existing data, or the index will fail to apply. So there’s a lot of supporting code in FieldsTableTools to do things like detect and warn about duplicate values, delete empty values before adding the index, identify when the index is present without querying the table, reporting error conditions in a manner that understandable and recoverable, as well as the actual schema manipulations that add or remove the index. I realize this sounds a bit technical (and that's partly why I'm not putting this in a more formal blog post), but I think most developers will at some point find it very useful in building sites and applications. Not only will it enable us to safely support login-by-email in the admin (coming next), but it’ll be useful in any situation where you need to prevent a value from repeating. Whether that is in preventing double bookings for a date, location, seat, etc., or preventing any kind of redundancy like post titles, author names, product titles, phone numbers, or codes (UPC, ISBN, ASINs, EIN, SSN, etc.), this feature can come in handy. And supporting it at the DB level is a lot more solid than supporting it at the code level. Right now it’s just supported in email fields, but all of the logic has been delegated to the newly added class so that we can easily support it in any other fields (with text and integer fields coming next). Following that, the $fields->tableTools(); will also be gaining methods for modifying other types of field schema. For instance, rather than just supporting the INT column type for integer fields, wouldn't it be nice to go to Setup > Fields > [some integer field] and select both unsigned and signed integers of different types: TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT, for any new or existing integer field? MySQL also offers a similar array of size variations for other types that would be useful in our text and textarea fields, among others. So you'll be continuing to see ProcessWire offer more options for existing FIeldtypes in future core versions, enabling you to more efficiently store and manage content in PW. But of course we'll do it in a way that keeps it simple, ensuring that you don't have to think about these things unless/until you want or need them.

I have URL segments enabled on the home template and have: regex:^[0-9A-Za-z-_]+$ as the regex for the allowed segments. Everything works as expected.

There's also the following, but be aware the stock module on github has some bugs (see my PRs). I'm also not sure how well it works with pw 3.x. I've used it in the past for assigning multiple types of roles to customer sections in a page.

If you don't need the entire page arrays of $shipments, then only querying the counts will always be way faster. Also, try to use findMany() instead of find(). I just ran three queries on a dataset of ~1100 pages in Tracy, and got an average of ~34ms: <?php $sel_2 = $pages->findMany("parent=1041, template=project, created>$month, include=all")->count; $sel_3 = $pages->findMany("parent=1041, template=project, created<$last2Years, include=all")->count; $sel_4 = $pages->findMany("parent=1041, template=project, images.count>0, include=all")->count; d($sel_2); d($sel_3); d($sel_4); Using just find(), it was about 10x slower. Or you can even replace find() with findIDs: <?php $sel_2 = $pages->findIDs("parent=1041, template=project, created>$month, include=all"); $sel_3 = $pages->findIDs("parent=1041, template=project, created<$last2Years, include=all"); $sel_4 = $pages->findIDs("parent=1041, template=project, images.count>0, include=all"); d(count($sel_2)); d(count($sel_3)); d(count($sel_4)); This takes it down to ~20ms, i.e. approx. 33% faster than findMany()->count Of course, if you have a really huge amount of pages, then a real direct DB-query (avoiding PW's API) will always be the fastest option. Or try @bernhard's RockFinder module.

@fruid I guess the only way to circumvent this behaviour is to delete with the backspace key, instead of "select block and use delete-key". Searching for this issue brought up this PR, which apparently has just been merged yesterday (though I'm not 100% sure if it really fixes the exact same issue).

Since sessions are maintained by cookies and cookies are bound to domains the answer is no – you cannot share a session between domains. What you can do is have only a single domain handle authentication, and all other domains fetch information from that service. See for example oauth or openid connect systems. That‘s rather complex though and not something available in processwire as is.

I would love to see SQLite support in PW. It would allow me to make my PW dev environment portable. I use my perosnal laptop and work PC for development and carry projects in USB Disk. All of my Nodejs and python projects are portable because they all use portable database files (not the database server instance, the actual data files). I know MySQL allows to specify a --datadir when starting, but this is not very portable (at least not for me). I've tried containerizing php and mysql for PW developement, but didn't work out the way I wanted. It just doesn't allow me to get started immediately. If sqlite support is implemented we can use a lightweight portable db in development and migrate to MySQL in production.

Just wanted to say thank you for this highly needed plugin! Is there a way to donate for it?

Hi all, Apologies for the very loud silence! I hope to elaborate more on this a bit later. However, rather than keep people guessing, I'll write something short. I have been working my fingers to the bone to release a beta by spring 2020. I suppose it hasn't gone unnoticed that I rarely post in the forums at large these days. This is because I am dedicating nearly all my time to Padloper. The plan was to start early beta testing in mid-April 2020. This was largely on track. Like many of us, maybe most of us in the forums, we have all been affected in one way or another by the current situation in the world. This has thrown a monkey wrench in the works. I have had to readjust how I work, albeit my productivity taking a hit. I wish I could properly 'guesstimate' how much delay this is going to cause but it will just be futile. On the other hand, I appreciate that you have been waiting for a relatively long time for this release. I want to reassure you that I am not just kicking the can down the road. Maybe I should have been showing you more screenshots of progress but currently, that would just eat further into my limited time. Thanks for reading, and hopefully, your patience. Cheers.

Dynamic Roles are a powerful access control tool for ProcessWire. They pick up where traditional roles leave off, and allow you to assign permissions at runtime based on any factor present with the user. Once a user receives one or more dynamic roles (at runtime), those dynamic roles then specify what pages the user can view, edit, or add children to. If traditional roles are a sledgehammer, Dynamic Roles are a scalpel, allowing nearly any finely tuned access control scenario. Traditional ProcessWire roles are limited to assignment of view/edit/add access on a per-template basis. Dynamic roles go outside those limitations and enable you to assign that access based on any factors present with a page (i.e. match any field values). Dynamic Roles assign new access, but do not revoke existing access provided by traditional roles. As a result, Dynamic Roles can be used together with traditional roles, and the two work beautifully well together. Though Dynamic Roles can also replace all situations where you would use traditional roles for access control assignments. If using Dynamic Roles to assign page-view access, you would typically want to use traditional roles to revoke view access from at least the "guest" role at the template level. Then use Dynamic Roles to assign view access to those pages in a more granular manner. This module directly affects the results of all page getting/finding operations by applying the access control directly to the database queries before pages are loaded. As a result, it is fast (regardless of scale), pagination friendly, and requires no further intervention by the developer other than configuring the dynamic roles as they see fit. Because it relies upon new features present only in ProcessWire 2.4.6+, it requires the current dev branch. Sponsored by Avoine Concept by Antti Peisa Code by Ryan Cramer PLEASE NOTE: This module is in pre-release state (like the PW dev branch it requires) and is not recommended for production use just yet. Though we do appreciate any testing and/or feedback that you are able to provide. While not required, this module benefits from ProFields Multiplier. If you have ProFields Multiplier installed before installing this module, it will make this module more powerful by making all of your access control selectors have the ability to use OR-group conditions. Depending on your access control needs, this enables you to accomplish more with fewer Dynamic Roles. How to install Make sure you are running ProcessWire 2.4.6 (dev branch) or newer. Download from GitHub (we will add this module to the Modules directory later). Place all files from this module in /site/modules/DynamicRoles/. In your admin, go to Modules > Check for new modules. Click "install" for the Dynamic Roles module (ProcessDynamicRoles). Click to Access > Dynamic Roles for the rest (see example and instructions below). Example and instructions Lets say you ran a Skyscrapers site and wanted a role enabling users with "portmanusa.com" in their email address to have edit access to skyscrapers designed by architect John Portman, with at least 40 floors, and built on-or-after 1970. Yes, this is an incredibly contrived example, but it is an example that also demonstrates the access control potential of this module. 1. In your admin, you would click to Access > Dynamic Roles. 2. Click "Add Dynamic Role". Enter a name for the dynamic role, like: "skyscraper-test-editor" and save. 3. Under "Who is in this dynamic role?" section, click "Add Field" and choose: Email => Contains Text => "portmanusa.com". This will match all users having "portmanusa.com" in their email address. 4. Under "permissions" check the boxes for: page-view and page-edit. 5. For this contrived example, we will assume the user already has view access to all skyscrapers, so we will leave the "What can they view?" section alone. 6. For the "What can they edit?" section: Click "Add Field" and choose: template => Equals => Skyscraper. Click "Add Field" and choose: architect => Equals => John Portman. Click "Add Field" and choose: floors => Greater Than Or Equal => 40. Click "Add Field" and choose: year => Greater Than Or Equal => 1970. 7. Click Save. Now users matching the conditions of your dynamic role will be able to edit the matching pages, but not any others (unless assigned by traditional roles).

I know this is a year old, but having just run into a similar issue, I wanted to point out that just adding check_access=0 should solve this particular problem without including any unwanted pages as a side effect.

I am on pw 3 and this is the code that works for me. I am new to PW and haven't yet caught up with hooks -- I got this code from somewhere here. <?php $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->get('template') == 'article') $e->return = "/$page->name/"; } This code that updates the urls is the first half of the redirection game. The other half is about redirecting users to the right article. For that, you will have to use urlsegments. Here are the steps, roughly. -- Enable urlsegments for homepage. => This means website.com/this-is-an-article is a hit to the homepage, and this-is-an-article is the first url segment. -- Use this url segment to get a handle to the article page object. ==> $pages->get("name=this-is-an-article") -- Check if its a legit article by checking for the existence of its id. -- If it's a valid page, redirect the visitor to it. echo $article->render(); return;