adrian

Did you just delete the template table and nothing else? This should be relatively easy to rebuild manually because it links to the fieldgroups and fieldgroups_fields tables which actually contain the details of the fields that belong to a template. The main thing you will have to do is to recreate template permissions etc once you have the basics set up. If you look through the columns of a templates table from another install you should be able to figure things out. If you have a lot of templates it might be easier to write a script that queries the fieldgroups table and rebuilds the templates table from that because there is actually some duplication of content between the two.

Sorry @itsberni - I totally misread the error message - obviously not a file permission issue for those modules - sorry for the wild goose chase.

How did you install the module? If you copied the files manually I am guessing this is simply a file permissions issue - make sure everything has the correct owner and permissions that allow reading of the files.

Thanks @gebeer - I think we really need to figure out this issue with new WireMail() not working with WireMailSMTP, but come up with another solution to what is used by this module because of the way it breaks hooking into send(). @ryan - any chance you have a minute to look into this please? If you are willing to maintain this going forward perhaps we can replace your fork as the repo that is installed from the modules directory.

It didn't this morning when I first checked after @Peter Knight's post so I'd say Ryan has added a redirect.

Tracy session data shouldn't stick around there - maybe there is a cleanup issue on windows/xammp. I actually think that given the errors you are seeing are in core Tracy files it might make sense for you to file a Github issue here: https://github.com/nette/tracy to see if they know what's going on.

Thanks for all your work on this @jmartsch - are you planning this as a third party module? I assumed we were trying to integrate these changes into the core modules installer interface, at least that's what I have done with the above autocomplete interface. I think it would also make sense this way because then we can both share the cached modue data json. On that note, are you getting the data in batches? I ask because the json feed is limited to 350 modules and we have more than that.

Where are you seeing this session file? In /site/assets/sessions? Is it related to Tracy somehow? Or are you referring to something else?

@ryan - I feel like on the API ref main page the classes should be below the variables, or at least the variables should be on the left, but I prefer the former with two columns still, but with Primary left, Input & Output right, Users & Access left, etc .... My reason being that for the most part variables are the main thing that is used in template files - these are what beginners need to know about. The classes themselves are generally a step removed from the code we are writing. The main exception is probably pagefiles/pageimages. The rest are used much less frequently. Interestingly when you are viewing an individual variable or class and the left sidebar is showing, the variables are on top.

Yep, already using that to populate the autocomplete entries in the screencast in the first post. I am caching the results already so we can use this cached data for the autocomplete/search shown above as well as to populate all the other data for modules in the proposed browsing/filtering interface. Do we really need install instructions given that this will install the module when selected? Looking forward to getting this all going!

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?