Pete

The amount of time I've lost to this in the past ??

I'm sure we can get an "updated" JSON response set up no problem once we get the feed code altered on the modules directory as well. Not heard back from Ryan about that yet so will give him a gentle nudge ?

I can take a look at it - what data does it need to pull? Just the same as is in the current feed? I think the only issue is that depending on the version of PW you run it dynamically filters the modules somehow on the PW server - I'll ask Ryan if it's okay to share the code so you can see what's going on and I'll get back to you.

That makes sense. As others have pointed out to me as well it's not a huge amount of data at the moment either, especially if you are just grabbing the essentials to start with and then if we wanted to do anything fancier like grab the readme then that can be a request when you go to view a module's details maybe. The modules that are on Github - it's down to the user whether they have a readme.md file so I guess that's a bit hit and miss. For non-Github modules in the directory they have an "Instructions" field we can get that data from. I think what this might highlight during this process is how many modules there are with no instructions that are able to be fetched from the server - in which case we can get a list together, nudge the authors and tighten up the submission process - I don't mind forcing either instructions or a basic readme file - not sure what everyone else's view is on this?

There are enough logs to show that the user has used the forgot password tool in the forums which isn't the action of a bot. They also passed the validation when joining and I also checked on stopforumspam.com manually. Aside from that, which rules have been broken? It is annoying to be sure not to receive any thanks, but the easiest thing to do here is simply not reply.

Theoretically I guess pretty easy. But what I also think it would be nice to do is to be able to click on a module and view the instructions and other readme data without leaving the PW admin which is where the data would balloon massively if it were in one large file. I guess that could be a JSON file per-module for the more detailed information as they would get called less and all of these files could of course be generated when the module gets updated in the directory. You raise a good point on modules that aren't in the directory - I guess it's more incentive for people to add them ?

I don't think interactive requests are out of the question either instead of relying on static JSON on the server, but I can see the benefit in separate cached JSON files on the server for category totals and all the modules per category in the short term.

I'm wondering if it needs to pull down data for all files in one hit anyway? If it starts off with categories and totals and just the first XX amount of modules listed by default it could fetch the rest as the filters/searches change surely? It would mean a change to the code on the modules directory but I'm happy to look at that for you - maybe set up a separate feed for our tests if you only want to pull a small amount of data until someone clicks on a module for more details.

I'm absolutely in awe at the speed you two are working at. I feel like a snail in comparison ? It's a separate thing so not one for right now but some similar code would be involved - the installer could do with reworking to allow easy presentation and installation of site profiles a bit like you can install a WP theme easily. You should be able to choose a site profile during installation (maybe thumbnails for each and click to popup the information about what it is and what it contains along with any caveats) and make that side of things easier too. I'm far from the only person to mention this, but I do know it's been mentioned for so many years now off and on and it lowers another barrier for entry in that people get to code that's relevant to them that little bit quicker. I think that one change, albeit not a simple one, would lead to more people producing site profiles as the current steps involved are again more numerous than they could to be and site profiles aren't paticularly visible as they are lumped with other modules in the directory. Also a note to say you guys probably want to make sure your tweaks to the modules interface don't show site profiles from the modules directory or that could get confusing.

The reason for "rebuilding" the categories layout into the module (though it's not a hard build to be honest) is that it lowers the barrier to entry further. It's just a convenience thing, but also a way to prevent new users having to go back and forth straight after installation. It's also how some other CMS's do it so it would also be intuitive for those users and just a nice bonus for the rest of us. I guess they will need to go to the PW site anyway for things like docs, but I think installation and setup should be made as simple as possible ideally. Nothing about the current setup is hard of course, but less clicks and easier/quicker module discovery would be a nice bonus - I'm a PW veteran and I honestly don't scour the modules directory for new modules often, but if there were a feed of recommended or new modules within PW itself that would help lazy people like me to not overlook things like Tracy ?

Hehe so much for not having much time ? Since you guys are a million miles faster than I am what I'll try to do today and tomorrow is an interface mockup for how I think it could look with categories and thus favourites idea so we've got a few ideas to pull from. In terms of instructions for modules - they're hit and miss as to whether they're on a GitHub readme.md file or entered into the Modules directory itself, but I think the code on the Modules directory can easily be tweaked to pull from either source. I also don't think that there are so many modules that if we thought there was some other essential functionality that was required (like something that HAD to be read before install) that there could easily be an extra field added to the DB to flag that up in a consistent manner. Sure there are a lot of modules, but for better or worse there are a lot of ways to store the config info too so maybe the Modules database itself is the only consistent way around that if we need to? Will post more later. Got to paint a kitchen first (yay ??)

I hadn't considered multi-instance issues but that totally explains an issue I was having a few months ago ?

Oh definitely - I'm forever only remembering parts of module names ?

Maybe we could collaborate on that. The "favourites" idea was just something that popped into my head because I've been working on integrating the forum member bar into other parts of the site (and forum member auth into the Modules and other interactive aspects as well). My test member bar currently does an AJAX request once the page is loaded so we can keep ProCache running on all pages, so a similar method could be used to remotely authenticate a user against the central PW database and retrieve the user's favourite modules. I think that this could be extended to do all sorts of cool things really, but an revamped module installer first, maybe with user-defined favourites, would be a good starting point - even if we only get as far as a mock-up of the design to begin with and run it by Ryan before we get too far ahead of ourselves ? The layout of such a module installer should be pretty similar to this idea we've been discussing for a while for the main Modules forum here as well, so maybe we could kill two birds with one stone there with the layout and basic search functionality at least ?

As per my last post above, if there's no explanation then yes, it is adding confusion, especially for newcomers. Well, and me, because I never bothered to learn the difference as I'm always in a hurry to get stuff done - tricky few years personally so if something works well I do it and move on quickly, but I do come to docs and examples every now and then and for the sake of a quick explanation on the docs page that would make me think "aha!" I should use that way, it's a shame not to have that explanation. If we're giving examples though, as in the case of wireMail, it should surely just be ONE way to do it (the most efficient?) with the other ways stored somewhere further down the page maybe even at the bottom in this case. Like "alternative ways to get a WireMail instance" (but with better wording). The funny thing is, I used Option C from that page the most at the moment as I'm often using it in my own classes, outside of PW modules on a current long-running client project, so again I'm not able to see why that option isn't recommended or where I would go to find out why (I'd actually love to know if anyone has the answer? My classes do extend PW's core, so maybe I can get away with option B?). Flogging a dead horse by now, but yes, for that specific doc page just list option A as being for use in templates, option b for use in modules and explain option C somewhere else under a "did you know?" or "alternative methods" header or something. And yes, don't shut up Adrian, this is all good feedback ?

I end up interchanging $this->pages and wire('pages') in modules depending on my mood. I've never learned which one is better than the other which is my problem, but I think it needs to be explained up-front, and as I think others have said any examples on the website should use the most efficient (or readable, but make a choice of one or the other) versions for where they're used. If there's a little "did you know the difference between x, y and z" on the documentation page for all the $pages info then that would be handy and link to the same explainer on a different page so the explanation is always there but the documentation and code examples are consistent (not saying they're not, I've not had 5 minutes to look yet just want to make sure we're not confusing people too much :)). A module installer that would install Tracy from wihtin Tracy? ? I'm kidding ? What I meant was an overhaul to the core module installation area really. I vaguely remember even MODx had a way to browse modules from within the admin - it just saves time and it's not like there should be more bandwidth using a REST api than rendering the modules directory as you're not rendering all the assets at the same time. There may be more bandwidth if it results in a spike in usage, but that can only be a good thing. What I'd love to see eventually is, after the installer runs, it then suggests some things for you to install on a first-run splash screen, so setting up a new site is ticking some boxes and you're away. Even better (though harder to code) would be remotely logging into the PW site from your installation and getting a list of your personally-chosen regular-use modules so you can tick the ones you need for your new project and they all install in one go. Sure, that's the ultimate nice-to-have, but anything that speeds up initial setup helps I think, especially for newbies ?

I've not actually used Tracy yet... *everyone gasps* ...but I have often dreamed of a module installer that lets you browse via category from your PW installation itself. This way you get around the less intuitive copy-and-paste-the-module-name-to-install functionality as it exists today (it's not hard but other systems make it simpler) and it's also the ideal place to get "must-have" modules in front of people's eyes. For example, show a list of the categories on one side of the page, and on the other side have a list of the top-10 modules most people use, or maybe suggestions for different types of website even ("Top modules for starting your blog/news/magazine site", "top modules for starting your company website" etc etc and clicking on each shows you the list. I'd also suggest some of the Pro modules would make the list as well as several of them are must-haves for me. Edit: forgot to say that this is the way around it - making things like Tracy one click away after installing ProcessWire, and also getting the obligatory "use third-party modules at your own risk" warning in there whilst also not adding much more to the core.

I am in the process of putting together a questionnaire which will ask questions like "what features do you think are missing form the core" (not the actual wording, but you get the idea) so hopefully that will be ready soon and I'll be collating answers. I think with so many great ideas discussed daily over the forums, Ryan almost certainly doesn't see every last one, so hopefully with a questionnaire to kick off 2019 if there are common requests from PW users that can help focus attention in certain areas.

Quick one on the blog comments - it is technically possible to have the forums automatically create a new topic in this forum when a blog post is published, show comments from that topic below the blog post, but also allow you to sign in on the website at the location of the comments form itself and comment there as normal. Would that be preferable to keep all comments in the forums from what people are saying? If you're logged in on the forums already there would be no requirement to login from the blog post again - it would know you're logged in. The form itself would likely be more basic there as I've found embedding the full-featured forum editor tricky in the past, but think this solution might be the best of both worlds to keep the conversation happening here in the community forums if that's what people would prefer?

Looks lovely, and pleasantly surprised to see it working so nicely on an ultrawide monitor across all the sections! I'm mucking about with ideas already (it's not got this lovely gradient through to pink in the original version ?)

I understand what you mean, but we're used to this as we're already here and understand ProcessWire, but new users (the target audience of a new homepage) aren't. They're also less likely to use anything but the master branch initially so whilst I understand your reference to the dev branch, I don't think it's applicable here. I guess I just don't see the point in rushing to launch and tweaking it afterwards (aside from the inevitable excitement to share something new - I know I would be keen to release it as Ryan is, but the ProcessWire site is no small thing and gets a lot of visitors). Sure, the new docs are for everyone, but the public face (homepage) and marketing side of the website isn't really for the folks that are already here ?

Plus, if you hang fire a bit, we can launch the forums and dev directory and other sections using the new styling all at once rather than a bit at a time. It actually bugs me when other sites don't do this as you're getting new visitors all the time so, whilst it's only a visual mismatch, it can be jarring and look a little disorganised/unprofessional if people don't realise what's happening behind the scenes and it may be that they go elsewhere as a result.

I agree with Jens on the "are you a..." split on the homepage (think I've mentioned it to you before Ryan once or twice ;)). If there's going to be a screenshot on the homepage then I think it needs to be below that section really, a bit like Activecollab and others show their main features here before leading into the screenshot - because the main selling points wouldn't immediately obvious from the screenshot itself: https://activecollab.com/ https://www.kayako.com/ and some CMS' don't even have a screenshot on their homepage: https://modx.com/ https://umbraco.com (.NET, but popular in that language) https://www.drupal.org/ https://www.joomla.org/ Wordpress do have a screenshot on wordpress.org, but only to show that you can install a blog with a theme in seconds (their strong point of course). I pretty much agree with everything Jens has said so far, especially this post: I also don't like the heading font, sorry! It seems like a small thing but ProcessWire is a professional system built for professionals, so somehow to me the playful curves on the heading font seems to detract from that for me. But since you're asking for everyone's opinion you're always going to get a split of "that looks fine" and "I don't like that" ? Another thought - is it actually wise to launch the new website just to get it out by a self-imposed deadline? I'm thinking in case there's something in the navigation structure that may change, but equally if any pages get their content majorly shuffled around due to feedback it's probably not wise to change them multiple times on a live site in quick succession. I've made suggestions for changes to the top-nav over the years that I think make sense and I'm worried that - without seeing the new structure - others may also have suggestions that could be adopted and changing the navigation structure more than once in a short space of time is obviously not great for SEO (if that were to happen - there's a lot of "what ifs" until we can see it of course ?). Putting it up somewhere behind a simple password screen where search engines won't immediately gobble up the content and getting feedback makes more sense to me, though I realise that getting feedback from so many people before launch could drag out the process quite a lot. Maybe give us somewhere to look at it before launch, see who's interested in helping out and get a small group together to help with the final touches? That way you get the best of both worlds, launch with any ideas you want to implement but then the small group collates and curates the feedback so it doesn't add too much time into the process.

I upgraded my Windows desktop earlier in the year for the first time in 6+ years as the motherboard was finally dying and the speed difference was immense. Now I'm the slowest component in my dev environment by a long shot ?

Done.