adrian

https://github.com/nicoknoll/MigratorWordpress - it handles post and comments automatically but if you already have the posts imported maybe you could at least steal some code from this to help with your comment importing.

Nice - much better than my "Inspect Element" approach ?

Now that Github topics tags have been around for a while and most of us are using them, this is becoming a pretty useful link: https://github.com/topics/processwire?o=desc&s=stars

In the template context, how can $page be any page unless you have overridden it, which we always discourage. Otherwise, $page is always the current page. I do understand that page() can't be overridden like $page can, so maybe going forward the functions API should be the recommended approach, but we are going to confuse the hell out of beginners if homepage examples show both approaches. But the save() example won't work as is and will confuse the user to see an error about outputformatting which they will not understand anything about yet. We have setAndSave() - why not use that example? Same goes for my observation about the image example and the issue with the need for first() on the site profiles which I think mostly come with "images" fields, rather than an "image" field. As a new user to a system all it often takes is one unexpected error early on to send them packing - I know I have done that myself. Sorry to be so blunt but I feel like many of us here have expresses our concerns regarding this - either through lots of likes on my posts above about it, or through their own comments. Please accept these comments in the spirit they are intended, which is to help make PW easy for beginners to fall in love with.

Ryan has just modified all included site profiles to turn on the functions API by default although I am not sure why the change wasn't made in the wire/config.php file so it works for all profiles even if they come from another source - I am sure I am overlooking a good reason though. Regardless I still don't like the mix of approaches used in those examples, but that has been discussed above ?

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