adrian

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.

I've just updated the PW search function in the PW Info panel to use the new website's search functionality for all sections, except the forum (where I still use Google) and of course the Github repo. Hopefully you'll find this is nice shortcut to the new PW site search which is really great!

Hey @ryan - I am revamping the search functionality in Tracy's ProcessWire panel so that it uses your new search functionality from the site. Current it looks like this, but I will probably clean up the radio options given how the new site search breaks up results itself. The catch is that when I make a request (eg. https://processwire.com/search/?q=findMany) it returns the complete HTML rather than JSON. I could parse out the HTML, but would you be willing to provide a way for it to return JSON for external requests? I think this would be really useful for users so that they can do site searches directly from their sites. Thanks for considering. PS - I have done an update on this so that it now uses the site search (except I still use Google for the forum), but of course it's not ajax - it just links off to the site's search page with links like: https://processwire.com/search/?t=Modules&q=tracy I think that will do for now but let me know if you do feel like making the results available as JSON via AJAX.

That is weird - my local dev setup has 128MB memory limit for PHP and I don't have this issue. I guess your only solution would be to increase the limit in your php settings.

Hi @MarkE - can you please try to narrow it down to a specific panel using the panel selector to disable/enable until you figure it out. I expect it's probably the RequestInfo panel so I would start there. If it is the culprit, is it only on certain pages? You can adjust its settings to turn off some of the more intensive sections.

Regarding the live search (which is awesome), is there a reason that it doesn't find "findIds()" or "findMany()" etc in the API when I type "find"? I actually have to type the "I" or "M" after find to get those matches. Can the matching be tweaked? PS, it's only the ajax/live version that doesn't return these, because this does: https://processwire.com/search/?q=find

Just wanted to add my support to @Robin S's comments. The "ProcessWire" text definitely lets down the look of the site at the moment.

With the new font, I think the "More" link at the end of the initial blurb is no very obvious. I think it needs to be separated and say "Read More" or something more obvious.

The other big one is the site title where "ProcessWire" is at the end, so you can't figure out what the browser tab actually is ?

Congrats @ryan on getting it live! One glaring thing for me (in case you missed my comments above) - the use of pages() in the API examples on the homepage is really going to confuse new users unless the FunctionsAPI is enabled by default, which I think it still isn't. Is that correct?

Here's something tricky with the live search ? Notice the second/third time I click into the input, the entire thing disappears. Also, maybe a small thing, but I find the search close button/ x icon is too far from the input field - can it be at the right side of the field instead of the entire screen, or can the input be floated right rather than center? Not sure which would be better. Adding the ESC to blur would help a little in this regard too, but I think in general it needs to be as easy as possible to clear the search and get the menu back. OR - maybe the menu doesn't need to be hidden when search is activated?