Leaderboard

For years, as a personal project, I've been documenting my little corner of the globe via my personal website www.marlboroughonline.co.nz, which also gets used as my testbed for new ideas with ProcessWire, SEO and other stuff, as I'm not going to have some client on the phone if I break something, but if I do it well, I can earn a few dollars from Google adsense. I've always had a bit of a passion for natural history, being introduced to David Attenborough documentaries when I was a teenager, and actually studying life sciences at university, so it's only natural if you'll excuse the pun, that a part of my site would be dedicated to documenting local plant and animal species in my part of the world. For many years, one of go to reference websites for information about native plants has been New Zealand Plant Conservation Network, and I often include a link from my site to details on a species on the site as an authoritative reference, and I use the site to help identify plants I've photographed. It was only recently that for some reason I decided to have a look at the source code of the site, and it looked suspiciously like it was made with ProcessWire. After a bit more detective work, I found out that it was made by @Robin S and is indeed built with ProcessWire. To get away from the computer, I also teach kids edible gardens at my daughter's school a couple of hours a week. It's part of a wider Enviroschools programme here in NZ, and among other things it covers is teaching kids to recognise noxious weeds. There's a really useful website Weedbusters that's supported by councils and used as a reference for many invasive plant species, and it turns out it's more of Robin's handiwork. I think it's a bit funny that even when I'm supposedly away from ProcessWire engaging in other activities, it seems to follow me around. ?

@ryan I can collaborate with you on improving Repeater Matrix and giving you a really deep understanding of page builders, issues that would be faced and my thoughts on a direction ProcessWire can take. I've built a module internally that demonstrates a lot of these concepts.

Off the top of my head if I had to name the things that are going to be — and, to be fair, have already been for some years now — potential "game changers", it'd have to be "flexible content" (as in some sort of page or site builders) and "headless" (as in native, external APIs). Neither of these is anything new, and both I believe have been mentioned here, and perhaps even existed on our roadmap in one form or another. In my experience the API part is driven largely by developer intent: there are many developers out there who prefer to work with something like JavaScript, or simply want to make a more clearly defined distinction between the data (API) and the application/front-end. WordPress has a native REST API, which (while not perfect) often gets the job done. Bolt has native REST and GraphQL APIs. And then there are all sorts of headless CMS' out there (Contentful, Strapi, Prismic, and so on) that have taken this even further, though I'm really not an expert on those myself. If ProcessWire wants to attract more developers, especially the types that enjoy working with modern technology and particularly JavaScript, this might be worth considering. Modules like AppApi and Process GraphQL have done a great job at providing an almost-out-of-the-box solution, and it's also very easy to build APIs on top of ProcessWire, but a native API would bring certain benefits that none of these solutions can do. That being said, it would also likely be a massive undertaking and would no doubt require a lot of planning: ProcesWire has a fantastic "internal" developer API, so the bar for a built-in "external" API would be pretty high ? As for flexible content, this is now something we use for pretty much every site we build. Unless it's a registry of predefined items (which is pretty rare), it's going to benefit from some sort of flexible content strategy. These days most content editors just can't be satisfied with "here's a CKEditor field, it works kinda like Word" — they demand quite a bit more than just that. We've been using RepeaterMatrix for this purpose and for the most part it works, but I do have to admit that it doesn't feel as slick and intuitive as some of the competition. Both Kirby and Bolt have interesting ideas in this regard, and Gutenberg is starting to look very interesting as well. Finally, a pet peeve of mine: the admin. While I really enjoy using ProcessWire's admin, there are also things I don't quite enjoy. For my taste it feels a bit overly verbose with all those lines, and when I look at the screenshots from something like Bolt, I really miss a sidebar. A proper one, one that stays in place, like the Reno theme had. I know I sound like a huge WordPress fanboy, but this is something they got right early on, and based on user feedback I'm not alone with that opinion. ... so that's one smaller-but-still-possibly-somewhat-meaningful feature I would like to see on our roadmap ? Now, having said all that: I know this is nothing "unique" or "groundbreaking". A lot of other systems are already doing these things. I would love to throw in an idea or two that no one has yet thought of, but honestly I think on the web today it's more about "who does it best" than "who has the most unique ideas".

Happy New Year! Today I’ve bumped the version on the dev branch to 3.0.170, and it’s quite a lot of updates. This post covers most of them. In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021? https://processwire.com/blog/posts/pw-3.0.170/

Oh. One more. I get that this is literally something you said you're well aware of, but I'd still like to say that I would absolutely love to see more pull requests get pulled into the core this year ? This has been brought up many times over the years, but the truth is that "if ProcessWire is so good then why are only a handful of people interested in contributing" is still one of the FAQ's I ever so often find myself answering. At least in the market I am in appearances and popularity matter a great deal, for clients as well as developers. I want to be able to justify why I'm not using the most popular platform out there, and sadly it's getting harder and harder by year (and a rather low number of contributors isn't helping, at the very least).

Happy New Year all and thanks @ryan for all of your work. There are already so many ideas and requests, but here is what my current clients asks: Central media/image manager for reusing images across pages Support for different file storages for image like Flysystem

Regarding @teppo's suggestion about a native external API - I know that we just lost one PW website to a JSON / GraphQL / Gatsby / React stack because the developer decided that was easier to do that than use GraphQL / Gatsby / React on top of PW. Personally I think his decision was misguided because now he is managing content in json files (he is the sole dev / content editor so he doesn't need an admin CMS), but I think he'd have done much better using PW for content management and generating JSON that can be pulled into the frontend. But maybe if PW had a native way of doing this, he might have stuck around and I am sure there are lots of other devs out there that ignore PW simple because they don't think it will let them use these modern frontend stacks. I do think an integrated javascript API would make lots of things much easier as it always feels a bit hacky to me getting PW data into JS - it would be great to have JS page object available on page load, but also to have a built in AJAX method to pull other PW data on demand. I do feel like we need to convince potential developers that PHP can work together with the rest of the tools they want to use - they don't need to use Node to integrate things. I am still baffled that companies are paying thousands of dollars a month for things like Contentful or ContentStack when PW can essentially do the same thing - I know there are other benefits to these services, but I find the downsides not worth the tradeoff. There are of course self-hosted headless CMSes out there, like https://strapi.io/ which has been around since the end of 2015 and has 32,000 Github stars and 600 contributors. I know you have constantly maintained that you don't care about popularity, but clients often do, and with good reason - they need to know that there are other developers out there to take over if needed. The other big thing for me is finding ways to make certain data queries more performant, perhaps with something like @bernhard's Rockfinder functionality built into the core so that we can pull large amounts of field data in a more performant way - we don't always need all the info contained in the PW objects that are returned by regular API queries. Honestly I haven't yet used Rockfinder in production - I've actually gone with custom SQL queries of PW field data to build up objects/arrays exactly as I need them, but some inbuilt methods for automating this (like Rockfinder does so well) would be nice. One thing I would like to see is a way to easily implement certain admin forms in the frontend - yes we can do this with the API, but having all the admin tools available in the frontend would have saved me a lot of time over the years essentially rebuilding functionality. Sometimes I can get away with the AdminBar module, but it's not always appropriate. If you want an idea for another profield, a properly working version of a recurring dates field would be awesome. Unfortunately the Recurme module just isn't a viable option - I do have it running in production, but it's not efficient and I have several hacky fixes in place. It's actually a difficult problem doing recurring dates well, but it is a common need for lots of sites and so a good implementation would be very popular. However, my biggest concern and bugbear has always been what some might consider little things, but these "little things" can sometimes cause lots of frustration - things like: https://github.com/processwire/processwire-issues/issues/550 - there are lots of other examples of these sorts of things that require hacky workarounds. It is much more important to me to find proper solutions for these than adding fancy new features. I'd also like to see the admin user interface tightened up - there are lots of areas for improvement and so this is just one silly example, but having the double-click to open/close all repeater items on the on/off toggle button is confusing and I think needs fixing. I have converted a local web dev agency to be exclusively PW (from Drupal), but whenever we chat, their main complaint is always the look of the admin - they feel it doesn't look modern and clean enough and makes PW look a bit cartoonish. Please don't take that as a personal insult - getting this right is difficult and in my mind take a very talented design person to get the details right - I can see the things that are jarring, but I am not good at figuring out how to make them right. I think this is really important in ensuring that PW continues to be something that we can convince clients is a modern platform. I do also think that the interface to RepeaterMatrix could be modernized. I am not a huge fan of fancy website builders, but I do think we need to find a middle ground between what RepeaterMatrix currently provides and the best of the new building tools out there, because eventually clients will complain that they don't have access to the shiny new tools - it hasn't happened to me yet, but I think that's partly because of the type of clients I typically have.

Are you using the AutoSmush module by any chance, configured to use the reSmush.it service? I've encountered similar problems on a site with this installed, and there seems to be a problem with the SSL certificates on one or more of the reSmush.it servers since late December.

Announcing the current status, planned release, roadmap and preview of Padloper 2. Status Feature freeze. Full multilingual support. Only PHP 7.2+ supported. Support for ProcessWire 3.0 only. Backend support for modern browsers only (that support JavaScript ES6 modules). Current Work Finish work on admin/backend. Work on installer and uninstaller (including configurable availability of some features). Work on UI/UX improvements. Start work on documentation with special focus on technical documentation. Continue work on Padloper API and data/model component. Roadmap Please note that these ARE NOT hard and fast targets. The roadmap may have to be adjusted to accommodate technical and non-technical constraints. Q1 2021 Inbuilt support for (latest) PayPal (full rewrite, no external modules required). Additional work on Padloper API. Invite a limited number of early alpha testers (fully-priced product). Soft and closed release of Padloper 2. Q2 2021 Start work on relaunch of Padloper website. Inbuilt support for Stripe (no external modules required). Future Plans Support for more Payment Gateways. Support for order, customers, etc imports and exports. Support for AdminThemeReno and AdminThemeDefault. Separate fully-featured frontend shop module. Consider support for multiple currencies. FAQ 1. Have you abandoned this project? No. 2. When will Padloper 2 be released? First early alpha release is scheduled for Q1 2021. This target may change depending on circumstances! Access will be by invite only for this first release. 3. What is the pricing model of Padloper 2? Three licences: Single Site, Developer and Agency licences (12 months’ updates and VIP support). 4. How much will Padloper 2 Cost? No price has been set yet. It will cost more than Padloper 1. 5. Can we upgrade from Padloper 1? No. 6. Will existing users of Padloper 1 get a discount for Padloper 2? No, this will not be possible. Apologies for the earlier announcement. It was unrealistic and unworkable. 7. Can we pay for Padloper 2 in advance? No. 8. Does Padloper 2 render markup/templates in the frontend? No. Access to all data you need to build your shop’s frontend is via the Padloper API. 9. Can we keep sending you ‘Are we there yet’ messages? No, please. Preview Here is a video preview of the current state of the backend/admin of Padloper 2. Please note the following: This is early alpha. There are bugs! It even includes WIP/notes!! FOUC, misaligned things, etc. The video shows the near-raw implementation of Vuetify UI. The UI/UX improvements work is yet to start. What you see here is the development version. Some of the incomplete features may not be available in the early releases. Most of the features you see will be optional to install.

Recurring dates / calendar module A big +1 from me for this. A lot of sites need this kind of functionality. The key thing is solid RRULE support in a user-friendly interface. It's really common to have events that occur on a regular schedule (e.g. the first Tuesday of the month for now until eternity) but then occasionally have exceptions where the event is moved to a different day or cancelled for a particular date. The Recurme module had the right general idea but if you take a look at the source code you can see why it's not really scalable and needs a lot of tidying. A robust calendar module is not a simple thing so it would be great to have something that's built to the standard of Ryan's other Pro modules. Flexible content I find that Repeater Matrix is fine for when the content is divided into discrete conceptual and visual blocks on the frontend. It's pretty easy to make the mental connection between "conceptual/visual block on the frontend" and "Repeater Matrix item in the backend". Where it's not so good is when you have a long piece of text that is interspersed with different pieces of other content, e.g. text - image - text - graph - text - pullquote - text. In this scenario the editor/author wants to think of the text as one conceptual unit. Breaking the text across multiple Repeater Matrix items feels wrong, and it's difficult to locate and move paragraphs between the different blocks. For this scenario (which is pretty common now - think of Medium articles or other longform articles containing rich content) the Statamic Bard fieldtype looks like it nails the solution pretty well. The user wants to see a single flow of text with elements floating inside the text that represent the other pieces of content. These floating elements should reveal the content they contain (or at least the type of content) so that the user can understand what is what, but perhaps be edited outside of the text editing interface where that is more practical, e.g. click an element to edit it in a modal. I have actually made a couple of different experimental modules that expand Repeater Matrix in this direction but haven't found a fully satisfactory solution yet. Admin theme I'm pretty happy with AdminThemeUikit and don't think it looks dated. I've said before that there's too much padding between and around elements and the main page heading is way too huge (maybe this is where the "cartoonish" criticism comes from), but these things are very simple to fix with custom CSS overrides. I wouldn't want to see the admin styling change every year and I can't relate to the desire to be endlessly changing the admin to keep up with the latest fads. The admin is a place you go to do work, not to see pretty things. It should be plain and utilitarian, which AdminThemeUikit already is. Having said that, a couple of ideas that would make it easier for those who want to tweak the admin: 1. Maybe there could be more config fields in AdminThemeUikit to let people adjust things like spacing and font size without having to add their own stylesheet to the admin. 2. It would be pretty good if developers could more easily create modules that extend AdminThemeUikit so if they want a customised admin theme they only have to override certain specific methods rather than completely duplicating the module. Right now if you do... class AdminThemeFoo extends AdminThemeUikit ...the admin experience completely breaks so it's not currently a good foundation to build on. And it would be good if there were more hookable methods in AdminThemeUikit so that it becomes possible to manipulate the main menus for instance.

Ouch. But this is really common. When it comes to a developer working at a company, new software is sometimes a threat. It's always easier to work with what you already know than to take a risk on something new. JSON files are nice and simple, so it's hard to argue with the sole developer and content editor; maybe PW is overkill for his needs. There's nothing hacky about getting PW data into JS. It's very simple. But I get what you are trying to say, is that PW doesn't do it, so it's the developer that chooses how to do it. Here's the problem, and reason why I haven't made PW do it, as simple as it is — the only real front-end input request that returns data from PW is the URL. And the contents of the returned data is at the discretion of the developer. That's it. It's incredibly simple and an amazing security barrier. Once you have a JS API to PW data, it sounds really cool... until you consider the security implications. What makes the PW API so useful is that you have access to everything as if it was already in memory. This is great in PHP because only PHP has access to it. But anything that JS has access to is also open to the world. Anything could slurp up anything from the API at that point, not to mention it would be a huge denial of service hole. The exception is if it's all behind some kind of authentication. But the vast majority of PW websites are not built behind a login wall. So then we might say, we just apply restrictions to what can and can't be loaded from the JS API. But at that point, it's taking just as much work as if we just output our own JSON, while still likely not as secure. I remain really interested in the idea, but so far have not been able to get the math to add up in being a worthwhile venture. I even built a module years ago called ServicePages that did some of this, and I got so disturbed by the potential implications of it that I ended up deleting the module permanently. Meanwhile, outputting just what you need for your JS remains 100% secure and simple. Maybe someday we can get the math to work here though. I think it's great he's building this. While I don't think the core needs to expand in this direction, I really like to see modules like this get built that can fill needs as people have them. The more the core can support people in building modules that solve their needs, I think the better. There are very good reasons why the admin and front-end are different environments that do different things. I think it's best if the core doesn't dictate much about the front-end, and always trying to keep PW as far from generating markup as possible. So I don't think it's likely PW would provide all of the admin in the front-end, other than the existing front-end editing features. But I don't think that's what you meant. Can you clarify about what you are looking for here more specifically? What front-end functionality have you built that you think should be in the core? Interesting, I don't know much about this, but it does sound like a good Fieldtype to have. What do you use a recurring date for on the front-end? I don't have a good answer for that particular issue report because it's asking to disable access control in a manner that I just don't know how to do safely. But I'll look at it again. There will always be little things, especially for people like you and me, who work in PW more than the most here, and probably represent less than 1% of the PW users. But I have to balance time between the little things and the big things in order to keep everyone happy. Likewise, when it comes to prioritizing issue reports, I have to consider how many people are affected by an issue and whether workarounds are possible. Hundreds of minor issue reports were resolved in 2020, and likely 1-2 months worth of hours getting through them. This is part of the job that I do every year and will continue (and actually I enjoy it). I could spend 6 months doing nothing but issue reports, but it likely wouldn't make any difference to 99% of users and would hurt the rest of the project. So I try and find the right balance. I don't know who would need that feature other than you and I didn't even know it was there, but if this is a major pain point, maybe we can build you a voice command for it. ? Kidding aside, I agree that it's good to start thinking about new stuff in the admin theme in 2021. I like the current Uikit admin theme, but I also used to like the old AdminThemeDefault too, and now it looks so primitive and behaves so clunky relative to AdminThemeUikit. So I imagine to some users, maybe the AdminThemeUikit is starting to feel old since it's been around for a few years now. Ideally we'd have a new admin theme design every year, and maybe someday we will. I'd like to stick with Uikit 3 as the underlying framework, but the look/feel can be a blank slate.

Yes the flexible content one seems to be a recurring theme, so I’m interested in that. As far as non-external headless, ProcessWire was the first to do this, at least as far as I know. The admin was later built in as an application in ProcessWire. For external API headless, this has been something I’d planned to do years ago (per old roadmaps and JS APIs). But, when it came to actually starting to implement it in the way I thought it would be useful, I found it opened a can of worms in terms of security. And security is one thing that you can trust I won’t make compromises on. I’ve come to settle on being comfortable with an external API so long as it is protected by very strong authentication. But then it also becomes less of a common strategy to build around, and more of a specialist thing… maybe useful to a small percent of users. Maybe there’s a middle ground and it’s worth revisiting this year. I've recently been in contact with @Brett who is is working on some really cool stuff with GraphQL (and more) and ProcessWire, which I'm following very enthusiastically. I definitely wouldn’t expect it to feel as slick as anything built for the purpose, as RepeaterMatrix was not intended for that. But the fact that it can be used at all for that need means we’ve probably got a good head start. Since this strategy doesn’t really fit in the projects I work on, it leaves me at a bit of a disadvantage in being an expert on it. Nevertheless, I’m interested in building it, but might need someone else work with. It sounds like you have a lot of experience here, interested in collaborating on it? This is subjective of course. I’m the opposite, a sidebar drives me nuts. But I’m not against sidebars, just against sidebars for when I’m using PW (or anything else where I have to be productive). I’m simple minded and easily distracted, and focus on one thing at a time. I can't do the multiple-monitors thing, and whatever window I'm working in is always maximized. Sidebars always compete for my attention in a way that other things (like mastheads or footers) don’t. But I'm probably the minority in this preference. When it comes to our next admin theme (or evolution of the current) I think it makes sense for something like a sidebar to be a configurable option. I’m too many years beyond my graphic designer days now, so I don’t think I should lead the next iteration of the admin theme. But I do think it’s a good time to start thinking about the next iteration of the admin theme, as well as dropping the older ones. I think you are providing good answers to the question. Unique and groundbreaking are not requirements by any means. The core is in a really great place right now, the foundation is solid, more so than the other projects out there. So now’s the time to start looking for what’s going to the most helpful to current and future ProcessWire users going forward, and start implementing them. This is the drawback of having a developer that’s committed to a project for life. I could be wrong, but I don’t think there are many projects like PW where the developer has been working on it for nearly 20 years, and is committed to working on it for at least another 20 or more. Not to mention, committed to make it easy for others to work on as well. Most people work on stuff and then move on to other stuff. I don’t do that. So I look at every PR a lot more critically than I think most projects do. The PR submitter submits the PR and that’s the end of their responsibility. Whereas, every bit of code that gets added to the core is something I accept responsibility for. It's something PW users and my clients trust me to vouch for. I look at new code in the core through the lens of supporting that code for the next 20+ years. Nevertheless, I do try and identify PRs that can be added and supported, and then take the time to understand how they work, and even recode them if necessary to fully understand how they work, so that I can support them in PW’s core for the long term. It takes awhile to work through them, but I’ll continue to do that. My preference is always that we talk about the PR before someone takes the time to code and submit one, so that we are on the same page about the goals and timeline for it, and getting all the details right. PR's that come in unsolicited are fine too, but they do take me a lot longer to get through. PW will always be a project that puts security, stability and long term sustainability above appearance or popularity. I understand there are times where a project calls for using what’s popular, and I see no harm in doing that, so long as you are also committed to supporting that decision as being in the best interest of your client. PW’s track record speaks for itself. WP’s track record speaks for itself.

Thanks for the feedback. Just to be clear, this question is not looking for answers about the location of issue reports, wishlists, PRs, or feature requests. All of that is already clear, always important and ongoing — great stuff, but also information we already have. It never hurts to be reminded, and of course we'll be working with much of that in 2021. But that's not what I was asking about. Zoom out and look at the bigger picture, and look towards the future—what's game changing and "next level" for the years ahead that we might not already know about? It doesn't have to be unique to PW either; maybe you see another project doing something major that would be nice for PW to also be able to do. I might be unique in this respect, but when I develop sites in PW now, it doesn't feel as though I'm lacking or compromising anything at all; everything I want and need is there. But my needs are also pretty simple. I do know that in the last couple of years, Markup Regions and custom Page classes were the two most recent game changers [for me at least]. But that's all the past. There will be more game changers for you and me, I have some ideas about things, but nothing concrete. I recognize this is something that's going to be personal and different for everyone. For the majority, I really doubt that any single product meets every need you have, whether ProcessWire or something else. But the intention is that ProcessWire can meet most of them, and better than other projects, for our current and future users. I'm trying to put together a long term, big picture roadmap (2021 and beyond) that keeps us focused on that. I have thought this sounds interesting no doubt. I'm interested. I'll catch up with it again. Not speaking of this particular feature request, but more in general. Unless it's something most people need, I look at a lot of specific feature requests more from the perspective of "how can the core best support someone in being able to fill this need?" (from a module, hook, etc.). For stuff where the need doesn't also surface in my own projects, I'm not an expert on it, so I'm not as likely to be able to please the people that do have the need. But making the core flexible enough to accommodate some need with module or hook, or something else—that's where I am an expert and can provide a lot of value. Improving the core by expanding its flexibility in accommodating things for people that wanted them, and not necessarily expanding what it does on its own. I like the GitHub requests repo or the Wishlist forum. But if you already have a GitHub account, I think it's a little easier to keep track of there. I'm not all that familiar with this as it seems to be a strategy that doesn't really meld with the types of projects I work on. But I've always been interested in it, and it seems to fits the big picture role I'm talking about. It's something I'd like to spend more time with in getting to know better. I know a lot of people use various strategies here already. But it's adapting things like repeater matrix to fill the need rather than something more designed for the purpose. I'm curious if you could expand more on why this is your personal favorite and how you would use in in your projects? I think this is something that might be too specific of a need (I'm guessing not many run into it). But it is actually a need I have had here. I've always answered it just by building whatever feature was needed into the front-end of the site. So the front-end basically has a custom-admin portion, for logged in users that have a particular role. Usually it's publish/unpublish/approve/disapprove something or another, list reservations, toggle things, etc. Simple stuff that needs little explanation. Though when the need involves full page edits (body copy, images and such), that's really what PW's admin is for, and that's where I'll put them. But if a user doesn't need to be using the page editor, then I don't bring them into the admin at all; and instead use the API to for simpler admin functions built into the front-end. Is this similar to your use case, or are you thinking of something different?

Thanks, I did notice this when it was released and it looks like a nice module. It's only for single images though, and I'd still like to see image and file reference fieldtypes in the core. For some situations such fieldtypes are needed (e.g. avoiding duplication of images/files and associated data/descriptions when the asset is used on multiple pages, roles that may select files/images but not upload new files/images, scenarios where images/files need to be centrally managed, etc) and the fact that the core doesn't cater to this feels to me like a gap that should be filled.

Just stumbled over this: https://javascript.info/

Hi @ryan - it's been a great year for the PW core - thanks for all your hard work as always and very glad to hear that pro module sales are doing so well for you! In addition to the requests repo that @Robin S mentioned, there is also of course the https://processwire.com/talk/forum/5-wishlist-roadmap/ thread. I actually think it would be best to start with the issues repo and once those are all fixed, then move onto those two requests lists. Lots of user input has gone into those lists and I'd hate to see that effort ignored or pushed aside in favor of new suggestions. I have lots of new suggestions / ideas, but I think they should wait so your efforts can focus on outstanding issues first - does that make sense?

This week I’ve been doing some work on the core, but it’s been a short week with the holidays, so I’m holding off on committing the updates till I can test and tweak them a little more next week. I’ve been working on some upgrades to the core Fields editor (Setup > Fields), as well as some improvements to our Inputfields system, among other things. Next week I’m also planning on working through some of the GitHub issue reports and some other parts of the core as well. With it being Christmas today, I’ve barely been at the computer and I’m guessing not many of you are either, so I’ll keep this short and wish you and your family a Merry Christmas and/or Happy Holidays!

I actually like the way that @dg from Nette handles this - he uses the "adrianbj authored and dg committed" approach which I highlighted once before - this allows the committer to make changes to the commit, while still having the author recognized as the contributor.

He had already built the site in PW (and had it running for over a year) and then rebuilt it as described - that's the reason I brought it up - it obviously wasn't clear enough that he could use PW effectively in the scenario he wanted. Maybe "hacky" isn't the right word - I do it a lot and have my systems down, but I thought perhaps it could be improved and be easier for those who want to do all frontend code in JS (which isn't me BTW). I appreciate all your comments around the security issues for this though and as always you have that as the highest priority, which is great - thank you! I guess it's mostly the ability to edit all the fields on a page, including those that require JS (like repeaters, image upload, etc) so that frontend users can edit their content (think complex user profile data etc). It's doable already, but it involves ensuring key JS files are included and some relatively complex API logic to get everything working correctly. A way to make this really simple could be very useful. Displaying event calendars - usually things like weekly farmer's markets, open mics etc I don't agree that it wouldn't make a difference - I know my needs are more complex than some users, but I've seen enough likes / replies to many of my GH issues to know that these things are affecting others as well. I think lots of users would like to be able to expand/collapse all items at once, but they don't know they can because the UI for it is so hidden ? I don't think it's an age issue - unfortunately I think it's always never quite felt right - in some ways I actually prefer the tightness of the default theme but it's look is definitely too dated. Thanks for taking the time to think through all my suggestions and minor gripes ?

@Zeka Thanks, I still feel this is redundant in PW, but it's been mentioned enough times that I can't rule it out. So will keep eyes open here. Yes, if you mean things like S3 storage or similar, this is something I've been interested in too. This is definitely on my wishlist too.

Awesome! Thanks @Jonathan Lahijani that would be great.

No, unfortunately not - I've had to disable the AutoSmush (or at least disable the optimize on upload option in the module). I guess it's a case of keeping an eye open to monitor when they'll fix their SSL. It's affecting non-PW users too: https://wordpress.org/support/topic/ssl-certificates-expired-on-resmush-it-servers/ Regards, Ian.

IT is not just one image it happens with diferent images, so the images are not the problem. Yes I'm using AutoSmush and SSL, did you happen to find the problem or fix for this? I'd like to keep AutoSmush if possible. Thank you R

Thanks @thomasaull and @Sebi (I've just bought you 3 coffees). Keep up the good work! :)

Can you post the image in question so we can test it, just in case there is something weird with it - even though I know you said it works sometimes.

Thanks @Robin S - should be fixed in the latest version.

I can't wait to try it out!!!

Hi Adrian, I spotted a minor layout bug with the new editor links in the Dumps panel:

They are custom fields (columns) added to the field_images database table. @Robin S - have you seen this module: Is this mostly what you are looking for?

Hear, hear! ? One place to find ready answers to this question is the requests repo: https://github.com/processwire/processwire-requests/issues That repo currently has 289 ideas for improvements, and it would be fantastic if you can find the time to do a quick first pass through the repo and add any comments or questions to the requests, and indicate which ideas you think are the most promising for developing this year. At the top of my wishlist is an Image Reference fieldtype: https://github.com/processwire/processwire-requests/issues/207 I'm imagining something that works much like a Page Reference fieldtype, with various options for defining which images are selectable and some elegant way of selecting from a large number of images (maybe a modal interface similar to Lister that lets you filter and select images for adding to the field).

Hi, @MadeMyDay as a former modx evo user for quite a long time and now completely pwired i of course really like this "why i choose..." article of yours ? just one thing to add, maybe you may set your website config debug on false, it currently displays errors to the bottom of the article ? Have a nice day

I think this is a helpful post for anybody new to hooks: https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?tab=comments#comment-158164

I had the same problem. After playing around I found out that there is a code in LanguageSupportPageNames.module with a comment "verify that page path doesn't have mixed languages where it shouldn't". This code was redirecting my non-default language page path to the default page path (and that didn't work correctly for my setup). I commented the redirect line out and it worked for me: // verify that page path doesn't have mixed languages where it shouldn't $redirectURL = $this->verifyPath($this->requestPath); if($redirectURL) { #$this->wire('session')->redirect($redirectURL); return; } But this can't be a solution (to change code in the wire). That brings me to my question: Is there a way to deactivate this redirect using the config, a hook or something? My Setup: Nginx Webserver, PHP 7, Processwire 3.0.165. I use 2 different domains, one for each of my two languages.

Good point, as many took the road without javascript like me. Lately I am catching up with "talking to the server without page reload" (ajax - XMLHttpRequest) I left treehouse and moved to udemey.com as I experience them more professional/friendly and they have a lot of offers. https://www.udemy.com/course/the-complete-javascript-course/

I know very little about multi-language development in PW, but just to confirm: are you using the FieldtypeURLLanguage module? It's created by Ryan but is different from the core FieldtypeURL module.

VSCode introduces Remote Development in the new Insiders Release! https://code.visualstudio.com/docs/remote/remote-overview Seems like they were watching our thread here closely ?

Awesome thanks - this has been a useful lesson ? I think my inital confusion on this stemmed from my hook function being my own code and not part of PW, but I guess as it is an extension of an existing class then it makes sense the other variables should be accessible. (I may be rambling here... but I know what I mean!).

Ah, great. I figured it out myself! We need to add all fields into a children array: $this->add( array( array( 'type' => 'Fieldset', 'name' => '_myfieldset', 'label' => 'Fieldset Label', 'collapsed' => Inputfield::collapsedYes, // Inputfield::collapsedNo 'children' => array( array( 'type' => 'select', 'name' => 'kit_type', 'label' => 'Select the Kit you are using', 'options' => array('uikit' => 'uikit'), 'required' => true, 'columnWidth' => 50, ), array( 'type' => 'text', 'name' => 'kit_fullpath', 'label' => 'directory site path to your kits scss sources', 'columnWidth' => 50, ) ), // close children ), // close fieldset //.. add more fields ));

Where as the tags stored? As part of the 'description' field for each image, or are you using a custom Fieldtype/Inputfield for your images? I'm going to assume they are in your description field, so you could do something like this: $tags = array(); $tagCloud = array(); foreach($page->images as $image) { $t = explode(' ', $image->description); $tags = array_merge($tags, $t); } foreach($tags as $tag) { if(isset($tagCloud[$tag])) $tagCloud[$tag]++; else $tagCloud[$tag] = 1; } ksort($tagCloud); The end result would be an alphabetically sorted $tagCloud array with each key being the tag and each value being the number of times the tag appeared. So you could output it in some manner like this: foreach($tagCloud as $tag => $quantity) { $fontSize = 10 + $quantity; echo "<span style='font-size: {$fontSize}px;'>$tag</span> "; }