Leaderboard

no argumentas needeed what.u wants is event->return wire()->addHookAfter('Page::render', function (HookEvent $event) { $page = $event->return; });

super user.s required to create fielders y templatos purposefulness of super user this.is with out such purpose is not.super

Great purchase which will save you a lot of time:

pw alreduy.usus PDO

Thanks for pointing these out. Latest release (2.1.0) includes improvements to spacings and the position of the triangle. Just for the record, the positioning is of the triangle was actually intended to be consistent with Admin Theme Uikit, where it's also off-centre, but I've now centered it in Admin Bar anyway ? In 2.1.0 the problem with "add new" button has been fixed. My initial idea was indeed to leave these buttons out if they have no purpose, but opted to leave them as-is, because that's how it's always been. For the same reason I was slightly hesitant to remove the full stop: this change will break existing translations. I've now done it anyway, since it's a relatively small thing. Note that 2.1.0 is actually bigger update than I anticipated. Class names have changed a bit, all themes had to be updated slightly, there's new JS, layout is now based on flexbox instead of floats, etc. So far things seem to work as expected (better than before), but let me know if there are any new issues ?

I've spent the last while experimenting with srcset implementation - and PageimageSrcset is the result: PageimageSrcset Provides configurable srcset and sizes properties/methods for Pageimage. Overview The main purpose of this module is to make srcset implementation as simple as possible in your template code. It does not handle images rendered in CKEditor or similar fields. For an introduction to srcset and sizes, please read this Mozilla article about responsive images. Pageimage::srcset() // The property, which uses the set rules in the module configuration $srcset = $image->srcset; // A method call, using a set rules string // Delimiting with a newline (\n) would also work, but not as readable $srcset = $image->srcset("320, 480, 640x480 768w, 1240, 2048 2x"); // The same as above but using an indexed/sequential array $srcset = $image->srcset([ "320", "480", "640x480 768w", "1240", "2048 2x", ]); // The same as above but using an associative array // No rule checking is performed $srcset = $image->srcset([ "320w" => [320], "480w" => [480], "768w" => [640, 480], "1240w" => [1240], "2x" => [2048], ]); // Use the default set rules with portrait images generated for mobile/tablet devices $srcset = $image->srcset(true); // Return the srcset using all arguments $srcset = $image->srcset("320, 480, 640x480 768w, 1240, 2048 2x", [ "portrait" => "320, 640", ]); // The set rules above are a demonstration, not a recommendation! Image variations are only created for set rules which require a smaller image than the Pageimage itself. On large sites this may still result in a lot of images being generated. If you have limited storage, please use this module wisely. Portrait Mode In many situations, the ratio of the image does not need to change at different screen sizes. However, images that cover the entire viewport are an exception to this and are often the ones that benefit most from srcset implementation. The main problem with cover images is that they need to display landscape on desktop devices and portrait when this orientation is used on mobile and tablet devices. You can automatically generate portrait images by enabling portrait mode. It is recommended that you use this in combination with Pageimage::focus() so that the portrait variations retain the correct subject. The generated variations are HiDPI/Retina versions. Their height is determined by the portrait ratio (e.g. 9:16). Variations are always generated, regardless of whether the original image is smaller. Upscaling is disabled though, so you may find that some variations are actually smaller than they say they are in their filename. The sizes attribute should be used when portrait mode is enabled. Pageimage::sizes will return (orientation: portrait) and (max-width: {maxWidth}px) 50vw by default, which handles the use of these images for retina devices. The maximum width used in this rule is the largest set width. Pageimage::sizes() There is no option to configure default sizes because in most cases 100vw is all you need, and you do not need to output this anyway as it is inferred when using the srcset attribute. You can use the method for custom sizes though: // The property $sizes = $image->sizes; // Returns 100vw in most cases // Returns '(orientation: portrait) and (max-width: {maxWidth}px)50vw' if portrait mode enabled // A method call, using a mixture of integer widths and media query rules // Integer widths are treated as a min-width media query rule $sizes = $image->sizes([ 480 => 50, "(orientation: portrait) and (max-width: 640px)" => 100, 960 => 25, ]); // (min-width: 480px) 50vw, (orientation: portrait) and (max-width: 640px) 100vw, (min-width: 960px) 25vw // Determine widths by UIkit 'child-width' classes $sizes = $image->sizes([ "uk-child-width-1-2@s", "uk-child-width-1-3@l", ]); // (min-width: 640px) 50vw, (min-width: 1200px) 33.33vw // Determine widths by UIkit 'width' classes $sizes = $image->sizes([ "uk-width-1-2@m", "uk-width-1-3@xl", ]); // (min-width: 960px) 50vw, (min-width: 1600px) 33.33vw // Return the portrait size rule $sizes = $image->sizes(true); // (orientation: portrait) and (max-width: {maxWidth}px) 50vw // The arguments above are a demonstration, not a recommendation! Pageimage::render() This module extends the options available to this method with: srcset: When the module is installed, this will always be added, unless set to false. Any values in the formats described above can be passed. sizes: Only used if specified. Any values in the formats described above can be passed. uk-img: If passed, as either true or as a valid uk-img value, then this attribute will be added. The srcset attribute will also become data-srcset. Please refer to the API Reference for more information about this method. // Render an image using the default set rules echo $image->render(); // <img src='image.jpg' alt='' srcset='{default set rules}'> // Render an image using custom set rules echo $image->render(["srcset" => "480, 1240x640"]); // <img src='image.jpg' alt='' srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w'> // Render an image using custom set rules and sizes // Also use the `markup` argument echo $image->render("<img class='image' src='{url}' alt='Image'>", [ "srcset" => "480, 1240", "sizes" => [1240 => 50], ]); // <img class='image' src='image.jpg' alt='Image' srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w' sizes='(min-width: 1240px) 50vw'> // Render an image using custom set rules and sizes // Enable uk-img echo $image->render([ "srcset" => "480, 1240", "sizes" => ["uk-child-width-1-2@m"], "uk-img" => true, ]); // <img src='image.jpg' alt='' data-uk-img data-srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w' sizes='(min-width: 960px) 50vw'> // Render an image using portrait mode // Default rule sets used: 320, 640, 768, 1024, 1366, 1600 // Portrait widths used: 320, 640, 768 // Original image is 1000px wide // Not possible to use portrait mode and custom sets or portrait widths in render() // Sizes attribute automatically added echo $image->render(["srcset" => true]); // <img src='image.jpg' alt='' srcset='image.320x569-srcset-hidpi.jpg 320w, image.640x1138-srcset-hidpi.jpg 640w, image.768x1365-srcset-hidpi.jpg 768w, image.jpg 1024w' sizes='(orientation: portrait) and (max-width: 768px) 50vw'> Configuration To configure this module, go to Modules > Configure > PageimageSrcset. Set Rules These are the default set rules that will be used when none are specified, e.g. when calling the property: $image->srcset. Each set rule should be entered on a new line, in the format {width}x{height} {inherentwidth}w|{resolution}x. Not all arguments are required - you will probably find that specifying the width is sufficient for most cases. Here's a few examples of valid set rules and the sets they generate: Set Rule Set Generated Arguments Used 320 image.320x0-srcset.jpg 320w {width} 480x540 image.480x540-srcset.jpg 480w {width}x{height} 640x480 768w image.640x480-srcset.jpg 768w {width}x{height} {inherentwidth}w 2048 2x image.2048x0-srcset.jpg 2x {width} {resolution}x How you configure your rules is dependent on the needs of the site you are developing; there are no prescriptive rules that will meet the needs of most situations. This article gives a good overview of some of the things to consider. When you save your rules, a preview of the sets generated and an equivalent method call will be displayed to the right. Invalid rules will not be used, and you will be notified of this. Portrait Mode Set Widths A comma limited list of widths to create HiDPI/Retina portrait variations for. Crop Ratio The portrait ratio that should be used to crop the image. The default of 9:16 should be fine for most circumstances as this is the standard portrait ratio of most devices. However, you can specify something different if you want. If you add a landscape ratio, it will be switched to portrait when used. Any crops in the set rules ({width}x{height}) are ignored for portrait mode variations as this ratio is used instead. UIkit Widths If your website theme uses UIkit, you can pass an array of UIkit width classes to Pageimage::sizes to be converted to sizes. The values stored here are used to do this. If you have customised the breakpoints on your theme, you should also customise them here. Please note that only 1- widths are evaluated by Pageimage::sizes, e.g. uk-width-2-3 will not work. Remove Variations If checked, the image variations generated by this module are cleared on Submit. On large sites, this may take a while. It makes sense to run this after you have made changes to the set rules. Image Suffix You will see this field when Remove Variations is checked. The value is appended to the name of the images generated by this module and is used to identify variations. You should not encounter any issues with the default suffix, but if you find that it conflicts with any other functionality on your site, you can set a custom suffix instead. Debug Mode When this is enabled, a range of information is logged to pageimage-srcset. PageimageSrcsetDebug.js is also added to the <head> of your HTML pages. This will console.log a range of information about the images and nodes using srcset on your page after a window.onresize event is triggered. This can assist you in debugging your implementation. The browser will always use the highest resolution image it has loaded or has cached. You may need to disable browser caching to determine whether your set rules are working, and it makes sense to work from a small screen size and up. If you do it the other way, the browser is going to continue to use the higher resolution image it loaded first. UIkit Features This module implements some additional features that are tailored towards UIkit being used as the front-end theme framework, but this is not required to use the module. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. ProcessWire >= 3.0.123 is required to use this module.

Wondering how to get that A+ rating on Mozilla Observatory? Now you can with ⭐⭐⭐MarkupContentSecurityPolicy⭐⭐⭐ Of course, MarkupContentSecurityPolicy does not guarantee an A+ rating, but it does help you implement a Content Security Policy for your ProcessWire website. Markup Content Security Policy Configure and implement a Content Security Policy for all front-end HTML pages. This module should only be used in production once it has been fully tested in development. Implementing a Content Security Policy on a site without testing will almost certainly break something! Overview Website Security Auditing Tools such as Mozilla Observatory will only return a high score if a Content Security Policy is implemented. It is therefore desirable to implement one. A common way of adding the Content-Security-Policy header would be to add it to the .htaccess file in the site's root directory. However, this means the policy would also cover the ProcessWire admin, and this limits the level of security policy you can add. The solution is to use the <meta> element to configure a policy, for example: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">. MarkupContentSecurityPolicy places this element with your configured policy at the beginning of the <head> element on each HTML page of your site. There are some limitations to using the <meta> element: Not all directives are allowed. These include frame-ancestors, report-uri, and sandbox. The Content-Security-Policy-Report-Only header is not supported, so is not available for use by this module. Configuration To configure this module, go to Modules > Configure > MarkupContentSecurityPolicy. Directives The most commonly used directives are listed, with a field for each. The placeholder values given are examples, not suggestions, but they may provide a useful starting point. You will almost certainly need to use 'unsafe-inline' in the style-src directive as this is required by some modules (e.g. TextformatterVideoEmbed) or frameworks such as UIkit. Should you wish to add any other directives not listed, you can do so by adding them in Any other directives. Please refer to these links for more information on how to configure your policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://scotthelme.co.uk/content-security-policy-an-introduction/ https://developers.google.com/web/fundamentals/security/csp/ Violation Reporting Because the report-uri directive is not available, when Violation Reporting is enabled a script is added to the <head>which listens for a SecurityPolicyViolationEvent. This script is based on https://developer.mozilla.org/en-US/docs/Web/API/SecurityPolicyViolationEvent and POSTs the generated report to ?csp-violations=1. The module then logs the violation report to csp-violations. Unfortunately, most of the violations that are reported are false positives, and not actual attempts to violate the policy. These are most likely from browser extensions and are not easy to determine and filter. For this reason, there is no option for the report to be emailed when a policy is violated. Instead, you can specify an endpoint for the report to be sent to. This allows you to handle additional reporting in a way that meets your needs. For example, you may want to log all reports in a central location and send out an email once a day to an administrator notifying them of all sites with violations since the last email. Retrieving the Report To retrieve the report at your endpoint, the following can be used: $report = file_get_contents("php://input"); if(!empty($report)) { $report = json_decode($report, 1); if(isset($report) && is_array($report) && isset($report["documentURI"])) { // Do something } } Debug Mode When this is enabled, a range of information is logged to markup-content-security-policy. This is probably most useful when debugging a reporting endpoint. Additional .htaccess Rules To get an A+ score on Mozilla Observatory, besides using HTTPS and enabling the HSTS header, you can also place the following prior to ProcessWire's htaccess directives: Header set Content-Security-Policy "frame-ancestors 'self'" Header set Referrer-Policy "no-referrer-when-downgrade" Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. ProcessWire >= 3.0.123 is required to use this module.

Core version 3.0.137 on the dev branch adds the ability to hook multiple methods at once, in a single call. This post details how it works and provides a useful example of how you might put it to use in your development environment. This version also refactors and improves upon several core classes— https://processwire.com/blog/posts/pw-3.0.137/

If you try to create some sort of page-builder featureset this way, than this is not what you are looking for as fields and templates are for developers (and most of the time they are the only superusers in the system...). People usually use RepeaterMatrix or sometimes the PageTree to implement page-building functionalities. There are plenty of examples in the forum demonstrating these. Some devs used custom coding too, again, they showcased their work in the forums.

OK, I've found it out myself now. The trick is to make the field accessible by API. Then you can simply write something like: function getRestrictedProperty($page, $fieldname, $user) { $field = $page->getFields()->get($fieldname); if ($field == null) return ''; return $field->viewable($page, $user) ? $page->get($fieldname) : ''; }

I use an IDE and found it stressful to have to work-around deploying config.php This is how I found your thread. Thank you! I integrated your solution into my own workflow and came up with this to share back here: /site/config.php (like @bernhard except last line) // include config file from outside of the repo $client = 'config-' . end(explode('/',__FILE__, -2)); include("../$client.php"); The PHP end() function and the minus 2 in the explode(), always gets the URI domain base. (As long as PW keeps it there.) Since my usual deployment flow is from ABC.dev -> test.mybox.com/ABC -> ABC.com ...in my root folder, safely out of reach (like @bernhard's concept), I then create 3 files each containing config deployment differences. ../config-ABC.dev.php and ../config-ABC.php and ../config-ABC.com.php For those also using PHPStorm, since these files are located out of project, I would add them in Favorites. (And add it's root folders in Deployment Mappings). I can then easily make use of IDE features like "Compare Two Files", "Sync with Deployed to", etc. Removing doubts about what config property I may have missed across the board. No more stress.

What you're seeing there is just what happens between browser and server, i.e. spaces getting replaced by %20. If you're echoing the value, it won't get executed as PHP code (you'd have to call eval or something similar to get that effect), but it could still allow HTML or JavaScript through – which is probably also something you don't want to allow. For an example, see what happens if you set the key value as <script>alert("hi")</script> instead. The general rule of thumb is to always sanitize user input ? That being said, if you're certain that you're only reading the GET variable and comparing it to some pre-defined value, and you'll never store or output it as-is, then there's no real harm in not sanitizing it. As you've proven yourself, it won't get evaluated as PHP code.

wireMail()->attachment() needs an absolute path for every (disk) file it should attach to a message. UPD: oh, i've missed last sentense, U know about absolute path already. You must save image from POST and then Send it, using absolute path. UPD2: VEEERYYY bad example. You need to check uploaded file for type, size etc first. But it should work ? <?php if($input->post('submit')) { $uploaddir = "/upload/"; $uploadfile = $uploaddir . basename($_FILES['userfile']['name']); if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) { $mail = wireMail(); $mail->to("some@one.com"); $mail->from = "me@me.io"; $mail->subject("FILE"); $mail->body("TAKE THIS!"); $mail->attachment($uploadfile); $numSent = $mail->send(); } else { echo "wtf?!"; } } ?> <form enctype="multipart/form-data" action="/" method="POST"> <input name="userfile" type="file" /> <input name="submit" type="submit" value="Send" /> </form>

?

hmm, the iframe looks in my PW install like this: <iframe class="pw-panel-content" src="../setup/manual/?modal=panel&amp;pw_panel=1"></iframe> If you work with JS, you could also check for body class "modal".

Tracy debugger has many tools to help in development. One of them is the user-switcher, which exactly does what you asked for! There are also other modules out there that provide this user switcher functionality. If I do remember right, @Pete has build and released one. (search in the modules directory for it) My ALIF module once came up with this, but in the meantime I have stripped it out, as there are now other solutions for this, so that I don't have to maintain to much functionality with my modules. :)

You will need: ProcessWire (of course) ProcessWire ProCache ProcessWire Modules as you like and need Netlify Account (in my case, you can use any other hosting or Github pages) Git Account (Gihub, Gitlab, Bitbucket) ScreamingFrog (free version should fit most needs) Things to keep in mind FormBuilder will not work (out of the box) 40x/50x must be defined separately Redirects must be defined separately Module-based functionality will not work GDPR/Opt-in/Cookie consent must be added differently Avoid using core/module files (UIKIT, jQuery, CSS, etc.) Where to save files and how to address them Most content and design related files can be saved in ProcessWire itself. Logos, favicon, trust icons and whatsoever. Some files can't be stored in ProcessWire - or shouldn't be stored in it - fonts and sitemaps (XML) in my case. While developing the overall site always use relative paths and URLs. Fonts and other assets need to be addressed by their web-root-based path (/site/templates/myassets/font.ttf and so on). Internal linking should be relative as well. Otherwise you have to change those link URLs manually which is PITA. Which files to copy and where you find them As we use ProcessWire we want and should use everything we can to make our webdev life easier here. Let ProcessWire and some modules do the work while harvesting the results for our benefits. While ProCache takes care of generating minified CSS and JS, SEO Maestro generates a nice and handy sitemap.xml. Depending of your installed modules you want to (at least) double check the output and results in your static site. As already mentioned FormBuilder and Simple Contact Form will not work, 404 management and redirects by the awesome Jumplinks modules will not work, too. Instead you have to create your very own .htaccess file with all redirects and error documents. Other modules like MenuBuilder, SEO Maestro and some other modules do a pretty good job even in your static site as their benefits result in already rendered HTML/pages. Autolinks, Automatically link page titles and Share buttons are some modules that will work as well. While it didn't work for me it may work for you - the Cookie Management Banner module. I had some issues and decided to install and use Cookie Consent manually. The Workflow First of all build your site. Make it perfect. Do whatever you or the client wants or needs. Whenever possible look into your rendered HTML and cached pages. Take a closer look at all the URLs and paths. It's already a good idea to run ScreamingFrog and find out if there are any files missing, links broken or pages missing. When everything is done, clear all cached files, all minified JS and CSS. Start a ScreamingFrog session and let it run. It will visit each and every page on your site it can find. Hidden pages, orphaned pages and of course drafts and pages behind JS-links will not be found and therefore cached by ProCache. Look into /site/assets/ProCache-XXX/ and /site/assets/pwpc/ now and double check that there are your pages and JS/CSS files. You will need those afterwards. If everything is fine you have to copy things around now. The Setup - folders and structure In my case the easiest way to go was setting up two local sites - one with ProcessWire and another one with the static files, assets and other things I needed. In the examples below only relevant parts are listed. project.pw.test (ProcessWire) /sitemap.xml (Generated by SEO Maestro) /site/assets/files/ (copy the whole path) /site/assets/pwpc/ (copy the whole path) /site/assets/ProCache-XXX/* (copy only the content of this folder - all files and folders) /site/templates/myassets/ (copy the whole path) project.sv.test (Static version) .htaccess (for redirects and 40x/50x error pages) 40x.html 50x.html /sitemap.xml /site/assets/files/ /site/assets/pwpc/ /site/templates/myassets/ all files and folders from /site/assets/ProCache-XXX/ As you can see there are only a few things to copy. When you're done with copying these files to the static version of your project, open it up in your browser. Check for missing files and test it. Let ScreamingFrog do the most work and check for any kinds of errors. Fix them in your ProcessWire-site and copy and test again. Check your 404s, your redirects and everything else you would normaly test. Create checkafterupdate.txt and write down whatever went wrong in your first try. This will be a great checklist later. The Final Step As everything is copied now and at its correct place you can upload it to your host. In my case the static version is a private git repository on github.com. I can commit and push my changes there and Netlify takes care of publishing the new version - most of the time within seconds. The benefit of using git - compared to S/FTP - you always have some kind of control if something brakes and you have to revert and check changes. In my case it's Netlify but you can use Github pages or any other hosting solution you want/the client pays for. Be careful with GDPR-related things as DPAs. You have to have them in most cases - Netlify did a great job here and I found everything I needed, while Github disqualified itself back then due to missing documents and kind of a sluggish support. Questions? Ask.

In addition to what @teppo said above, some sample snippets to get you sarted:

Actually the API provides access to the hashed password. If this password hash (the one you use for your secure URLs) needs to remain constant, I guess that's as good approach as any – mash some non-public variables together, generate a hash, and then check if the user has provided the correct hash. If you're looking for a ready-made solution I'm not aware of one, but on the other hand this sounds like something you could put together in a few lines of code, so not really a massive problem. The specific implementation depends on how your site is built, but technically you just need to add a bit of code somewhere before any markup is rendered – check a GET param from $input->get->token_var_name, and then compare that to a correct token (or one stored in user details – more about that in the list below). I would probably use URL segments here, so that first segment contains the username and second one the token, though. If there's a match, do something (display page content), otherwise throw a Wire404Exception (preferable over displaying a clear message such as "wrong token"; you don't want third parties to know even if they got the username right.) Some additional steps to consider, mainly for security reasons: Instead of calculating the token on the go, you could generate it automatically for every user, and store it in a custom field added to the user template. This way you can also include random data in the original hash, which means that it cannot, under any circumstances, be used to uncover (hashed) passwords or any other type of sensitive data. Note: this would still mean that the token is stored in the database as-is, which would become a problem in case this information ever leaks. Technically the safest thing to do might be to send the private token to the user, and never store it as-is, but rather convert it to a hash using a salt and then store those locally ? Add some sort of brute force protection to the page, i.e. after a few incorrect attempts block the IP for a while. Preferably refresh (recreate) tokens after a set amount of time. This may not be particularly important, but personally I believe it's a good practice in these sorts of situations. Provide a way for users to change (reset) this key, in case there's a chance that someone else has gained access to it. Preferably this new key should also be randomly generated, so that users cannot manually type in a weak key. Use username or some other value in the URL itself, so that keys become much harder to guess (via brute force attack) – but also make sure that third parties can't use these URLs to collect a list of existing usernames ? ... although the security level of course depends on the type of information you're providing via this calendar. If it's not particularly sensitive data, then it won't be such a big deal, but if there's a chance that it may, for an example, contain personal data, then definitely take every possible precaution.

You could take a look at https://modules.processwire.com/modules/access-by-query-string/. Maybe it'll do exactly what you need, or you could take it as a starting point and tweak it to your needs.

On-demand mirroring of remote web server files to your dev environment ???

Just in case anyone else is interested, this does the job nicely! $this->addHookBefore('AdminBar::getItems', function($event) { $args = $event->arguments[0]; $args['strings']['browse'] = 'View'; $event->setArgument(0, $args); });

Thanks, @adrian. I've been using this module for a long time, and it has actually been quite fun to work on it ? A profile edit button seems like a good idea. That was on my list for a while actually, but I wanted to get 2.x out sooner rather than later, so had to leave that for a later release ? I think we'll also need a "select enabled links/features" option to avoid too much clutter. On many (most) of the sites I've built this feature, for an example, profile edit feature wouldn't have been particularly useful – users often edit their profiles really, really rarely – so I'd like to leave it to superusers to figure out which features are necessary. (Could also make the feature selection configurable per user, if there's demand for such a feature.) Restricting editable pages to ones the user has created seems to me like a relatively specific need – at least I haven't personally come across a project where this would've been particularly useful. As such, my initial view is that this might be best implemented as a per-site customisation. Unless, of course, I'm wrong and it's actually a commonly needed feature, in which case it may make sense to add a setting for it ? Note that one key point about the hooks I've added is that it's now quite easy to customise what is displayed in the Admin Bar, and how. One example of this is what I've done with the "Uikit" theme, where I've added icons to existing items, and also the PW logo/mark as a new item. If you hook into AdminBar::getItems, you can easily modify the list, and – for an example – only show the edit link under specific circumstances. (And if this is a feature you require often, you can always bundle this, and any other modifications, into a separate module.) By the way, I'm assuming that this would actually be just about displaying the edit link – not modifying permissions? Modifying permissions would, in my opinion, definitely belong to another module. As far as I can tell, this item has been "Browse" since the beginning – at least for the past 8 years or so, according to GitHub ? I'm slightly hesitant to change what I consider established terminology. Also, I don't personally see the problem: technically what this item being active means is that you're currently browsing the site. Kind of like "browse mode" vs. "edit mode". When you're in admin and want to view a specific page, "view" is indeed better word, but in this context I actually prefer "browse". Again it's quite simple to modify this with a hook, of course, but I think I'd rather stick with current terminology for the default state.

Hi, ProcessWire has excellent functionality when it comes to solving URLs in another language. For example, suppose I have the following addresses: domain.com/en/career and domain/fr/carriere. If a user types domain.com/carriere, ProcessWire will be able to deduce that the correct address is domain.com/fr/carriere. On my machine, I can switch between Apache and nginx and the expected behavior works very well with Apache, but not with nginx which will systematically send me back /en/career. I tried to study the ProcessWire code, including the getPage() function and the LanguageSupportPageNames module, but I can't find where it fails. All I perceive is that the user's language does not switch, it remains in English. I would like to point out that otherwise, ProcessWire works smoothly with nginx.

AdminBar 2.0.1 released: Plenty of updates behind the scenes. So far "end user" functionality remains largely the same, though. New options for hooking – decent support for modifying generated output and adding all-new links and other features programmatically. Extended theming support: the module now comes with three built-in themes ("original", "tires" per the theme submitted earlier by @tires, and "uikit"). Uikit is an adapted version of the top bar in admin, and it's now the default theme for the module. Each theme may include its own settings (Uikit, for an example, allows displaying/hiding some or all of its icons and the ProcessWire mark). Custom theme support is still there, but requires a few modifications: custom theme needs to be selected via module config screen, you need to provide a directory where theme files live, and this directory has to contain (at least) a theme.css file (but optionally also theme.js for custom JS, theme.php for hooks, and config.php for custom module config settings). Oh, and the module is installable via Composer now – just run "composer require teppokoivula/admin-bar" in your sites root directory, or the /site/ directory. New requirements for 2.0.1 are ProcessWire >= 3.0.112 and PHP >= 7.1.0. For earlier version of ProcessWire or PHP, use release 1.1.5 (this version won't be updated anymore, but should work in ancient version of PW and PHP). Below is a screenshot of the "Uikit" theme in action on the Wireframe website. In this case I've disabled the icons from the left side of the Admin Bar – by default each action there would have its own icon as well.

I've now came up with this setup which works really well for me: /site/config.php (can safely be committed to GIT) <?php if(!defined("PROCESSWIRE")) die(); /*** SITE CONFIG *************************************************************************/ $config->debug = false; $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; /*** INSTALLER CONFIG ********************************************************************/ $config->dbHost = 'localhost'; $config->dbPort = '3306'; $config->chmodDir = '0755'; // permission for directories created by ProcessWire $config->chmodFile = '0644'; // permission for files created by ProcessWire $config->timezone = 'Europe/Vienna'; // include config file from outside of the repo include('../config.php'); ../config.php DEV (one file for all laragon hosted sites on my local machine) <?php $config->dbUser = 'root'; $config->dbPass = ''; $config->httpHosts = [$_SERVER['HTTP_HOST']]; $config->debug = true; switch($_SERVER['SERVER_NAME']) { case 'www.XXX.test': $config->dbName = 'XXX'; $config->userAuthSalt = 'XXX'; $config->installed = 123456789; break; [...] } ../config.php LIVE (one file for each vhost) <?php $config->dbName = 'XXX'; $config->dbUser = 'XXX'; $config->dbPass = 'XXX'; $config->httpHosts = ['www.XXX.com']; $config->userAuthSalt = 'XXX'; $config->installed = 123456789; setlocale(LC_ALL,'en_US.UTF-8'); Thx for that ideas @arjen and @jens.martsch!

SiNNuT: what I was talking about back there was probably more like HTML prototyping than just plain wireframing, though in my humble opinion HTML prototypes are rather straightforward evolutionary step of HTML wireframes -- or "HTML wireframes on steroids." Basics and reasoning behind these kind of techniques are discussed (for an example) in this Webdesigner Depot article, this Handcrafted post about how 37signals work on their designs and in this rather old but still valid blog post by 37signals about why they like to "skip Photoshop." I'm still hoping more people in our industry would take these techniques even further though. What I'm currently most interested in (and experimenting with) is taking HTML wireframes to what I see as "the next level" by adding not only bones (wireframes / structure) but also as much meat (functionality) as possible before drawing / having someone else draw the skin (graphics) on top of it all. Yeah, I really suck at metaphors. Sorry for that. I'm actually working on a project right now that I'd love to see as close to being completed as possible before adding any distracting eye candy, though that's definitely not an easy task to achieve; lots of people still claim (I say claim because I'm not very satisfied with this answer) that they cannot really "get" the whole thing without seeing layouts. In my opinion keeping things as bare and clean as possible forces everyone to concentrate on what really matters: usability and user experience. Long story short: what you're doing is probably very close to what I'm talking about here and I'm happy to hear that you've already implemented a method like this. I'm not a big fan of front-end frameworks myself and definitely not an expert on that subject, but if I've understood properly how they work (and why they exist in the first place) this is exactly what they're good at