Jump to content

PW 3.0.42 master + ProDevTools released

ryan

By ryan,
in News & Announcements

 Share

Recommended Posts

apeisa Hero Member

apeisa

Posted
Posted

Congratulations on release Ryan! Yesterday I spent some time to browse the API Explorer on demo site and I have to agree that ProcessWire documentation is top notch! Huge improvements over what we used to have and way ahead of most projects.

  • Like 9
Link to comment
Share on other sites
microcipcip Full Member

microcipcip

Posted
Posted

@ryan I have a suggestion regarding the Roadmap. Why not providing a REST API as a pro module or in the core? Headless CMS are on the rise and there's a huge market of Front End developers (Angular, React, VueJS) that would love this. Caching and JWT auth integration would also be appreciated. At the moment setting up a REST API requires a little bit of set up, which may be trivial for a PHP developer but a little difficult for a Front End developer. For example looping all fields, by default won't show image fields or repeater fields, you have to add specific code to get them properly.

  • Like 12
Link to comment
Share on other sites
szabesz Hero Member

szabesz

Posted
Posted (edited)

Hello ProcessWire community,

Here is my proposal:

“ready-to-go profiles”

Why more than one? Why not put all the effort into a sort of “standard” way of implementing the frontend. Something that is a versatile and officially supported way of building a site profile. Of course, it should not be forced upon anyone, so that the “blank profile” is always there for those interested.

I’m not proposing to change the current philosophy, rather I suggest that we add an additional layer on top of it.

There could be only two site profiles that comes with the system: blank and “community”.

This so called “community” profile should be:

  • Updatable by site owners in an automated fashion just like modules with the ProcessWireUpgrade module.
  • Hookable, so that part(ial)s of it can be removed and added, meaning it can be changed to one’s needs in a way that is supported by the core.
  • Well documented so that others can easily use it, contribute to it, and can implement custom “widgets” and/or partials that can be used by anyone.
  • These so called ‘Widgets” (template partials / blocks / whatever we call them) would need to implement a standard interface so that the Widgets can be wired into the system no matter what sort of Templates and Fields are used by the backend. With a little bit of code (writing the proper selectors, etc..) the widgets could be wired up to the system, in an officially supported and documented way.
  • This profile would come with standard blogging and portfolio-site like tools already implemented, ready to be used and extended.
  • Any of the implemented features should be easily disabled, as opposed to all the “junk” that comes with WordPress for example (where implementing hooks are required to remove things like RSS, oEmbed, emoji, etc...) If there are features like these, site owners should be able to turn them on/off, nothing should be forced upon them.
  • This site profile should also support something similar to the Css Zen Garden philosophy, so that not only widgets/blocks can be added/removed, but the profile can be “skinned”. These skins could be interchangeable.
  • It would be multilanguage with features suggested by Adrian.

To summarize: by working on only one but a versatile and updatable site profile, the whole ProcessWire community could add their bits to it, finally there could be a standard to which one can optionally adhere to.

The backend could utilize the very same/similar methodology, so that the community site profile and the admin share the same grounds.

It was already mentioned that the backend might introduce UIkit, so this site profile should be built upon it too. For example, imagine being able to utilize the ProcessWire form API on the frontend, fully supported by the site profile’s css framework! Those who use this “community” profile (or any other UIkit based profile they implement) could optionally share UIkit with the system too.

I am one of those who would mainly stick to such a profile :) but it is easy to see how this would help beginners and professionals, and the ProcessWire project too.

Cheers :)

Edited by szabesz
typos and "added multilanguage"
  • Like 5
Link to comment
Share on other sites
bernhard Hero Member

bernhard

Posted
Posted

the sad thing is i do not expect to get an answer here as i put some time im my last post and did not get an answer either...

anyway, from the roadmap 2016:

Quote

Client-side image resizing. This will enable images to be resized before upload. This will be particularly handy for cases where clients are uploading giant photos that are time consuming and/or impossible to resize server-side.

Front-end JS $pages API. Something that's been on my wish-list for awhile is to have the ProcessWire $pages API available at least in a read-only state to front-end Javascript (and perhaps more API variables). I think 2016 is the right time for this, but we'll see.

what about the client side image resizing? that would be REALLY helpful in many of my projects...

i'm still voting for a rock-solid image handling field. like cropping in predefined ratios and so on. that's an often discussed topic and i don't think that horst's awesome cropping module is the best solution... in my opinion it still feels like a workaround and not like processwire awesomeness...

but of course many many thanks for all the great work that lets me have so much fun in my everyday work :)

  • Like 10
Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
  • Author
Posted
Quote

I have a suggestion regarding the Roadmap. Why not providing a REST API as a pro module or in the core? Headless CMS are on the rise and there's a huge market of Front End developers (Angular, React, VueJS) that would love this. Caching and JWT auth integration would also be appreciated. At the moment setting up a REST API requires a little bit of set up, which may be trivial for a PHP developer but a little difficult for a Front End developer. For example looping all fields, by default won't show image fields or repeater fields, you have to add specific code to get them properly.

What you are describing is already what PW is for the most part. Though maybe there's additional helpers that could be added to support the front-end developer as you mentioned, I'm not sure. But what simpler context for a REST API could you have than what PW already provides? My experience has been that this kind of module is counterproductive – I deleted the web services module I'd built awhile back because I thought it costed people time rather than saving it. Maybe what's needed is a guide showing you how to implement a simple REST API on your own, without any module, since PW already makes it easy. But I appreciate your comments and will certainly look further into both options. 

Quote

Why more than one? Why not put all the effort into a sort of “standard” way of implementing the frontend. Something that is a versatile and officially supported way of building a site profile. 

That's basically a theme – what WordPress, Drupal, etc. are for. :) I'm not against the idea as something for us to collaborate on as a community, but from the core standpoint, it's the opposite of what the core aims to provide. Great ideas regarding the "community" profile, and I think it makes a great community thing, just not a core thing. I don't want to blur the line between PW and platforms like WP, Drupal, etc. Though I do think it's good to show that PW can do these things too. But if we had community efforts like this (and more diversity of profiles separate from it) the core really wouldn't need anything other than a blank profile. Though until that time, I do still think it's good for the core to demonstrate the diversity of output possibilities at the simplest level.

Quote

the sad thing is i do not expect to get an answer here as i put some time im my last post and did not get an answer either...anyway, from the roadmap 2016:

These are still on the roadmap and have been for awhile. What gets implemented depends on resources, but front-end image resizing seems like it's got good potential for the near future, while front-end $pages API may take longer (but I still hope to accomplish that for 2017). Chances are I won't be the one developing the front-end image resizing stuff, as the ideas were brought in by another person, and I know little about it. But it is also one of the features that gets me very excited, so hopefully we can get some momentum going on this soon.

 

  • Like 8
Link to comment
Share on other sites
szabesz Hero Member

szabesz

Posted
Posted (edited)

Thanks for the reply Ryan!

30 minutes ago, ryan said:

That's basically a theme – what WordPress, Drupal, etc. are for.

Well, it certainly points in that direction, however I was trying to explain something different which should fit ProcessWire better (in my opinion, of course...). Although this sort of “standardized community profile” could be ready to be used out of the box, most of it would be customizable by developers and “brave enough site owners” only (who dare tinker with code), meaning it should mainly provide code level interfaces (for blocks), hooks (to add and remove blocks), etc... I called them widgets, but let’s call them blocks (or whatever) if it is misleading.

By providing a solid starting point for non-developers, more beginners or simple bloggers could choose ProcessWire which would boost the user base, but that in turn should attract more developers too.

Edited by szabesz
typo
  • Like 1
Link to comment
Share on other sites
Craig Sr. Member

Craig

Posted
Posted

I can see the REST topic being split into its own thread, but on that subject here are some of my own observations/notes based on some recent projects.

  • URLs: Generally, lots of them are needed. This either means lots of pages/templates to keep track of, or implement routing logic in a template and call other classes/functions/modules as required.
  • Content Type, Input Method and errors: Detecting and responding correctly to content type headers has to be done manually - or just ignored, and respond with your chosen format. This is generally OK, but uncaught exceptions or errors will just show HTML instead. Sometimes it's necessary to implement DELETE and PUT HTTP methods as well.
  • Input data: PW doesn't allow deeply-nested arrays/objects (WireInputData@cleanArray) which has proven problematic. Slightly related to the above point - but sometimes data is sent as regular encoded form data, and other times it is JSON or XML in the raw PHP input body. 
  • Returning objects: sending page data means creating arrays and specifying exactly should be sent. For text/number fields it's not too bad, but is much more involved when images and Page fields are used. My solutions for this range from implementing toArray() methods/hooks, right up to third party library  http://fractal.thephpleague.com/.

 

  • Like 3
Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
  • Author
Posted
Quote

By providing a solid starting point for non-developers, more beginners or simple bloggers could choose ProcessWire which would boost the user base, but that in turn should attract more developers too.

Makes sense, thanks. While I think PW core needs to remain kind of independent of a specific theming system, I do agree more options here would be helpful if we had some ways for the audiences you mentioned to be able to get up and running without delving into development. It's not just a matter of those audiences, but also could be helpful to us on projects where we don't really have much of a budget to work with, but just need to get something up and running without having to resort to WP, SquareSpace, etc. So I definitely support the idea of community profiles like this. But of course the foundation of PW's core is that it doesn't produce front-end markup. Site profiles are independent of the core, so it works well that way. The core shouldn't adopt a particular front-end theme strategy, but if one evolves on its own through the community I think it'd be beneficial for sure. 

What I was alluding to in the blog post is that in the short term, PW would benefit from having a few more site profile installation options from the get-go. The current "beginner", "intermediate" and "languages" profiles are focused more on developer skill level rather than "what kind of site do I want". And the "classic" profile is so old it needs to be dropped. I think we'd be better off with options like these:

  • basic beginner site(s) for learning (like the current profiles)
  • business/corporate site
  • multi-language site (business/corporate?)
  • blog site
  • brochure site (single page on the front-end?)

Maybe some other options would be worthwhile too, these are just the first that come to mind. But the point would be to have more starting points that are closer to what someone's looking for in terms of their actual needs. Rather than being bare bones like the current site profiles, these would be attractive sites in their own right (hopefully as a result of the great designers we've got in this community). Maybe a community profile would even evolve as a part of this process. 

Quote

URLs: Generally, lots of them are needed. This either means lots of pages/templates to keep track of, or implement routing logic in a template and call other classes/functions/modules as required.

I've always done it with just one page and template file as the controller utilizing $input->urlSegmentStr (or individually) for specifying actions and query strings for specific key/value things. This keeps it simple. Of course it may pull in lots of other pages, but as for the service itself it usually needs nothing but a single page and template. 

Quote

Content Type, Input Method and errors: Detecting and responding correctly to content type headers has to be done manually - or just ignored, and respond with your chosen format. This is generally OK, but uncaught exceptions or errors will just show HTML instead. Sometimes it's necessary to implement DELETE and PUT HTTP methods as well.

Usually when people are building a web service, they are trying to accommodate some specific need. So a lot of these details become irrelevant when building something to answer to the need. If building a full blown REST API, then yes it gets complicated because you have to account for anything that anyone wants to do. But this doesn't change the reality that building a web service for a specific purpose in PW is incredibly simple, and probably more often simpler than even configuring a full flown REST API, if it existed. Showing the right content type when an error occurs is a given, so yes one shouldn't leave uncaught exceptions, of course. I might not have understood what you meant on that. 

Quote

Input data: PW doesn't allow deeply-nested arrays/objects (WireInputData@cleanArray) which has proven problematic. 

Using PW's $input var does not override using PHP's $_GET or $_POST vars. Honestly I use whatever is more convenient in a specific instance. Most of the time I prefer $input, but if need something outside the scope of $input then of course I go to PHP's superglobals. There isn't really a major benefit to using $input unless you are chaining it with a sanitizer method at the same time. Years ago, portable coding around these superglobals was annoying because you had to determine if PHP was messing with the data, like adding slashes to input. You don't really come across this anymore. PW's $input is not meant to replace the superglobals, it's meant to provide an alternative to them that may be more convenient in many cases.

Quote

Returning objects: sending page data means creating arrays and specifying exactly should be sent. For text/number fields it's not too bad, but is much more involved when images and Page fields are used. My solutions for this range from implementing toArray() methods/hooks, right up to third party library http://fractal.thephpleague.com/.

This is again a reason why I like the simplicity of building services to fit the need. I fully support a REST API in PW, but am just not convinced it would save anyone time except maybe non-developers. Like you mentioned above, PW has quite a diversity of possible data types, and always will (since Fieldtypes are modules, and anything can be installed). So a REST API that accommodates anything could become quite complicated. All the while, web services for specific needs remain one of the simplest things to build in PW. The biggest benefit of a full REST API in PW as I see it would be for marketing, for having a box to check, etc. And I can't argue with that. :) 

 

 

  • Like 8
Link to comment
Share on other sites
bernhard Hero Member

bernhard

Posted
Posted
28 minutes ago, ryan said:

But this doesn't change the reality that building a web service for a specific purpose in PW is incredibly simple, and probably more often simpler than even configuring a full flown REST API, if it existed.

i guess a blog-post with a good tutorial about how to create the most simple rest api and then, in the next steps, adding things like error handling and authentication and so on could help a lot for bringing in light to this topic :)

there's already the great tutorial of @gebeer , but i guess that's not what looks "incredibly simple" to the eyes of someone who does not have a dev background...

 

  • Like 3
Link to comment
Share on other sites
szabesz Hero Member

szabesz

Posted
Posted
29 minutes ago, ryan said:

I do agree more options here would be helpful if we had some ways for the audiences you mentioned to be able to get up and running without delving into development. It's not just a matter of those audiences, but also could be helpful to us on projects where we don't really have much of a budget to work with, but just need to get something up and running without having to resort to WP, SquareSpace, etc.

I couldn't have said better myself :) This was the most important message I was trying to get through but I had been lost is some details, I suppose.

31 minutes ago, ryan said:
  • basic beginner site(s) for learning (like the current profiles)
  • business/corporate site
  • multi-language site (business/corporate?)
  • blog site
  • brochure site (single page on the front-end?)

Generally, the more options we have the better, but there is one thing that generates unnecessary extra work and that is being "non-multilanguage". By implementing something like this in the core, the question of "should it be multi-language or not" could be eliminated:

While we are at it, @adrian's Admin's Restrict Branch module is based on similar principles, so maybe both could find its way into the core.

Anyway, since the ProcessWire community mainly comprises developers who are already fine with the own way of building frontend from "scratch" (probably they use their own base profile or equivalent boilerplate), it is hard to see that without you leading the way such a community effort could be successful. Judging by the low number of responses to my proposal, current developers are not too interested...

  • Like 1
Link to comment
Share on other sites
LostKobrakai Hero Member

LostKobrakai

Posted
Posted

I think in terms of building apis people just look at things like laravel which come with everything included: router, automatic post data parsing for json, rules where to put files and so on. Some things are nice to have like the automatic parsing of json if the post data come in as content-type: text/json, while in case of routing I'd keep that one for people to install manually. There are great 3rd party routers out there, so no need to have one in ProcessWire by default.

  • Like 1
Link to comment
Share on other sites
microcipcip Full Member

microcipcip

Posted
Posted
Quote

i guess a blog-post with a good tutorial about how to create the most simple rest api and then, in the next steps, adding things like error handling and authentication and so on could help a lot for bringing in light to this topic

This is not a bad idea, I'd like to see a tutorial/guide of how to implement a REST API with common best practices and possibly the correct way of getting the image/repeater fields and show how to use query selectors with limits, pagination etc.

  • Like 2
Link to comment
Share on other sites
bernhard Hero Member

bernhard

Posted
Posted
On 27.11.2016 at 6:52 PM, ryan said:

front-end image resizing seems like it's got good potential for the near future

maybe if you look into this in detail i think it would also be nice addition to be able to paste images directly from the clipboard. this is a nice timesaver when uploading screenshots (for support or the like). but it's not a necessity... whereas i think client side image resizing is :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...