Leaderboard

FYI: Today, January 29, Firefox 65 is out with WebP support. The only major browser left with no WebP support is Safari.

I do a lot with $cache, it's great and super flexible, and easy to implement. I expect i'll be using it more and more in the future. I don't use markup or template cache much; I always use ProCache, but i think it's still important to have pages load pretty fast without it, as the first page load that generates the cache needs to be something reasonable that doesn't overload the server, or bounce the visitor. One thing i did recently on a few challenging situations was to use the $page to store markup. For example, using something like wireRenderFile, you can generate the some bit of markup and store it with the page, in a hidden field; this markup can be regenerated on save of the page using a hook, and then it doesn't have to wait to get regenerated on the front end. Another thing that is interesting to do is $cache within $cache, ... had to do it in a few places, it was tricky, but it really made a difference in speed..

This is certainly nothing, which can be answered in absolute terms. File system speed depends on the filesystem. A RAM disk is way faster than some old-ish HDD. The database might be local and mostly in RAM, but could be on another machine with network latency to consider. You'd need to test this on the actual machine you're working with under the expected load you're working with. If you're already doing much filesystem IO WireCache might perform better. If you filesystem IO is not saturated, but your db is queried a ton, then adding even more load to the db might not be the best choice. The latter is probably the more usual case for ProcessWire usage. Attention seems like one of the worst metric to judge the usefulness of features by. Afaik WireCache was added to allow for caching of actual data (like pagearrays), which is something MarkupCache simply could not do and cannot do. If you don't need that as a feature performance would be the only thing I would care for.

As @Macrura said in most cases ProCache and WireCache is the way to go for me. Also what I have found super useful is namespaces for WireCache, as for the example you can load all cache for a page with namespaced cache and preloadFor method just with one query. There is CacheNesting module, I haven't used it but it should help to handle such scenarios https://modules.processwire.com/modules/cache-nesting/.

We're finally launching a redesign of our website! Doesn't feel like it to us, but our previous design was already from 2013 ? https://ed-works.com/ We like to keep things simple, so the only third-party modules that we installed were Tracy debugger, Admin on steroids and Admin Theme Boss, which we tweaked a little bit to our taste. All in all, there's not much going on inside PW. Our main concern was to serve the frontend with responsive images with a close quality to the originals, and for this, it's important that PW allows us to use ImageMagick for resizing them. We also love to use PW's image tags to add classes to the images. In this case, we use them to display the images with three different sizes. We also had to change the templates to serve the projects to the homepage via Ajax. We hope you guys like our new baby ? Edit: I forgot to refer that we also changed our logo and tweaked our name to ED works.

You can do it to the degree forums do it. Like track users activity somewhere in a database whenever communication happens and take some amount of timeout at which you consider a person without activity offline. What you cannot easily do is online users to the degree you would expect it from e.g. a chat platform, where you actually want to detect if someone is leaving without waiting 15 minutes and without them needing to communicate to your server constantly. This is the realm of websockets. I may be biased, but if you want a really proper (and scalable) solution for that problem take a look at: https://dockyard.com/blog/2016/03/25/what-makes-phoenix-presence-special-sneak-peek

PushAlert4PW WIP.... Some more on the PushAlert REST API. Every sent alert requires a URL and it appears in the notification. Silly me thought that was 'just life'. Didn't realise until I chatted with Alex from PushAlert, that it is in fact the URL to which notification responses are sent. It does not have to be the page, eg an admin page, that sent the push notification. So cool! The URL also appears in the notifications so thinking about hooking into the front end home page URL to capture the json responses and save the data to a different page that connects the sending page with the message id. Onward & upward

emplate Field Widths Adds a "Field widths" field to Edit Template that allows you to quickly set the widths of inputfields in the template. Since v0.2.0 the module also adds a similar field to the settings of Edit Field for Repeater, FieldsetPage and Repeater Matrix allowing you to quickly set the widths of inputfields within the Repeater/FieldsetPage field, or within each Repeater Matrix type. Note: widths are only saved if the edit form is submitted with the "Field widths" field in an open (non-collapsed) state. Edit template Edit Field: Repeater Edit Field: Repeater Matrix Why? When setting up a new template/repeater or trying out different field layouts I find it a bit slow and tedious to have to open each field individually in a modal just to set the width. This module speeds up the process. Config options You can set the default presentation of the "Field widths" field to collapsed or open. Widths entered into the "Field widths" field are only applied if the edit form is submitted with the field in an open (non-collapsed) state. "Collapsed" is the recommended setting if you think you might also use core inputs for setting field widths in a template context. You can choose Name or Label as the primary identifier shown for the field. The unchosen alternative will become the title attribute shown on hover. You can choose to show the original field width next to the template context field width. https://github.com/Toutouwai/TemplateFieldWidths https://modules.processwire.com/modules/template-field-widths/

Pages At Bottom Keeps selected pages at the bottom of their siblings. A "bottom page" will stay at the bottom even if it is drag-sorted to a different location or another page is drag-sorted below it (after Page List is refreshed the bottom page will still be at the bottom). Newly added sibling pages will not appear below a bottom page. The module also prevents the API methods $pages->sort() and $pages->insertAfter() from affecting the position of bottom pages. Note: the module only works when the sort setting for children on the parent page/template is "Manual drag-n-drop". Why? Because you want some pages to always be at the bottom of their siblings for one reason or another. And someone requested it. ? Usage Install the Pages At Bottom module. Select one or more pages to keep at the bottom of their siblings. If you select more than one bottom page per parent then their sort order in the page list will be the same as the sort order in the module config. https://github.com/Toutouwai/PagesAtBottom https://modules.processwire.com/modules/pages-at-bottom/

Background I'm creating a module to integrate https://pushalert.co/ into ProcessWire. You actually don't even need a module. You could just use the "Other Websites" javascript provided by PushAlert for basic functionality, ie send a broadcast notification to all subscribers. This is essentially what all the other integrations, including WordPress, do. The WP integration installs a widget with a form enabling the admin to enter details such as title, message, etc from a blog post. It does not: collect any statistics within the CMS about the notification enable audience fine tuning to eg a particular subscriber or subscriber segment within WP. The admin needs to use the PA dashboard for that functionality PushAlert has a javascript and REST API. It's intended that this module will use both. https://pushalert.co/documentation What my module does so far: associate a subscription with a user. FE user clicks a button on the website front end to subscribe and/or agrees to the browser popup to accept notifications from this site send broadcast push alerts from a page within admin It doesn't have a 'widget' but easy enough to create a fieldsetpage with the relevant fields and add that fs page to any appropriate templates, then with a hook, send the notification. Need to be careful that once published/sent, the notification is not automatically re-sent on subsequent page edits. Looking for help/collaboration on how best: to send a notification, eg from a blog post, then track the statistics. Dilemma is that the push notification must come from the admin page. Responses go to the sending page which, as it's an admin page, is restricted and will not accept the https response. This is where the other CMS integrations stop. The only json response from PushAlert is the status, eg 'success', and the notification id. There is no opportunity at this point to capture the sending page id. handle, 'once sent on page publish', do not automatically resend on future page edits Am thinking along the lines that FS Page will have a @kongondo runtime markup field https://modules.processwire.com/modules/fieldtype-runtime-markup/ to pull the stats from PushAlert. Every time an admin visits the page, the stats will update. Once an admin checks the 'Send notification on page publish' checkbox, a hook creates new front end page that records the 'sender page', sends the notification request to PA, which then uses that newly created frontend page, as the response endpoint. Another rook re-associates the front end page with the admin page (eg blog post), to update the stats. Potential use cases: Notify individual and/or users with a particular role of an event, eg "New work opportunity" for job seekers; new blog post published; entries now open, etc... Looking for help/ideas/collaboration on this module. Please let me know if you're interested and as I do, believe this would be a great addition to ProcessWire

ImageMagick isn't required for progressive JPGs. GDlib also just works fine. You just need the interlace setting. See my originial request here https://github.com/processwire/processwire-requests/issues/134

Truth is I would have also assumed ImageMagick as a requirement!

Ok... my mind seems more reliable than I thought. ? I wish I could find that thread or post where it was discussed back than.

I guess I'm totally wrong with that but somehow my mind tells me that you will need ImageMagick/IMagick support for this.

Awesome Reply... @flydev Just wanted to add a side-query to OP. Below is a situation :- #. Once a new user logged in, this user can see list of current Online Users. ( I have seen this feature mainly in Forums websites / Social N/W sites ) Can we do this in PW ?

PS - when you have found the field in question, check out the Field settings in the RequestInfo panel to see if there are any textformatters showing there that are null or empty or something.

Have you tried: bd($textformatter, $field->name); so you can see which one at the end there is returning null? If you know the field affected, you might be able to check which textformatters are assigned to the field and find the problem that way.

Thanks, guys! I'm checking what's up with the server now. update: the server is up and the permissions are fixed. Remind me not to run terminal commands as root again ?

We have ListerPro's with 10.000's of pages (some up to 80.000 pages and counting) displaying 25 fields. Just make sure to limit/paginate around 50 or 100. Still quite fast (around 3 seconds loading time). This includes all kinds of Markup changes. So I would say: yes

Hi Kai, I don't see any requirements here that is not manageable by ProcessWire, the only limit will be knowledge of PHP. 1. You could implement OAuth easily with 3rd party libraries or integrate each provider's API into ProcessWire. 2. You can manage users by using API and/or by playing with roles, permissions into ProcessWire backend. 3. Yes - very easy, for example, you can just use "pages" and page filedtype for relations. 4. Yes - by playing with urlSegments. 5. Yes - you can implement this feature easily + there are one or two modules which might help you to achieve that. 6. Yes - you have to implement it. 7. Yes - by using the API . 1. Yes 2. Yes 1. Yes (hooks come to my mind). 2. No problem at all. 3. From what I've read on the forum, I want to say : superfast. (ProCache)

Thank you, I overlooked this one ^^ My other question (search several fields) is also finished... I turned out that I didn't have a field "body" at all. If it exists, there is no error.

With Lazy Cron you will not be able to guarantee exactly when a task will be run - a page on the site will need to be loaded, just as you noted. You could skip lazy cron altogether and use cron directly on your server, or you could use the technique that Ryan mentions at the bottom of: http://modules.processwire.com/modules/lazy-cron/ (How to make it not-lazy) If you are running your site on a shared host, you will probably find a tool in your control panel for setting up and managing cron jobs. If you don't have a control panel, you can simply google it and you'll get lots of tutorials: https://www.google.com/search?q=limux+manage+cron+job

SiNNut - you are quite right, it's a totally bogus "Apple and Oranges" comparison. I guess the real comparison is down to this; I've heard about how magical RoR is, I've been using it on the course and you know what - I'm totally underwhelmed, despite the all the hype and all of the resource and community around its development over the past 6-8 years or so. By accident, I stumbled on ProcessWire that has been, from what I understand, largely the results of one person combined with the help of an enthusiastic, yet relatively small community by comparison to that belonging to RoR. When I started to look at PW, I was amazed at how well thought out it is, how well architected it is, how easy to use it is, and how powerful it is. I immediately got that "giddy" feeling when you know you've stumbled onto something amazing. I just didn't get that buzz or excitement about RoR despite having heard for years about how good it is and how it's better since V3.