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

I love ProcessWire. @ryan has done such a fantastic job and I'm sure is incredibly proud. I agree with some of the other members here that a goal of 2018 should be better community and project management in order for the community to grow and be part of the larger web development community. We do have our own way of doing things here which is fantastic, and the accessibility of ProcessWire is on point, but I fear we do lack some elements that can position us more, for lack of a better term, professionally. Here is my suggested list of priorities: Long-Term Vision: What is the long-term vision of PW? All the rest of my suggestions are coming from my long-term vision of how I wish to use PW, how I want PW to be seen by my clients and how I want PW to be viewed by other developers. But if Ryan doesn't want PW to get too big, if he doesn't want his role to become more and more of a manager and less of a sole developer role then that is fine. I can see a potential future where PW runs itself, where we have set up a structure for a team to surround Ryan, the community grows and lots of people buy Pro Modules =D New Website & Documentation: First impressions count, a consistent and modern site will help PW look like a real legitimate offering from the offset. Wouldn't it be fantastic if the ProcessWire website was open-source on Github - as the perfect demonstration of PW itself. Documentation needs to be positioned as a source of truth instead of scattered across multiple blog posts / forums posts. The API CheatSheet is great but we documentation also needs to provide standards and methodology for some of the most common solutions people build with ProcessWire. The MeteorJS Docs are a fantastic example - they include a full API breakdown as well as a guide for common areas such as Application Structure, Data management, user accounts etc. https://docs.meteor.com/ Importantly they are open-sourced on Github, so the community can contribute. Project & Community Management: Continuing from the above this should not all be put on @ryan's shoulders. I think much of the website and documentation above can be handled by the community once the initial setup is there. Slack Channel: We're modern so let's have a modern Slack channel. Team Members: Let's take some of the talented members of the PW community and give them a role if they want it. Who triages the Github issues, who can speak on behalf of the PW project that isn't Ryan? One Github Repo for PW: I don't understand the multiple repos for different things. Most projects don't go down that route? Contribution Guidelines: How to contribute to Processwire core. What are the coding standards, what issues can people currently contribute to? Open up the shop: Pro Modules should be available to the public, modules like Padloper should get seen on the PW site - after some requirements are met. Developers should have an easy access to earning from supporting PW instead of just consuming PW. PW should take a tiny cut of sales as well Stability and Modern Practices: If PW is to be part of the larger ecosystem we have to play on some of their terms. There has been great progress with this with Namespaces, and the new Admin theme etc. We should definitely focus on fixing some of the small issues that others here have mentioned and the development cycle. We should definitely be supporting NGINX as a first party citizen. On a side note; is PW unit tested? This is a big thing for larger developers. Anyway, I love ProcessWire but I feel that the community is actually quite fragmented, each of us doing our own thing in our own way in silos where the only commonality is that we consume the same framework. Lastly, @ryan - set up a PW Patreon. I'd happily subscribe in order to help support the development of PW technically as well as the project and community.

Can we set up a Slack channel for Processwire? My key concern is to have ProcessWire stick around and look the part. I want my clients to easily find other devs, see that there is a team and a community behind ProcessWire and have it come across as a modern platform that will solve their business needs.

I really want Processwire to take off and big a bigger player as it's my platform of choice.

@mountbatt - You can go into the module's options and run the compile manually. I've since switched to an NPM based build system; watching and compiling scss, autoprefixing and minifying it.

I agree. I'd really like to be able to support ProcessWire and @ryan much more. We should have a git-backed documentation site. The Meteor Docs, as an example, are built in Hexo and managed on Github: https://docs.meteor.com We can then make sure it is up to date as a community instead of it resting on Ryan's shoulders.

Another reason we need to expand the ProcessWire store @ryan . All these modules spread across different sites - this one is even priced the same way as the official modules.

Where can I find a link to the latest version of the logo & ident? =D

I think the way you were doing it before made sense - using a Page Field Selector. Setup in the page-tree a section called "Components" or "Blocks", make sure that isn't being rendered anywhere, then reference those in a field in your front-end facing pages.

Sounds really good. Would happily purchase. The backend being pre-done is much more interesting to me than the having a front end template.

Ah man, this is awesome. It'll make it a lot easier to use Processwire as the CMS for a front-end not built on Processwire. =D