adrian

Thanks for your input - I totally agree that we need a browsable / filterable interface as well. Let's start discussing this more over here:

As first discussed here: https://processwire.com/talk/topic/20596-new-post-new-pw-website-ready/?do=findComment&comment=178781 Here is the next version of the searching interface. You can see how it automatically populates the module class name in the field from the matches based on what you have typed. This is basically ready to go if Ryan is willing to incorporate. Now we just need to figure out a browsing/filtering interface to make it easy to discover modules base on categories and keywords.

@MarkE - is it all pages on the site, or just some? Anyone else out there using xampp had any memory issues with Tracy? Did you have to bump up the PHP memory limit?

I do think that is a little unfair - @bernhard's RockForms (https://processwire.com/talk/topic/18763-alpha-rockforms-flexible-fast-and-secure-frontendforms-for-processwire/) is actually really nice. There is also http://modules.processwire.com/modules/simple-contact-form/ Nothing is perfect and PW is no exception, so you have to figure out what option suits your needs and skills the best and I think PW is that product for me. Do I agree with how everything is done - no I don't, but for now the pros outweigh the cons for me which is why I am still here ? And the community is also a huge part of why I am here - never come across such a helpful group and that has stemmed from Ryan's communication style here in the early days (when he had more time).

Just a quick little play around with returning results directly from the modules directory. It is pulling in from a cached JSON feed from the modules directory. Obviously we want browse/filtering by category functionality as well, rather than just searching like this, but I think this would also be very useful for those who already know what they want. EDIT: new version and further discussion here:

It's not really beginner friendly

PS - I think that PW experts thing on the hostpapa site is BS. Try these links as well: https://www.hostpapa.de/drupal-hosting.html https://www.hostpapa.de/modx-hosting.html etc

Don't touch hostpapa - their Canadian servers are awfully slow - not sure about the German ones. I am a big fan of Digital Ocean these days (so fast and so cheap), but if you want something managed, KnownHost is pretty good. I am sure others will chime in with some good European options.

Actually speaking of the cheatsheet - these days I just refer to the API Explorer panel in Tracy - it's all there and always up to date and I generally prefer it to the PW website docs for quickly finding stuff. That said, I still think there is a place for the cheatsheet for beginners because it lays out the most used stuff so well.

It is still available though: http://cheatsheet.processwire.com It's also linked to from the PW Info panel in Tracy

Apparently Ryan does that also, so don't feel bad, eg $this->modules vs $this->wire('modules') in his LoginRegister module: https://github.com/ryancramerdesign/LoginRegister/blob/7e6395393d46f9fba3a6769cc2ce85d4e495b8a4/LoginRegister.module#L492 https://github.com/ryancramerdesign/LoginRegister/blob/7e6395393d46f9fba3a6769cc2ce85d4e495b8a4/LoginRegister.module#L430 I completely agree that this belongs in the core modules installation area - I'd even be keen to work on it, and I love the idea of being able to favorite modules for easy access on other future installs. I was just starting to feel like a broken record on the $pages vs pages() etc stuff, that's all. I certainly won't keep quiet on other feedback I have!

Actually @ryan - I have a question myself about the new WireMail() option - it doesn't work with @horst's WireMailSmtp module. It does work in the WireMailMailgun module, but the "hack" to make it work prevents you from hooking into WireMail::send. I'd really appreciate your input on this here, or over here: https://processwire.com/talk/topic/12667-wiremail-mailgun/?do=findComment&comment=178727 Thanks again and sorry for getting OT.

@horst - sorry to ping you, but it's interesting because it turns out the your module doesn't work at all with the: $m = new WireMail(); approach. So I can see why @Pierre-Luc went with that approach even though it then breaks other hooks to WireMail::send Just wondering what your thoughts are on not supporting new WireMail() and whether maybe this module should just drop it as well? Thanks for your thoughts - I am lost without a working MailInterceptor so I definitely would like to get this module changed so that it works without having to maintain my own hacked copy.

@ryan - just looking at: https://processwire.com/api/ref/wire-mail/ I feel like there needs to be some better explanation as to which can be used where. I know this is similar to the $pages / wire('pages') debate, but it's another example where a newbie might wonder why there are options and just assume PW is confusing for no good reason. Do others agree, or is it just me?

OK, I kinda figured it out. These lines are the culprit: https://github.com/plauclair/WireMailMailgun/blob/904137e349ac081eee73239bb31b0978b67a00f1/WireMailMailgun.module#L176-L183 /** * Handles send() when new WireMail() is used instead * of calling wireMail() directly */ public function send() { return $this->___send(); } So this seems to be triggered which prevents the hook to send() from working. Turns out if I start my mail call with: $m = new WireMail(); then the Mail Interceptor's hook into WireMail::send works perfectly, but it doesn't work with: $m = wireMail() or: $m = $mail->new(); Not sure how best to proceed at the moment, especially because this module doesn't seem to be maintained anymore, but I think it's probably getting quite a lot of use. Any thoughts?

Hi @gebeer - it looks like @Pierre-Luc is no longer around here - I wonder if you might want to take over maintenance of this module? Now to the reason I came to this thread - for some reason the Mail Interceptor panel in Tracy doesn't work with this module and so far I can't figure out why because it simply hooks into WireMail::send() which this module extends, the same as @horst's WireMailSMTP module does. Does anyone more familiar with this module have any ideas? Thanks!

@ryan - I see you have a separate live search field on the API page that limits results to the API. I wonder if it would make sense to have a similar one on the Blog page as well where the results are limited to just blog posts?

Thanks for your thoughts @wbmnfktr - I agree that examples must work as they are - they shouldn't result in a message explaining why they don't work. Ok, I'm done now, I promise :)

Sounds good!! I think it is especially confusing that you have: $page, but then pages() - that suggests to me that there is no $pages option. I still think all examples on the site should use one approach with a dedicated page that explains what can be used where and why. I provided more detailed thoughts about this here: https://processwire.com/talk/topic/20596-new-post-new-pw-website-ready/?do=findComment&comment=178332 I think all the $this->wire('pages'), $wire->pages, $this->pages, $pages, pages() options are confusing to newbies to PW and OOP in general. But I won't mention it again if you think it's OK ?

Hey @bernhard - not sure but this is how I do it in the Migrator module: https://github.com/adrianbj/ProcessMigrator/blob/eaf8255aded36033bcd468c59b235b9a0eb6b785/ProcessMigrator.module#L990 Not sure if "get" vs "install" works a little differently or not - been a while since I worked with this.

Let me know if you notice issue again and can narrow it down to something that I can investigate.

There is of course Soma's old Modules Manager, but I haven't used it in years now. Maybe a new Modules Installer panel for Tracy ?

Thanks to several of you for suggesting that Tracy should be part of the core and as much as I like the idea in theory, I am not so sure about it in practice. Here are several reasons why I don't think it should be part of the core: 1. I think all core code should be vetted by Ryan and Tracy is just too large for him to be able to do that. 2. There is always the chance that I, or the guys at Nette that develop the Tracy core, could introduce a security bug - obviously we do our best, but I don't think Ryan should have to worry about this affecting the reputation of PW. 3. I update and add features to Tracy very often and I wouldn't want to have to wait on Ryan to approve PRs for those changes. 4. Tracy does slow down ProcessWire a little when activated and the debug bar is showing, especially on pages with lots of complex fields (this can be reduced by turning off certain sections/panels). I think most of us are willing to live with this for the advantages it brings, but I think new users should probably experience PW with the best possible speed and then decide if they want Tracy. 5. Some users just might not like Tracy - they already have their own way of debugging and don't want something else getting in their way - I think they're crazy, but who am I to judge ? Anyway, hopefully those arguments make sense, but I really do appreciate how much you guys value Tracy as a tool in your own workflows - don't forget to like in modules directory and star on Github!

@ryan - at the bottom of https://processwire.com/sites/submit/ you have link for "Powered by ProcessWire FormBuilder", but it links to a broken URL at: https://store.di.net/collections/software/products/processwire-form-builder

Sorry Ryan, but can also please change this API example from the homepage: // Set “summary” field value on page and save to database $page->set('summary', 'Hello world')->save(); It will fail with a "Can’t save page 1: /: Call $page->of(false); before getting/setting values that will be modified and saved" error. Maybe you could use a setAndSave() example instead, or something else? I do also wonder about the image example - you are using a single "image" field, but if someone is playing around for the first time, chances are they will be working with an "images" field and so this call will also fail. Another thought for the homepage if you don't like my Console API sandbox idea - what about a screencast of coding and returning the results of some key API calls? This could be recorded from the Console panel, or you could do it with code editor and browser windows tiled - I like the idea of users being able to see the API in action visually to see just how easy it is to query and output field content.