StanLindsey

So we're over half way through the year. How are we getting on with this @ryan? I don't see much of a discussion around it? I think this is a really important first step to making ProcessWire part of the larger web development community and really increasing its popularity. (And sales of pro modules!).

Yeah, that doesn't come through on the $input variable, so you'd have to grab it yourself. I've pushed a PR to include it in the $input variable as it makes sense for ProcessWire to support that out of the box. @ryan

@LostKobrakai, @marcus - what about using "json_decode(file_get_contents("php://input"))". That let's you retrieve the raw data from the request body. http://php.net/manual/en/wrappers.php.php

Anybody got a working config for 3.0.x I can steal?

I'm been using VSCode for the last 9 months or so and I love it. I'm mostly a Javascript developer so it does fit in my alley but I've had success with using it with PW. The little circle/refresh symbol in the bottom left allows you to push your changes to Github/Gitlab etc. Or you can use the command palette to "Git Push". Works a treat with Continuous Interaction. There's also a remote FTP plugin which lets you sync which I've used a couple of times on legacy projects.

I've just started using MarkupRegions and I think they are fantastic. It is basically identical to the Delayed Output strategy but you are able to focus on the markup instead of various php variables. Definitely give it a try before you write it off.

Bit of a bump. Ther Api-Docs are great and it is useful that they are built on the dockblocks but that still really limits how far they can go. A site that allows us to bring the core API-Docs, plus the fantastic blogs, tutorials, guides and forum posts would be perfect. All this information is so spread out at the moment its terrible compared to competing platforms.

There are so many ways to skin a cat in Javascript, especially considering how far Javascript has came in recent years. You really don't need jQuery at all. It is also good to learn the Javascript core as to expand your skill set as well as remove a dependency on your project. Some of the posts here are way out of date and verbose. Native Fetch is much better than XMLHttpRequest, and there are some polyfills online if you need IE11 support. fetch('../my-url/', { method: 'post', body: JSON.stringify({ test: response.test }) }).then(response => { return response.json(); }).then(json => { document.querySelector('#output').innerHTML = json.test; }); Read more here: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API And there are a bunch of good basic examples here: https://github.com/mdn/fetch-examples/tree/master/fetch-json

Yeah sorry - went off topic - but that's why I originally asked - if there was any additional functionality included for setting up templates and fields beyond the default APIs capabilities. The migrations module install idea is genius though. Thanks.

I already do this for most of my builds for fixtures but can't find a way to edit the other "data" of a template - the url info or other advanced data.

Can this module set up some templates, fields and pages?

You could also use Url Segments to pull out the image ID from the URL and then pull that out of your specific gallery page you're holding the images in.

That is absolutely feasible. An application doesn't really care where it gets its data from, you just need to send a PWA compliant app bundle down to the client and within that app consume some APIs to get data. Whether that API is on a Digital Ocean, AWS, Linode server, or whether its written in NodeJS, PHP, Ruby, Go or whether its built on top of Wordpress, Magento, ProcessWire doesn't make much of a difference. I'm not sure how familiar you are with PWAs, but if you haven't built one yet I'd suggest you test it out without the ProcessWire part of the stack. If you can build a PWA that consumes the Github API, caches it with a Service worker and displays it offline. Then moving to a ProcessWire API Backend will be dead simple. ProcessWire is fantastic for this sort of headless/API based CMS, So you're making a good choice there

This is the most important thing to me. If we keep having these conversations then let us solve the root cause. How can we as a community help Ryan more? We need Ryan to help us create some frameworks and models for us to help him out. As there is a barrier of entry for us to help him. This framework can then be used for us to achieve whatever we need to (be it website, documentation, pro modules etc), with a sense of direction.

To clarify - if the community at large disagrees with something (e.g. Slack) then its something to put more thought into. The primary reasoning for suggesting it is that its a common and in some ways expected in modern circles. It wouldn't replace the forum. So anybody who doesn't want to be part of it wouldn't have to be. Long form content is much better suited to the forum. It would have to be supported first-party. The PW Slack Channel, "Find us on slack" on the official PW website etc. Not a sub-channel on another team's Slack group that you have to find by searching through the forum posts. Though the sentiment is definitely welcome, it's not about the existence of the thing, it's about the supporting arms around the thing. (Be it Slack, Documentation etc) But quickly - that is one point on that list and not an overly important one. If we can instead discuss the things we really do want instead of the discussion turning towards moot points we'll get more headway in convincing the community. =D