Leaderboard

$page->parents() can take a selector: foreach($page->parents('template!=myTemplate') as $item) { // ...

Looks like you need to include jquery in your page (see point 4 in the lightbox2 getting started docs).

You're welcome! I wish I could help more.

hahaha thanks a lot for you help and patience! I just pinged on an nginx thread to check if anyone's got some more info.

Thanks!

Thanks for the feedback so far and even mentioning me in the pw.weekly issue ? In the standard ProcessModules section is also an input for entering the name of the module, which would download this module from the modules.processwire.com directory. ModulesManager2 simplifies and optimizes this process by providing the modules names in an autocomplete. I know that the modules directory is just ONE source, but that's how the standard in PW always was and I think we should have an official repository for modules. Think of it like the npm registry which is the main source for npm packages. Maybe in the future we could also add alternative module registries like in npm or other package managers, but I really don't know if this is needed. Options to upload a module zip file or provide a download URL like in the original ProcessModules will also be added soon. Partly I agree with you, but every user is different and if you only want to update one module you can search for its name and click the update button. I've been planning from the beginning, to also offer a table based view, or a view with reduced information to quickly scan the modules. As you can see in the latest update there is an example table layout (not even nearly finished) to showcase what is planned later. Also we have buttons for filtering the cards or table view to show only modules which can be updated. I personally think that I would even use the card view for updating my modules, but that's just me. That's your opinion, but others (including me) may see this differently. In the latest update the chosen layout mode is remembered so you don't have to switch. I am even thinking about providing a button to switch between compact and detailed information which would be available for the table and the card view. This would allow someone regardless of the layout to view all information or only the most important bits. This is very easy to accomplish with vue. Maybe I hack something together, because I really like the idea. I have to disagree on this point with you. I think the "discovery" process is good for all users, even powerusers like us. Sometimes I just don't remember a module's name but with MM2 allows me, to search for a term, which might be in the description and I find my module. That's just one example. Another one is that users might not even be aware what great extensions exist and with the modules directory integration they can get an overview. This is something that other CMS or ecommerce systems (like PrestaShop or Shopware) have integrated by default (not at least to earn money, but that's a different topic). But however, if someone does not like the card view or detailed information, he can switch and forget about it. One doesn't need to use all the features. I hope my reaction will not be seen as an offensive, because that is not my intention. Unfortunately, it can often seem that way when written. And of course it is also the case that one can have different opinions on a topic. Whereby anybody can be right. So you guys see, a lot of stuff is still planned, but before I integrate more and more stuff, I am working on the main features for the card view, then release the module and you guys can try it out, provide feedback or pull requests to make it even better.

Here is a little update. Not much to see on the frontend side, but I added a whole build setup which generates the JavaScripts and stylesheets from a .vue file. These files will later be embedded into the module. This step allows me to develop quicker with hot media reloading and better debugging possibilities for vue. I don't even need a ProcessWire environment to make updates to the view, so this enables others to quickly jump in on this and help me with development. Added functions that remember the category or the module name. So you can even provide links for users, to guide them to a special module or category like so: http://localhost:8080/processwire/module/edit/?module=process404-logger Added a switch to switch between card and table layout. This is even remembered and restored after you close your tab or browser. The table layout is something that I plan to integrate at a later point when the main functions work correctly. As I am very busy right now with customer requests I don't have an official date for releasing the module yet. I hope that I can work on the weekend on it.

Updates ? https://2017.stateofjs.com https://2018.stateofjs.com/ https://2019.stateofcss.com/

Care to elaborate about such projects? i.e. some insights into the pros/cons of PW, or just general infos (what worked well, what didn't; what general dev route you were taking instead, bottlenecks or overhead etc).

article: The perils of functional CSS (sometimes referred to as atomic CSS) https://www.browserlondon.com/blog/2019/06/10/functional-css-perils/ Quote: "...if you don’t have a dedicated front-end team to handle this end of things, I can see how functional CSS would be useful. I don’t think it’s a coincidence that back-end developers have written most functional CSS libraries."

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.

This. Please read this before you post. Not a single person here has, to my best understanding, suggested that there should be a page builder in the core. This very topic is in the Modules/Plugins development area of the forum. This topic is not about the ProcessWire core. Thank you ?

Marc, when you are developing a site it's good to turn debug mode on. This will ensure that errors are sent to the screen, exceptions reported, etc. This can be found in /site/config.php. By default, it is false. You'll want to change it to true: $config->debug = true; Obviously you don't want this enabled for production sites, so remember to change it back to false for live/production sites. I don't see any problem with using var_dump, var_export, print_r, etc. so long as you are directing that output to where you can see it. Also avoid running these functions on PW objects as you may get into an infinite loop. Sometimes it can be difficult to track the output of these functions because PW performs a redirect after most POSTs. But if you use PW's built-in reporting functions, they will get queued between requests until they are output. Here are the relevant functions bellow. They will produce the messages that you see at the top of your screen in PW admin: $this->message("status message"); $this->message("status message that only appears in debug mode", Notice::debug); $this->error("error message"); $this->error("error message that only appears in debug mode", Notice::debug); If you are outside of a Wire derived object, you can call upon any API var to handle the notice for you. For example: wire('session')->message('status message'); wire('pages')->error('error message'); Note that these reporting functions above are for the admin (and related modules), and they don't do anything on the front-end of your site. How you choose to debug or report errors on the front-end is at your discretion. Personally, I keep debug mode on in development, and this puts PHP into E_ALL | E_STRICT error reporting mode... it reports everything possible. If I need to examine the value of something on the front-end, I'll do it the old fashioned way with just PHP. Though others may prefer to go further with their debugging tools. If you want to keep your own error log, here's how (anywhere in PW): $log = new FileLog($config->paths->logs . 'my-log.txt'); $log->save('whatever message you want'); You can direct it to store logs wherever you want, but I suggest using the PW logs dir as shown in the example above. This will make the log appear in /site/assets/logs/, and this directory is not web accessible for security.