Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 08/20/2019 in all areas

  1. 33 points
    Hope you guys are having a great week. I'll keep this week's update short since everything I'm working on is in-progress rather than ready to post. But I can tell you about a few things you'll likely see in next week's post: First is that I've got multi-page/paginated form support just about ready to release in FormBuilder. What this means is that you can take forms (especially long forms) and break them up into multiple paginations. This makes for multi-part forms that are more digestible and easy to use for users. The end of each pagination has "Next" and "Prev" buttons for navigation between them. FormBuilder validates each pagination independently as it is submitted so that any errors are taken care of as the user proceeds rather than all at the end. And these are true paginated forms, rather than a JS manipulation of existing forms. More on this next week. I'm also working here on a new Inputfield module called InputfieldToggle. It's an alternative to the core InputfieldCheckbox and the intention here is to make it a selectable alternative for FieldtypeCheckbox fields. Unlike InputfieldCheckbox, it is presented as two radio buttons for "on" and "off" states. (It's also possible to have a "no selection" state distinct from the "no" state, where supported). It comes predefined with several toggle types (Yes/No, On/Off, True/False, Enabled/Disabled), along with the ability to specify your own (multi-language too of course). Like a checkbox, because it is a toggle, it holds a value of either true (1) or false (0). There is also null for no selection. While this is a relatively simple Inputfield, it answers a common need (at least in my experience) and often can provide a better experience than a standard checkbox, depending on the input need. Not to mention, it's a lot more efficient than using an Options or Page field to accomplish the same thing. In addition to sites and apps running in ProcessWire, I think this particular Inputfield has a lot of potential use in the core and its administrative forms, so I might include it in the core, though not yet certain. I'm already using it quite a bit in forms I'm developing for clients in FormBuilder, where in many cases I find it a better fit than InputfieldCheckbox. Lastly, there are some nice UI enhancements just about ready for manipulating column widths of fields in ProcessWire. It makes it a much simpler and quicker job than it currently is, so I'll have more on that next week too. Have a great weekend!
  2. 27 points
    RockFinder2 is the successor to RockFinder v1 and while the changes might not look that big on first sight they are quite huge behind the scenes. In RockFinder1 I used some kind of custom query builder because I didn't know of PW's built in one (see later). RockFinder2 will exist besides RockFinder1 because I have several projects relying on RockFinder1, but for any future projects you should definitely use RockFinder2. This is how RF2 builds the SQL query: So this is really easy to grasp, easy to maintain and easy to extend (like aggregations, selecting distinct values etc). RockFinder2 also comes with a custom UI where you can manage your Finders: You can then easily access those finders by name: This is a soft alpha release. The module can be downloaded from https://github.com/BernhardBaumrock/RockFinder2 and the docs are at the moment a mess. I'll work on several useful examples in the next weeks that showcase all the features.
  3. 27 points
    This week we’ll take a look at a new version of FormBuilder that's on the way (with a screencast), as well as the latest version of the core: ProcessWire 3.0.140— https://processwire.com/blog/posts/pw-3.0.140-and-formbuilder-v40/
  4. 23 points
    Hi guys, today I want to share a little preview of my newly developed ModulesManager 2 module which is currently in beta. ModulesManager 2 provides an easy to use interface to download, update, install, uninstall and configure modules. It is meant to provide an optimized alternative to the ProcessModule dashboard. Maybe @ryan agrees to merge it to the core at some point when it is finished and polished. Features: Live-Search (aka find as you type) for categories Live-Search (aka find as you type) for module names Modern UIKit design Quick uninstall of a module Caches the module list from modules.processwire.com directory locally. There's a refresh button to get actual data. Preview video (with voiceover) Why a new module manager? Some people including myself think that the actual module installation in ProcessWire could be improved in many places. Make it easy for everybody! Lower the barrier for new users, and make it easier for existing users to find an install modules. That is one thing, that many other frameworks/CMS's have by default. Like ModX, WordPress or PrestaShop. What are the disadvantages of the actual core module interface? Installation of a module is not very user-friendly: You have to be aware where to get new modules, search for a module, copy or remember the module name or URL, go back to your ProcessWire installation, paste the module name , or URL, click on "get module info" and finally install the module It only displays installed modules, not the ones that are available in the modules directory, so it makes discovering modules hard. Uninstalling a module requires you to go to the module detail page, click a checkbox and then submit the change. After that you have to go back to the module overview page. It displays only limited information about the module History Back in 2012 Soma came up with ModuleManager, a module which displays modules as a table and provides functionality to download, update, install and configure modules (same as this module does). Sadly this module isn't maintained anymore (but it is still working) Then in 2019 Adrian came up with the idea of autocompleting the module name and Robin S developed the AutocompleteModuleClassName module which does this. This approachis a nice addition for devs who know which module they are looking for. But for all others we need a browsable experience, which provides more info than just the name. This was the perfect time for me to chime in, as I thought that module management is very cumbersome at its current state. A quick proof of concept / prototype was quickly developed. But then development slowed down, as I had to get more experience with vue.js first. Even as I was more experienced I stumbled into some problems that were to advanced for me to tackle. So I hired someone to help (yes, I even paid money for developing this module) TODO Install multiple modules at once like it is done in [ProcessModuleToolkit](https://github.com/adrianbj/ProcessModuleToolkit) add filter by installed/not installed / updateable / recommended Allow "search for module" to search in the description also, so a module can be found by its purpose and not only by its name Integrate the Readme or changelog of a module as it is done in [ModuleReleaseNotes](https://processwire.com/talk/topic/17767-module-release-notes/) This would have the following benefits: Make discovery of a module's changes prior to an upgrade a trivial task. Make breaking changes very obvious. Make reading of a module's support documentation post-install a trivial task. Make module authors start to think about how they can improve the change discovery process for their modules. Make sure the display of information from the module support files/commit messages doesn't introduce a vulnerability. I need your feedback This module is in development right now, and I am happy to discuss with you and get some feedback. I will publish it on github as soon as I have the time, so you can download it and analyze the code, and even provide pull requests. What do you like? What is missing? What could make the process even easier? Wink at @bernhard @adrian @Pete
  5. 23 points
    This latest version of ProcessWire on the dev branch adds a new Inputfield module called “Toggle” that is an alternative to the existing Checkbox Inputfield. It also adds a nicer way to make column width adjustments to your fields when editing a template. This post covers all the details with screenshots and a short video: https://processwire.com/blog/posts/pw-3.0.139/
  6. 20 points
    In this tutorial I want to write about handling special cases and change requests by clients gracefully without introducing code bloat or degrading code quality and maintainability. I'll use a site's navigation menu as an example, as it's relatable and pretty much every site has one. I'll give some examples of real situations and change requests I encountered during projects, and describe multiple approaches to handling them. However, this post is also about the general mindset I find useful for ProcessWire development, which is more about how to handle special cases and still keep your code clean by making the special case a normal one. The problem: Special cases everywhere Since ProcessWire has a hierarchical page tree by default, as a developer you'll usually write a function or loop that iterates over all children of the homepage and displays a list of titles with links. If the site is a bit more complex, maybe you additionally loop over all grandchildren and display those in drop-down menus as well, or you even use a recursive function to iterate over an arbitrary amount of nested child pages. Something like this: function buildRecursiveMenu(Page $root): string { $markup = ['<ul class="navigation">']; foreach ($root->children() as $child) { $link = '<a class="navigation__link" href="' . $child->url() . '">' . $child->title . '</a>'; $children = $child->hasChildren() ? buildRecursiveMenu($child) : ''; $markup[] = "<li class="navigation__item">{$link}{$children}</li>"; } $markup[] = '</ul>'; return implode(PHP_EOL, $markup); } But then the requests for special cases come rolling in. For example, those are some of the requests I've gotten from clients on my projects (by the way, I'm not saying the clients were wrong or unreasonable in any of those cases - it's simply something I needed to handle in a sensible way): The homepage has the company's name as it's title, but the menu link in the navigation should just say "Home". The first page in a drop-down menu should be the top-level page containing the drop-down menu. This was requested because the first click on the top-level item opens the sub-navigation instead of navigating to that page (espcially on touch devices, such as iPads, where you don't have a hover state!), so some visitors might not realize it's a page itself. Some top-level pages should be displayed in a drop-down menu of another top-level page, but the position in the page tree can't change because of the template family settings. The menu needs to contain some special links to external URLs. For one especially long drop-down menu, the items should be sorted into categories with subheadings based on a taxonomy field. In general, my solutions to those requests fall into three categories, which I'll try to elaborate on, including their respective benefits and downsides: Checking for the special case / condition in the code and changing the output accordingly (usually with hard-coded values). Separating the navigation menu from the page tree completely and building a custom solution. Utilizing the Content Management Framework by adding fields, templates and pages that represent special states or settings. Handling it in the code This is the simplest solution, and often the first thing that comes to mind. For example, the first request (listing the homepage as "Home" instead of it's title in the navigation) can be solved by simply checking the template or ID of the current page inside the menu builder function, and changing the output accordingly: // ... $title = $child->template->name === 'home' ? 'Home' : $child->title; $link = '<a class="navigation__link" href="' . $child->url() . '">' . $title . '</a>'; // ... This is definitely the fastest solution. However, there are multiple downsides. Most notably, it's harder to maintain, as each of those special cases increases the complexity of the menu builder function, and makes it harder to change. As you add more special conditions, it becomes exponentially harder to keep changing it. This is the breeding ground for bugs. And it's much harder to read, so it takes longer for another developer to pick up where you left (or, as is often cited, for yourself in six months). Also, now we have a hard-coded value inside the template, that only someone with access to and knowledge of the template files can change. If the client want's the link to say "Homepage" instead of "Home" at some point, they won't be able to change it without the developer. Also, each special case that is hidden in the code makes it harder for the client to understand what's going on in terms of template logic - thus increasing your workload in editorial support. That said, there are definitely some times where I would go with this approach. Specifically: For smaller projects that you know won't need to scale or be maintained long-term. If you are the only developer, and/or only developers will edit the site, with no "non-technical" folk involved. For rapid prototyping ("We'll change it later") Building a custom solution My initial assumption was that the main navigation is generated based on the page tree inside ProcessWire. But of course this isn't set in stone. You can just as easily forgo using the page tree hierarchy at all, and instead build a custom menu system. For example, you could add a nested repeater where you can add pages or links on a general settings page, and generate the menu based on that. There are also modules for this approach, such as the Menu Builder by @kongondo. This approach is not the quickest, but gives the most power to the editors of your site. They have full control over which pages to show and where. However, with great power comes great responsibility, as now each change to the menu must be performed manually. For example, when a new page is added, it won't be visible in the menu automatically. This is very likely to create a disconnect between the page tree and the menu (which may be what you want, after all). You may get ghost pages that are not accessible from the homepage at all, or the client may forgot to unpublish pages they don't want to have any more after they've removed them from the menu. I would only go with this approach if there are so many special cases that there hardly is a "normal case". However, even then it might not be the best solution. The direct relationship between the page tree, the menu structure and page paths are one of the strongest features of ProcessWire in my opinion. If many pages need to be placed in special locations without much structure in regards to what templates go where, maybe you only need to loosen up the template family settings. I have built one site without any template family restrictions at all - any page of any template can go anywhere. It's definitely a different mindset, but in this case it worked well, because it allowed the client to build custom sections with different page types grouped together. It's a trade-off, as it is so often, between flexibility and workload. Weigh those options carefully before you choose this solution! Utilizing the CMF This is the middle ground between the two options above. Instead of building a completely custom solution, you keep with the basic idea of generating a hierarchical menu based on the page tree, but add fields and templates that allow the editor to adjust how and where individual pages are displayed, or to add custom content to the menu. of course, you will still write some additional code, but instead of having hard-coded values or conditions in the template, you expose those to the client, thereby making the special case one of the normal cases. The resulting code is often more resilient to changing requirements, as it can not one handle that specific case that the client requested, but also every future change request of the same type. The key is to add fields that enable the client to overwrite the default behaviour, while still having sensible defaults that don't require special attention from the editor in most cases. I'll give some more examples for this one, as I think it's usually the best option. Example 1: Menu display options This is probably the first thing you thought of for the very first change request I mentioned (displaying the homepage with a different title). Instead of hard-coding the title "Home" in the template, you add a field menu_title that will overwrite the normal title, if set. This is definitely cleaner than the hard-coded value, since it allows the client to overwrite the title of any page in the menu. I'll only say this much in terms of downsides: Maybe the menu title isn't really what the client wanted - instead, perhaps they feel limited because the title is also displayed as the headline (h1) of the page. In this case, the sensible solution would be an additional headline field that will overwrite the h1, instead of the menu_title field. Which fields are really needed is an important consideration, because you don't want to end up with too many. If each page has fields for the title, a headline, a menu title and an SEO-title, it's much more complicated than it needs to be, and you will have a hard time explaining to the client what each field is used for. Another example in this category would be an option to "Hide this page in the menu". This could be accomplished by hiding the page using the inbuilt "hidden" status as well, but if it's hidden it won't show up in other listings as well, so separating the menu display from the hidden status might be a good idea if your site has lots of page listings. Example 2: "Menu link" template One solution that is quite flexible in allowing for custom links to pages or external URLs is creating a menu-link template that can be placed anywhere in the page tree. This templates can have fields for the menu title, target page and/or external target URL. This way, you can link to another top-level page or an external service inside a drop-down menu, by placing a Menu Link page at the appropriate position. This is also a clean solution, because the navigation menu will still reflect the page tree, making the custom links visible and easily editable by the editors. A minor downside is that those templates are non-semantical in the sense that they aren't pages with content of their own. You'll need to make sure not to display them in listings or in other places, as they aren't viewable. It may also require loosening up strict family rules - for example, allowing for Menu Link pages to be placed below the news index page, which normally can only hold news pages. Example 3: Drop-down menu override This one is a more radical solution to override drop-down menus. You add a repeater field to top-level pages, similar to the one mentioned as a custom solution, where you can add multiple links to internal pages or URLs. If the repeater is empty, the drop-down menu is generated normally, based on the sub-pages in the page tree. But if the repeater contains some links, it completely overrides the drop-down menu. It's similar to the fully custom solution in that as soon as you override a sub-menu for a top-level page, you have to manually manage it in case the page structure changes. But you can make that decision for each top-level page individually, so you can leave some of them as is and only have to worry about the ones that you have overwritten. Again, this offers sensible defaults with good customizability. A downside is that the mixed approach may confuse the client, if some changes to the page tree are reflected in the drop-down menu directly, while others don't seem to have any effect (especially if you have multiple editors working on a site). Finding the right solution So how do you choose between the approaches? It depends on the client, the requirements, and on what special cases you expect and want to handle. Sometimes, a special request can be turned down by explaining how it would complicate editorial workflows or have a negative impact on SEO (for example, if you risk having some pages not accessible from the homepage at all). Also, make sure you understand the actual reason behind a change request, instead of just blindly implementing the suggestion by the client. Often, clients will suggest solutions without telling you what the actual problem is they're trying to solve. For example: In one case, I implemented the drop-down override mentioned in example three. However, what the client really wanted was to have the top-level page as the first item in the drop-down menu (see the example requests mentioned above). So they ended up overwriting every single drop-down menu, making the menu harder to maintain. In this case, it would have been better to go with a more specialized solution, such as adding a checkbox option, or even handling it in the code, since it would have been consistent throughout the menu. Another example was mentioned above: If the client requests an additional "Menu title" field, maybe what they really need is a "Headline" field. I recommend reading Articulating Design Decisions by Tom Greever; it includes some chapters on listening to the client, finding out the real reason behind a change request, and responding appropriately. It's written from a design perspective, but is applicable to development as well, and since UX becomes more important by the day, the lines between the disciplines are blurred anyway. Conclusion I realize now this reads more like a podcast (or worse, a rant) than an actual tutorial, but hopefully I got my point across. ProcessWire is at is greatest if you utilize it as a Content Management Framework, creating options and interfaces that allow for customizability while retaining usability for the client / editor. I usually try to hit a sweet spot where the editors have maximum control over the relevant aspects of their site, while requiring minimal work on their part by providing sensible defaults. Above, I listed some examples of requests I've gotten and different solutions I came up with to handle those with custom fields or templates. Though in some cases the requirements call for a custom solution or a quick hack in the template code as well! What are some of the special requests you got? How did you solve them? I'd love to get some insights and examples from you. Thanks for reading!
  7. 17 points
    No blog post this week because I don’t have anything new or interesting to write about just yet (unless you like to hear about repairing fridges and clothes dryers). But I’ve been focused primarily on completing the FormBuilder updates that I mentioned in last week’s blog post, and it’s looking very good, though I’ve still got a little further to go with it. When it comes to multi-page forms, I’m trying to cover all of the exceptional cases where sessions expire, cookies clear, etc., and want to make sure a form-in-progress continues to work through all these situations. Multi-page forms can be potentially long and people can invest lots of time in them (relative to regular forms), so trying to make it all as resilient as possible. This takes lots of time developing and testing, so that’s what I’ve been doing. I’ll be doing some of that next week too, though also have been planning to dig back into the core issues repo and start working through some of those in preparation for a new master version this Fall. Hope you all have a great weekend!
  8. 16 points
    In the last few weeks... or almost months... I worked on a project for a restaurant. Sad to say that the company behind the restaurant went out of business before the project could be finished - or was paid or the website ever saw the light of day. As there is kind of a lot of work in it... but yet a lot of customization... I decided to create a site profile of it and make it public as ProcessWire Barebone Site Profile. Right now I'm stripping out every client detail and finish some functions and details that were planned a few weeks back so you can build right on top of it, if you like or want. Maybe it's only a playground for someone or an inspiration for how to f**k up data-mangement... but hey... better than a ZIP file on a backup drive. 😎 As the project was and is super tailor-made to that client, it may not work for a lot of restaurants out there, but nonetheless I don't want miss the opportunity to offer a foundation for upcoming restaurant projects you may face. The project had a huge focus on dishes, beer and wine variations so those templates are kind of feature-rich. You might want to rip out some of it as most restaurants don't focus that much on those details. Important details I want to be honest and clear about: this profile does NOT include a highly polished and usable frontend as the design is paid and therefore can't be made public the frontend will be a collection of re-usable snippets to show every possible detail of each page, item and whatever the whole site profile will be without any support - future updates aren't planned right now the site profile will be released in single-language setup only (english) existing translations (as seen in parts of the screenshots) will be changed to english existing data, for example dishes, will be replaced with demo content if you, one of your clients or anyone else wants to use this profile - feel free to do so Pro Modules were already stripped out of it only public modules were used and are included with the profile itself the full module list will soon be published on Github the full README will soon be published on Github the full LICENSE will soon be published on Github So... yes... that's just a short preview of an upcoming site profile. As mentioned before, the site profile will most likely never ever receive any future updates, so it will be available on Github only. It's not planned to publish this as a full featured site profile, yet. More details, screenshots and the site profile itself (of course) will be available soon. Questions? Please feel free to ask. Github Repository: https://github.com/webmanufaktur/pwbrestaurant
  9. 13 points
    Nginx' performance advantages over Apache were built on three factors: modern-day multiprocessing in the server, a lot less overhead due to reduced functionality and memory caching. Over the last five years, Apache has greatly reduced that gap by adapting Nginx' multiprocessing approach (one keyword there is the event MPM module), so Apache isn't spending most of its time spinning up and tearing down whole server instances anymore. File system access has greatly improved with solid state disks, too. Apache still has a lot more functionality, and its distributed config file approach, most prominently the ability to make configuration changes with a .htaccess file inside the web directories, hurts performance. Its dynamic module loading approach and the dozens of pre-installed modules most distributions ship also take up processing time and memory. Nowadays, Apache can be stripped down a lot and compiled to be head to head with Nginx, though few actually care to do that, since it also means removing functionality one might need in the future. A stock Apache is usually still quite a bit slower and reaches its limits faster (about the factor 2). This becomes an issue under heavy load or on slow machines. Where Nginx still shines brightly is load balancing. Apache can do it too, but with Nginx it is straight forward and well documented, having been there for a long time. For those interested in a bit of (highly subjective) history: for a long time (speak eighties and nineties), the classic forking mechanism that was common on *nix OSes was the way to do multiprocessing in network servers, and therefore in Apache too. This meant spawning a full copy of the server process and initializing it, then tearing it down when the request was done. Apache brought a small revolution to that approach by implementing preforking, meaning to keep spare server instances around to fulfill requests with little delay. After a while, there were other approaches too when faster multiprocessing approaches become part of common operating systems, like multi threading, which is supported by Apache's "worker" multiprocessing module (MPM). There were, however, big caveats with using other MPMs. Since file systems used to be slow, sometimes awfully so, in the old days, and since the classic CGI approach of starting an executable from the file system, supplying it with information through environment variables and standard input and capturing its standard output was a security nightmare - even without thinking about shared hosting - nifty programmers included full languages interpreters inside Apache modules. mod_perl and mod_php became the big thing, the latter coming to dominate the web after a few years. These interpreters, though, often had memory leaks and issues with thread isolation, meaning at best that an error in one thread tore down numerous other sessions and at worst that the server had a propensity for information leaks, remote code execution and privilege escalation attacks, the former security nightmare squared. Thus, these tightly integrated interpreters more or less locked their users into the classic prefork approach where every instance is its own, basically independent process. With PHP as the market leader not evolving in that regard, things were frozen for quite some time. This was when Nginx conquered the market, first by serving static HTML and associated resources with lightning speed (CMSes generating static HTML were still a big thing for a while), but soon by taking care of all the static stuff while handling the dynamic things off to Apache and caching parts of its responses in memory. Finally, though, PHP finally got a fresh boost and grew stable enough for its engine to re-use interpreter instances. It was easier to contain things inside an interpreter-only process instead of dealing with all the server peculiarities, so FastCGI daemons finally became stable, known and used, and suddenly the need to have the language interpreter contained in the web server fell away. Apache got leaner and Nginx more flexible. Caching servers like Varnish became popular since it suddenly was relatively easy to build a fast, nice, layered caching solution with a combination of Nginx, Varnish and a full fledged web server like Apache or IIS, able to serve thousands of highly dynamic and media rich pages per minute. About that time, SSL grew in importance too, and hosting providers learned to love Nginx as a means to route domains to changing backends and provide fast and easily configurable SSL endpoint termination. Over the last years, Nginx got other features like generic TCP protocol load balancing that offset it from other servers and make it more into a one-stop solution for modern web applications. It does boost its popularity that Nginx is often the first (or the first major) web server to ship evolving technologies, making the front pages and pulling in early adopters, http/2 being one of the most prominent examples there.
  10. 13 points
    Hello everyone, Recently I spent some time researching how I can update my workflow. I really enjoy working with TailwindCSS however, when it comes to Javascript, I often find myself having to search around to find a good package. Often I find myself having a package for lazy loading, a package for sliders, a package for animation, a package for parallax and a package for ajax. Before you know it, you are worrying about dependicies, conflicts and vunrabilities for many different packages. Since the push is to get rid of jQuery and use native javascript, often each will have their own utility classes, some of which do the same thing. This adds a lot of bulk to the website. This is what I love about UIKit, it provides plenty of functionality for a small ~130KB unminified. Not many know this, but the UIKit helper classes are exposed via the API too. So it means you will not have to worry about your javascript working cross-browser (https://github.com/uikit/uikit-site/blob/feature/js-utils/docs/pages/javascript-utilities.md). The perfect thing would be to combine UIKit and TailwindCSS, but the best way to achieve this is up for grabs. I personally use TailwindCSS base and implement components from UIKit. I then use PurgeCSS on the CSS file to make sure anything unused by either UIKit or Tailwind isn't making it to production. I do this using Parcel JS. I have used Webpack and Gulp previously, but I find Parcel is a simple and easy way to get a project started (and it's fast!). The next thing I've found is UIKit is not always the answer. There are now more than ever better ways of achieving things in browser. Such as CSS Grid, `position: sticky`, and `object-fit` try to use these CSS alternatives where possible. Purge will always make sure that you get the smallest possible file size, so avoid using the uk-grid element where possible and use CSS Grid. I have setup a github starter template (https://github.com/TomS-/UIKit-TailwindCSS/tree/master) if you want to have a look at it. CSS Grid will introduce intrinsic design (https://www.youtube.com/watch?v=lZ2JX_6SGNI - Great series) Next will be to use WebP, there is plenty going around on the blogs now about this, but this will make a massive improvement to your Google Page Insight rating (https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.tikari.co.uk%2F&tab=desktop). I would love to hear your web manifesto - and ask me anything about mine 🙂
  11. 11 points
    As threatened in Ryan's announcement for 3.0.139, I built a little module for sliding toggles as a replacement for checkboxes. Styling of the input is CSS3 only (with all the usual caveats about older browsers), no JS necessary, and may still be a bit "rough around the edges", so to speak, since I didn't have much time for testing on different devices or brushing things up enough so I'd feel comfortable pushing it to the module directory. But here's the link to the GitHub repo for now: InputfieldSlideToggle Fieldtype and Inputfield that implements smartphone-style toggles as replacement for checkbox inputs. The visualization is CSS-only, no additional JS necessary. Status Still very alpha, use with caution! Features / Field Settings Size You can render the toggles in four different sizes: small, medium, large and extra large. Off Color Currently, "unchecked" toggles can be displayed either in grey (default) or red. On Color "Checked" toggles can be rendered in one of these colors: blue (default), black, green, grey, orange or red. Screenshots Some examples with checkbox label View all Size and Color Combinations Small toggles Medium toggles Big toggles Extra big toggles
  12. 11 points
    Here's a basic example of how you could save files to a PW page via a front-end page using tus-php and Uppy. 1. Install tus-php via Composer. 2. Create a PW template that will provide the tus-php server endpoint - in this example the template is named "uppy". In the template Files tab, disable any automatically appended template file. In the template URLs tab, allow URL segments. If using Tracy Debugger, disable the debug bar in the front-end for this template because we don't want any output from Tracy being included in the response. The contents of the uppy.php template file: <?php namespace ProcessWire; // Create PW temp directory $td = $files->tempDir('uppy'); $td_path = (string) $td; // Create TusPhp server $server = new \TusPhp\Tus\Server(); // Set path to endpoint - no trailing slash here $server->setApiPath('/uppy'); // Set upload directory $server->setUploadDir($td_path); // Listener function for when an upload is completed $server->event()->addListener('tus-server.upload.complete', function(\TusPhp\Events\TusEvent $event) { // Get path of uploaded file $file_path = $event->getFile()->getFilePath(); // Add uploaded file to "files" field on Home page $p = wire('pages')->get(1); $p->of(false); $p->files->add($file_path); $p->save('files'); }); // Send response $response = $server->serve(); $response->send(); // Exit from current PHP process // Could probably use PW halt here as an alternative // return $this->halt(); exit(0); 3. Create a page using the template - in this example the page is at url http://1testing.oo/uppy/ 4. Add the Uppy assets, JS and markup to the template of the front-end page that you will upload files from. Markup Regions are used in this example. <pw-region id="scripts"> <script src="https://transloadit.edgly.net/releases/uppy/v1.4.0/uppy.min.js"></script> <script> const uppy = Uppy.Core({debug: true, autoProceed: false}) .use(Uppy.Dashboard, {target: '#uppy-box', inline: true}) .use(Uppy.Tus, {endpoint: 'http://1testing.oo/uppy/', limit:10}); </script> </pw-region><!--#scripts--> <pw-region id="stylesheets"> <link href="https://transloadit.edgly.net/releases/uppy/v1.4.0/uppy.min.css" rel="stylesheet"> </pw-region><!--#stylesheets--> <div id="body"> <div id="uppy-box"></div> </div><!--#body--> 5. Upload files via the front-end and see that they are added to the "files" field on the Home page.
  13. 11 points
    Paginated forms: Looking > Forward > To > This > Alot. Thank-you!
  14. 10 points
    The new FormBuilder features look very nice, thanks! Lots of questions spring to mind... 1. When using Form A within a Form B, is it possible to override any of the field settings of Form A in the context of Form B? Say, if I was using Form A inside several other forms but I needed one of the fields to be required only within Form B. 2. Is it possible to have show-if and required-if dependencies on fields within Form A that depend on the values of fields within Form B? 3. In a paginated form, are the form values submitted to the server each time Next / Back is clicked? So is each page validated independently and the user cannot move forward until the current page validates, or is all the validation done on the final submit? 4. If each page is submitted/validated independently, can a site admin see partial form submissions in Entries that are abandoned before the final submit button is clicked? 5. Or if the form is only submitted/validated after all pages are completed, how are field errors displayed if they occur on multiple different pages in the form? 6. Is it planned to have an overview navigation of the pagination using the page headings, so a user can jump directly to any previous page in form and can see how far they have progressed through the total form? 7. Do the different pages "know" about the values entered into other pages in the form, so show-if and required-if can depend on values in other pages? Probably I just need to wait until the new version is released. 🙂
  15. 10 points
    Worth mentioning this module here: https://modules.processwire.com/modules/template-field-widths/ GIF: https://user-images.githubusercontent.com/1538852/49207167-0cbef100-f419-11e8-965a-ca46b4f256d1.gif
  16. 10 points
    I am back again with another crazy module that might help someone. This time I am using the native Tfa class to add FIDO/U2F support. this includes Yubikeys 🙂 Sadly I cant seem to find a way to do multiple keys at once. and it seems you can only have one Tfa method at a time so not ideal but it was a fun challenge to code and maybe someone will a use for it Github: https://github.com/adamxp12/Processwire-TfaU2F ProcessWire Modules: https://modules.processwire.com/modules/tfa-u2-f/ The code is not the neatest and has limited comments but if you understand the Tfa class it should be quite easy to break apart. And here is a demo of signing in using the Yubikey as the 2nd factor
  17. 9 points
    This doesn't warrant a full tutorial, but I wrote a little function that will recursively search through a repeater field to find the first non-empty field matching a list of fields to look for. I needed something like this to generate a fallback for SEO fields (og:image, og:description et c.). Here it is: <?php namespace ProcessWire; /** * Find the first non-empty field out of a list of fields in a repeater or repeater matrix field. * Will recursively search through nested repeaters until it finds a non-empty * field. * * @param RepeaterPageArray $repeater The field to search through. * @param array $fields A list of fields the function should look for. * @param array|null $allowed_repeater_types All the Repeater Matrix types the function will check. Leave empty to allow all. * @param array|null $allowed_repeater_fields All the repeater fields the function will check recursively. Leave empty to allow all. * @return void */ function firstRecursiveRepeaterMatch( RepeaterPageArray $repeater, array $fields, ?array $allowed_repeater_types = null, ?array $allowed_repeater_fields = null ) { // iterate over the items of the repeater foreach ($repeater as $current) { // if the function is currently inside a repeater matrix field, // skip this item if it isn't one of the allowed types, unless // allowed_repeater_types is empty (all types allowed) if ( $current instanceof RepeaterMatrixPage && is_array($allowed_repeater_types) && !in_array($current->type, $allowed_repeater_types) ) { continue; } // get all fields of the current item foreach ($current->getFields() as $field) { $name = $field->name; // if the current field is another repeater, check it recursively $fieldtype_class = $field->getFieldType()->className(); if ($fieldtype_class === 'FieldtypeRepeater' || $fieldtype_class === 'FieldtypeRepeaterMatrix') { // continue with the next item if the field name isn't one of the // allowed repeater fields, unless allowed_repeater_fields empty (null) if ( is_array($allowed_repeater_fields) && !in_array($name, $allowed_repeater_fields) ) { continue; } $deep_search = firstRecursiveRepeaterMatch( $current->get($name), $fields, $allowed_repeater_types, $allowed_repeater_fields ); // if the deep search inside the repeater // finds something, the function ends here if ($deep_search !== null) { return $deep_search; } } // if the current field name is one of the requested // fields, return it's value if it isn't empty if (in_array($name, $fields)) { $value = $current->get($name); if ( // check for empty values !empty($value) // if the value is any wirearray, check // if it has at least one item && (!$value instanceof WireArray || $value->count() > 0) ) { return $value; } } } } // if the function reaches this point, there is no match in the entire tree return null; } Can be used like this: $seo_description = firstRecursiveRepeaterMatch( // content sections fields, a repeater matrix with multiple types $page->sections, // look for the first non-empty instance of any of those fields ['body', 'html_basic', 'html_full'], // only check sections of the following types ['section_text', 'section_columns', 'section_accordion'], // only check the following nested repeaters recursively ['columns', 'accordion'] ); Wanted to share because I thought it could be useful to others. It should be easy to adjust the matching condition from non-emtpy fields to some other condition, depending on the use case ...
  18. 9 points
    👍 for the width adjustment, this is a really nice feature that makes setting up new templates and changing them much more convenient! Funnily, I just implemented a toggle inputfield myself and thought, oh bummer, I could have saved myself the work! Turns out, you weren't talking about a sliding toggle like I am working on, and the core toggle field type is a nice addition for cases where the choices need to be more verbose than a simple yes/no and on/off. It'll come in handy for some of the forms I have in the queue. I will have to rename my module, though 🙂 It'll be CSS only. I still need to add color and size options, and it'll hopefully hit the module repo at the end of next week.
  19. 9 points
    This module will log information about all mails that are sent via WireMail to the PW logs From PW Weekly: https://github.com/BernhardBaumrock/RockMailLogger https://modules.processwire.com/modules/rock-mail-logger/
  20. 8 points
    I just wanted to mention. I found a new job as a front-end dev at https://backslash.ch. Since 2 months there already and enjoy it. We work with in-house CMS specially targeted to governments. So a lot less PW for me in the future, but I'll use it as my tool for private projects.
  21. 8 points
    Hey folks! I've been a bit quiet here about Wireframe, but the thing is that I've finally got a couple of "real sites" (as in not my own projects) to implement it on, and that has brought up some new requirements and a few issues. I haven't had the time to dig into a whole lot of really new stuff (components and such), but I have made a lot of other updates to the framework. As such, Wireframe 0.6 was released late yesterday. (A release on Friday the 13th, consisting of a total of 13 commits – not being superstitious here.) I've been updating the docs at wireframe-framework.com as well, but some parts remain a bit outdated. A lot of what happened in this version doesn't really affect the use of Wireframe, but some things do – and one change may even break some existing implementations: It used to be possible to set the view file or layout from Controller with $this->view->layout = "some-layout" or $this->view->view = "json". This has been deprecated and removed in favour of a setter/getter API: $this->view->setLayout("some-layout") and $this->view->setView("json"), and getLayout() / getView() for reading the value. In addition to some obvious benefits from type hinting etc. this also makes it harder to accidentally change something when you thought you were just passing a variable to the View 🙂 There are now three ways to perform actions and pass data from a Controller to the View: Controller::init() (triggered as soon as the Controller class is loaded), public methods (which are made accessible in the View as $this->method_name), and a new addition Controller::render() (called right before the page is rendered). In most cases where one might've used the init() method before, render() is a better choice, as there's less chance that code will get executed "unnecessarily". In addition to existing Page::layout() and Page::view() methods there are now specific setters/getters: Page::setLayout("layout-name"), Page::getLayout(), etc. Original "unified setter+getter" methods may actually get removed at some point, as they're often ambiguous and make code arguably less readable. Quite a few other changes as well, some of which improve performance and others that make the API more polished. Some bug fixes too, though those mostly apply to what I'd consider "border cases" 🙂 Here's the full changelog for Wireframe 0.6.0: ### Added - New Page methods Page::getLayout(), Page::setLayout(), Page::getView(), and Page::setView(). - New Controller::render() method, executed right before a page is actually rendered. - New ViewData class for storing (internal) data required by the View class. - New getter/setter methods for ViewData properties for the View class. - New method Wireframe::getConfig() for getting current config settings. - New method ViewPlaceholders::has() for checking if a placeholder has already been populated. ### Changed - Various View-related features moved from Wireframe module and ViewPlaceholders class to the View class. - Removed access to local get* and set* methods via the PHP's magic setter method __set() and getter method __get() in the View class. - Redirect feature no longer fails if provided with a WireArray data type; in these cases the first item is used as the redirect target. - Improvements to PHPDoc comments. ### Fixed - An issue with Config class where the "all directories exist" message was sometimes displayed unintentionally. - An issue where View Placeholder values might've been overwritten because existence of earlier value was checked inproperly. - An issue where empty / null view file would be automatically replaced with value "default". On a related note, for this version I decided to give sonarcloud a try. For those who don't know it, it's a sort of a code quality inspector, and it's free for public projects. It didn't have a whole lot to complain about at this point, but it's good to have some sort of validation in place just in case. I will also be digging deeper into reported "code smells", as some of them definitely make sense to me 🙂
  22. 8 points
    I had to find a way to use a person's head shot that was too small (640px) for print collaterals. Found https://letsenhance.io that uses machine learning to upscale an image and also do other improvements. It blew my mind! This is pure "black magic" :) See attached example from their blog. And I also recommend https://www.remove.bg/ for removing backgrounds. Incredible quality also.
  23. 8 points
    I also use different ways for implementing menus, depending on what I find appropriate. Here is a repeater based, one level customizable menu, where hiding fields on conditions makes it possible to switch between "custom" and page picker options:
  24. 8 points
    Some great musing there! I don't think there will ever be a one-size-fits-all approach for creating menus that works for every site. Sometimes I match the menu exactly to the page tree. Sometimes I hard code it. Sometimes I have a checkbox field that determines if each page should be in the menu. Sometimes I let the site editors control it like this with two page reference fields for the header and footer menu respectively, and put it in a "Menus" tab on the homepage. And sometimes it's a combination of these approaches for different parts of the site. There are so many options and each has its place.
  25. 8 points
    Hello everyone, while building an app-interface for a page, I developed some changes and improvements to this module, which I made available as a pull request. But @thomasaull and I are not quite sure if it makes sense to transfer these basic changes into the main module as well. Therefore we would like to hear your opinion: What do you think of the new module version? Which features would be useful for you? I have developed several new features that allow the administration of Api accesses via the ProcessWire backend. I also revised the authentication and added a new Double-JWT option that works with long-lasting refresh and short-lived access-tokens. New Features: New menu item "Restapi" in the ProcessWire menu under "setup Management of Api accesses (applications) outsourced to the new menu item Apikeys now authorize api-access Creation of multiple applications with different auth types possible Double-JWT Authentication, renewable tokens token-sessions can be viewed and deleted in the backend Improved exception handling: Each endpoint can throw exceptions, which are then output with the appropriate HTTP status header and message.
  26. 7 points
    Hi Folks, this is a bit older project but i thought that I will share it with you - https://icapturemylife.pl/ About 2 years ago one of my friends and clients asked me to build a personal photography blog for himslef. In a day life Mariusz is a professional volleyball player, but in his spare time as an amateur photographer he loves taking pictures and learning about photography. Technically, the site was built from scratch with core PW functionalities, the only module used here is Ryan's "login - register" module - to avoid time-consuming comment moderation, we decided to allow comments only for registered users. In general, the blog is quite simple, but it was real fun to build it with PW! I hope you like it 😉
  27. 7 points
    This module gets people confused 😉. Yes, it is both. Page Table is a pro module based on a concept by @apeisa, coded by @ryan and sponsored by Avoine where Antti works. Avoine offered the module to the ProcessWire community for free (through their sponsorship). Edit: For some reason, the above link is not linking correctly to the single post where Ryan explains the difference between the modules. Here is the direct link. It is Ryan's 3rd post on page 2 of that thread. TLDR; Table and Page Table are different modules. Both are pro fields. The latter is available to us for free, thanks to Avoine. 🙂
  28. 7 points
    Just added support to hide columns in the final output. Before I've always hidden those columns via JavaScript in the final table, but if you don't need them, why not removing them from the result before transmitting them to the client? Now it is as simple as that - and the example also shows the new concept for single-page-reference joins which I really enjoy using as it is so much clearer than in RockFinder1: $rf = new RockFinder2(); $rf->find('template=husband'); $rf->addColumns(['title', 'wife']); // wife is a single page reference // find all wifes $wives = new RockFinder2(); $wives->find("template=wife"); $wives->addColumns(['title']); $rf->addJoin($wives, 'wife'); Result so far: id | title | wife | wife:title --------------------------------- 11 | John | 22 | Sue Hide the wife column (the page id of wife pagefield): $rf->hideColumns(['wife']); id | title | wife:title -------------------------- 11 | John | Sue 😎
  29. 7 points
    $page->template->altFilename; $page->template->filename;
  30. 7 points
    I wouldn't call it a manifesto but anyway... let's talk about my workflow. TL;DR I build 90% from scratch. Every time. Each and every project. I don't use frameworks of any flavour.* * except from some JS stuff - see below Long version My boilerplate for new projects: SCSS Skeleton (my personal collection of SCSS Magic) JS Skeleton (my personal collection of JS Magic) HTML/Kit files depending on templates and elements the project needs (inspired by http://bradfrost.com/blog/post/atomic-web-design/) just an empty folder would work totally fine as well Tools I use and need: git Prepros/CodeKit (or ProCache 😎) Tools that may be added later (if absolutely necessary): Lazysizes SVGinline jQuery for Slider scripts (slick, OwlCarousel) MixItUp Tools I never use (because I'm too old for that - I guess) Grunt, Gulp, Bower, Webpack, Parcel, ... you get the idea Benefits Projects are portable Projects run everywhere Every part of project can be changed without affecting other things (most of the time) No need for a special setup (at least for the compiled files) Small(est) file sizes and therefore fast websites (in most cases) Downsides Working with others means I have to trust them and their capability to write good CSS/SCSS You have to think at least twice for each step, every time It takes much more time to build everything from scratch It's much more expensive at first Clients often don't understand the benefits and sometimes WANT a Bootstrap website 😱 FAQ What if you work with others? As mentioned before I have to trust others that they are capable of writing good CSS/SCSS and therefore I tend to work only with very good people I really trust. Is it worth it? Yes! Why? When stuff breaks or needs to be changed, I know where to look, what to change and can do my stuff without the need to take care of any version upgrades, incompatibilities in or with newer version, I don't need a special setup or whatever. AND... if I want to I can still add whatever is needed. Try it the other way around. That's much harder. Are there exceptions? Of course. Backend stuff, admin interfaces and things like - ProcessWire admin is the perfect example. I wouldn't build something like that from scratch. I guess that's my manifesto.
  31. 6 points
    https://web.dev/native-lazy-loading/
  32. 6 points
    It was really nice to see you in a video explaining things. The additional capabilities to Form Builder are remarkable.
  33. 6 points
    Really nice additions to form builder, as an happy customer of Pro Fields I'm going to purchase Form Builder in the next future for a project I'm working on. High five to your new cat! Thanks Ryan, you are a great person.
  34. 6 points
    It's a breaking change in MySQL 8.0.16 that Oracle developers are refusing to list as such, as documented here. I guess Ryan will have to adapt the fieldtype's getMatchQuery code to keep things compatible. I have taken the liberty and opened an issue since this is going to bite me too soon. In the mean time, you could try replacing the line in question in FieldtypeDatetime::getMatchQuery, changing it from else $value = ''; to else $value = '0000-00-00 00:00:00'; and see if that works.
  35. 6 points
    Hi @MoritzLost, great Tutorial again! :) I'm short in time but can give an example for a custom solution that I use sometimes. It suites for small sites or landingpages where the clients have the need to also include external links into the main menu. PS: .. and yes, I try to avoid those things and instead try to stick with the native page tree hirarchy, as it is less error prone for the customers as with an additional layer involved.
  36. 6 points
    @Robin S - brilliant! Your code works like a charm on my site after adjusting a bit of my own code to suit. Can't thank you enough 😍
  37. 6 points
    Right! Multiple Key support is now included. you can put about 19 in before you run out of space (20480 characters, each key uses about 1040) if someone has 19 keys I will be very surprised. I have bumped the version to 1.0.1 as a result. I ain't a big versioning guy but this is a minor change from the users perspective. you can just click the add button more than once now. Just be sure to only click the save button once you have added all yours keys. I have tried it with the 3x keys I have and it works fine. More than 3? not sure cant test that yet. if you click save before you add all your keys then you will only get the ones you added and have to disable/re-enable Tfa to add them all again. This is a limitation of the Tfa class sadly.
  38. 6 points
    Memorizing classes will always be needed. If you take a pre-build framework or your own classes. The big productivity improvement is not in writing CSS using @apply and tailwind classes, but in writing just html and adding tailwind classes directly to the markup. So you need the backing css to already exist. Once you have to switch to a css file you're already loosing on the productivity gains. If you're using properly separated templates there might even be no need to later move the utilities to custom classes and `@apply` as everything's already in one place - the template of a component. Having the utilities out of the box is exactly the selling point of tailwind. Sass/less don't give you classes you can put in your markup - they're pre-processors. It also doesn't want to be a contender to e.g. uikit or bootstrap because they require so much work to be bent to custom design. Building your own components is expected, as custom design most often does require that anyways. There's however some work on a component library being done, which is build on top of tailwinds utility classes; and which will probably be easier to customize than e.g. bootstrap. If you have your own custom utilities library tailwind probably won't be of much benefit. If not however it' a great way to get started quickly on a existing, well documented, well adopted framework. Tailwind by default comes with 9 shades of each color, where afaik 4 are accessable colors on black and 5 are accessable on white background. And you can still edit them, those are just defaults. The message is not "you should not use more than (those) x colors/shades". The message is that a well managed design system must use a fixed set of colors, which is different to each person on the team just adding a new shade each and every time they add something to their codebase. The latter most often being the reason for the exploding number in color or text-size variations. It's about consistency and less about absolute numbers. Imho the need for all those customization variables of frameworks like uikit/bootstrap and the lock-in to a certain preprocessor already show how "inflexible" those solutions really are. I've not yet used any of those frameworks, where I didn't hit a brick wall at some point trying to skin a component to a custom design, because some aspect of a component wasn't customizable (either markup expectations or missing a "configuration variable"). To me tailwind css is neither an alternative to writing css, as the building blocks are way more cohesive and well rounded as well as "higher level" than css 1 – but also not for frameworks, which often impose quite an amount of markup constraints and understandably a certain kind of style, which can be problematic when implementing a custom design. [1] Take for example .truncate. There's no single css rule for truncating text properly. It's overflow: hidden; text-overflow: ellipsis; white-space: nowrap Same for e.g. .rounded-t. It applied rounded borders to both top edges, instead of css, which requires you to set it for each edge explicitly. This is more in line in how a designer would think about a design than how css needs it to be implemented. Nobody will say "make the top left and top right edge rounded". People say "make the top edges round" or "truncate that line".
  39. 6 points
    Fixed! Not completely sure why, but switching: $mail = new WireMail(); to this: $mail = $this->wire('mail')->new(); in the LoginRegister module did the trick — line 684. Now Gmail's sending my registration emails too 🙂 Gotta say, I am hugely grateful for Processwire. Ryan, and all you fantastic moderators and commenters—this is such a great place to learn, and goddamn if the sky doesn't seem to be the limit.
  40. 5 points
    I may have missed some of the points made here (sorry in advance), but regarding links opening in new tab/window: please keep in mind that this is a problem from accessibility point of view. For typical desktop users with decent eye sight etc. this is usually not a problem – and in fact it may be nice in some cases that a link automatically opens in a new tab – but for most screen readers (apps, that is – and thus their users as well) it's a real problem. From what I've heard/read, it can entirely mess up their understanding of the context. WCAG advises that if you're about to open a link in a new window, you should provide a clear signal that this is going to happen. This can, for an example, be a note at the end of the link text: "(opens in a new window)". If you care about accessibility, think twice before you use target="_blank". And for those cases where the client requests this, be sure to inform them that it will likely cause issues for some users. If the client still wants to go with it then by all means do it, but I've found this argument to resonate quite well with most sensible people 🙂
  41. 5 points
    Just stumbled across this...
  42. 5 points
    You probably have "dev" in your hosts file pointing to localhost.
  43. 5 points
    Hallo everyone 👋 I have just release AdminThemeBoss 0.6.0: Introducing, a refined, more colorfull and streamlined expirience: Added: more colors 🎉 Added: improved notifications 📢 Added: improved dropdows ⬇️ Added: improved integration with third party modules like ProDrafts, AOS and ASM… 🤝 Under the hood improvements on how settings are saved and applied Fixed: Some minor bugs 🧨🦟
  44. 5 points
    I'm using this: https://github.com/dragan1700/site-backup One script creates a ZIP of the entire site, the other creates a DB-dump. They can be also used with Cron, if you just put in the shebang (may vary in your server setup). Since normally I'm not working with huge databases, I didn't do an option to zip the .sql as well, but I might add that later if the need arises.
  45. 5 points
    Hmm, I'm not convinced that just because something used to be artificially defined as standard that means it is necessarily "ideal". I've seen so many people not knowing that the browser has a back button/feature (let alone the history...), getting confused by navigating away from the site, using Google just to find it again. But these individuals in question are aware of the tabs feature of the browser – and they do use it – as tabs are promptly visible (at least on desktop) and such users only use what they see right in front of them. Menus and shortcuts? Alien to them. The article is certainly subjective yet tries to look objective. The article's points certainly have merits, but just as our main topic, I think requirements vary and so do implementations based on that...
  46. 5 points
    I know I am getting OT, but I almost never use target="_blank" anymore. Here are a few thoughts: https://css-tricks.com/use-target_blank/ I think the key thing for me is that it's really hard to prevent opening a new tab when it is used, but it's really easy for the user to choose to open in a new tab if they want, so my rule is that unless the user will lose unsaved form data as a result of opening a link in the same tab, I never force a new tab.
  47. 5 points
    1.5.55 is released :)
  48. 5 points
    There are some modules that have their own configurations/settings that are displayed on this page, which are applied using this submit button.
  49. 5 points
    The notes on the Settings tab of Page Edit are a good summary of what the statuses mean: Hidden and unpublished pages are both excluded from selectors (unless you override this) - the difference is that a hidden page is viewable if the URL is known, whereas an unpublished page cannot be viewed unless the user is logged in and has edit access for the page.
  50. 5 points
    No problem! When I have some time here I'm planning to build a site profile using Tailwind CSS so more people can see how it can be integrated with PW. Using both the CDN version, which gzipped is around 60kb and using brotli compression goes down to less than 20kb and the webpack installation I mentioned. :)
×
×
  • Create New...