PrevA stocking full of $pages updates with ProcessWire 3.0.46
This week, the big stuff is between you and Santa, but what we do have are lots of useful stocking stuffers for you to enjoy in ProcessWire 3.0.46! More
2017 roadmap, 2016 recap & more
Happy New Year! Looking back over the last year, it's been a really great year for the project, and wow has it gone fast! In this post we'll look back at some of what we've accomplished over the last year, and–more importantly–introduce and review our 2017 roadmap. Today we've also released version 3.0.47 dev, which doesn't add anything new feature wise, but does contain several optimization and bug fix comments.
- 2016 was a great year for ProcessWire
- What’s in store for ProcessWire in 2017?
- Less talk, more results
2016 was a great year for ProcessWire
Most of the development time in 2016 went towards preparing ProcessWire 3.0, and we released this new version, which has been a very successful release. More about what's new in ProcessWire 3.x can be found here. Going from 2.x to 3.x, version 3.0 was the first major version release in ProcessWire's history as an open source project (not including the first open source release), and likewise represents a major highlight of the year.
We released 44 dev branch versions of ProcessWire 3.x in 2016. Meaning, close to one new version per week for the entire year!
ProcessWire finally got major media coverage in 2016, and they had a lot of nice things to say! Thanks to people like Francesco Schwarz, Ben Byford and others who have written great articles on ProcessWire, the word is getting out. We've appeared on some of the best web design/development related websites including tutsplus.com, smashingmagazine.com and others.
Documentation has been another major theme of 2016 with a lot of time investment. ProcessWire's code documentation has been improved by leaps and bounds, and a new API reference was introduced that serves as a strong and comprehensive reference of ProcessWire's API.
Repeater fields have had a lot of love in 2016 with multiple major updates (the last month included too). We also introduced perhaps our most powerful field: ProFields Repeater Matrix.
People have been doing awesome things with ProcessWire in 2016. Looking through our sites directory and showcase forum, we see more and more amazing examples of what people are creating in ProcessWire and… I'm always speechless, it's beautiful. This has been particularly apparent in 2016. The designers and developers using ProcessWire are the most talented and skilled people in the world, and we are so proud to have you as part of the ProcessWire community.
We've had a new edition of the awesome ProcessWire Weekly to read every week. Huge thanks to Teppo Koivula for this, it is a true highlight of the week for me and I'm sure most of you – ProcessWire Weekly.
We switched to a new GitHub repository that's more relevant and fitting for the project. Our new repository is a GitHub organization account that supports better collaboration with separate issues and requests repos, and enables us to assign more people to assist in these areas. With a new repo and new contributor guidelines ProcessWire has become much more of a collaborative effort in 2016. This will continue more and more in the years ahead.
The outstanding community continues to be the best thing about ProcessWire. Big thanks to all of you for being part of ProcessWire and doing such awesome things with it.
What’s in store for ProcessWire in 2017?
2017 is going to be even better than 2016! While it's impossible to cover everything we might do in 2017 here, we've put together a list of some of our bigger priorities for the year ahead:
open_roadmap2017
New admin theme. While it's been mentioned in previous blog posts, this roadmap would not be complete without mentioning it here. An areas of focus will be developing a new admin theme that takes the best of the Reno and Default admin themes, and goes further. We aim to replace our current default admin theme. In doing this, we'll also be standardizing ProcessWire's front-end class namespace to use the "pw-" prefix (in cases where it's not already using a module name or type prefix). We'll be simplifying a lot on the CSS framework side of PW's admin as part of this as well.
New bundled site profile(s). This one was also mentioned in a previous blog post, and will be a high priority for 2017. At minimum, we'd like to drop the Classic profile that currently comes as an installation option, and replace it with a common CSS framework profile. We'd also like to have a bundled blog profile, which may be one and the same as the common CSS framework profile, or something different (we'll see). Regardless of which way it goes, we want to make sure that when someone installs ProcessWire for the first time, they have something that really shows off what's possible and inspires them to want to dig in to see how it works.
Continued upgrades to our image and photo handling tools. We're continuing to look at support for predefined crops, and client-side image resize support, both of which we think may be possible to bring to the core in 2017.
Custom properties for image/file fields. Currently file and image fields just support description and tags options as meta data to accompany a given file or image. We'd like to move towards supporting additional custom inputs for these types.
New website. A lot of nice redesign work was done by the community over the last year or so. In 2017, we'll be moving forward with developing it and making a lot of nice improvements to this website.
Continued performance and security optimization. This is one I repeat in every roadmap, and goes without saying – we are always driven to make ProcessWire the fastest and most secure CMS out there. We will continue to optimize performance and security in every way possible and are always looking for opportunities to do so.
Front-end JS $pages API. This continues to be on my own wishlist, though it's rare that I hear from others that want it. But I think a read-only, front-end Javascript API of ProcessWire's $pages API variable would be really handy for a lot of cases, and so I'm going to continue to keep this in our roadmap.
Tools for exporting and importing of pages. We've got some nice built-in tools for importing and exporting of templates and fields, but not yet for pages. Over the coming year, I'm hoping to add page import/export as well. I'd like to be able to copy/paste a page or group of pages from one server to another.
Expanded image capabilities in CKEditor. Currently when you want to use images in CKEditor, there must be an images field on the page, and you have to upload an image to that field before you can use it in CKEditor. We'd like to optimize this process so that: 1) if there's no images field on the page, it falls back to a predefined common images/gallery page; and 2) these common images/gallery pages would also be available as bookmarks in the "insert image" dialog; and 3) you can drag-and-drop images directly into the CKEditor field, and they will upload to the appropriate location automatically.
More multi-language fields. Currently the core includes multi-language text, textarea and title fields. Multi-language is also supported natively on some more the more complex fields as well. However, there are a few gaps yet to fill, like multi-language URL fields for example. We will cover any remaining gaps here in 2017.
Support for markup regions. This simple template file strategy takes the best of direct output and delayed output, and enables even simpler communication between multiple template files by using the markup you already write. This makes template files easier to understand at a glance, reduces verbosity, and enhances what you can do with output.
Continued Pro module upgrades. 2016 saw the release of new Pro modules (RepeaterMatrix, ProfilerPro, ProcessWireAPI) and upgrades to most of the Pro modules. In 2017, we'll continue to expand upon the ProFields and ProDevTools sets of modules, and release major upgrades for FormBuilder, ProCache, ProDrafts and ListerPro. The next major upgrade is coming for ProDrafts with support for repeaters, workflow and more. A huge thanks to all of you that are supporting ProcessWire by purchasing (and renewing) Pro modules – this is what makes ProcessWire sustainable as an open source project, and it's what enables me to put my time towards developing ProcessWire and less towards other client work. Your support is greatly appreciated.
New cheatsheet. With our new API reference now fully up-to-date and running smoothly, we'll be working to make it drive the cheatsheet site as well. We're not yet sure if we'll be integrating it into the existing cheatsheet or re-developing parts of it, but we do know that Soma's cheatsheet has been awesome and essential, and getting it up-to-date with all that PW 3.x offers is a priority for 2017.
Chances are we'll be covering a lot of stuff that doesn't appear above, as that's how it always works out. But these are our best projections for the moment. With ProcessWire 3.x we've got the best product out there (in our humble opinion), and we'll emphasize making it even better in 2017.
close_roadmap2017
Less talk, more results
In 2017, as you've seen above, we'll be focusing on some projects that don't fit quite as neatly into 1-week blocks – things like new admin theme, site profiles, new website and more. Currently, most of my time goes towards preparing everything into weekly version packages and blog posts, and that takes up most of the week. I love the weekly format and schedule, and it's great for momentum. But also recognize that timeline drives where the attention goes, rather than what needs attention. Bigger updates get pushed back because they can't as easily contribute to a weekly version or blog post.
I've been thinking it would be good to experiment with putting more focus on those bigger multi-week updates, where I won't necessarily have enough new ready-to-use code or content to push for a new version or blog post on a weekly basis. So in 2017, I'll be reducing the frequency of our version and blog posts a bit so that we can drive more attention towards bigger picture stuff on the ProcessWire project, and take things to the next level.
I'll be aiming to have 2-3 versions and blog posts a month (sometimes 4), rather than always 1 per week. When it comes to the blog posts, if we've got more guest authors that would like to participate, that would be welcome too. I do plan to return to the once per week (or more) frequency once we've covered some of the bigger projects on our 2017 roadmap.
As a side note, I wanted to mention that quite a bit of time this week went towards continuing development on the ProDrafts support of Repeater and RepeaterMatrix fields. I now have it functional, though still have a lot of testing to do, as there are lots of different cases to cover with Repeaters. But for those that have been asking for it, I did want to let you know you'll definitely be seeing this, and likely very soon.
Happy New Year! I look forward to a great 2017 with you and the whole ProcessWire community!
Comments
NextProcessWire 3.0.48 core updates
6 January 2017 1
This post includes coverage of the latest weekly core dev version, an update on ProDrafts, and more. More
Joe Regan
Really excited about this road map! Love the javascript api plan, keep it high! And the export and import pages! Very needed.
Custom properties for image/file fields, yes! I can have one for url link now if I make a slider and not be forced to use a repeater for an image with link and caption.
Love the image library also. Using a module for this now, but would be great to have it in core.
I would like to be able to have user file uploads saved in s3 so my ssd server doesnt fill up so fast with large pdfs that are rarely used! But other than that, thanks for all the hard work!
Reply
Can
- 8 years ago
- 10
★★★★★totally agree with you joe!
as far as i know procache is capable of outsourcing assets to aws..
happy new year to all of you =)
Reply
Joe Regan
Doesnt it store on both places though? I am not sure it would save space on my ssd server. If it only goes to s3, that would be awesome!
Reply
Can
that i actually don't know..better ask one of those using it ;-)
better place would be the forums as the blog is not really supportive in this regard..
Reply
ryan
I wasn't really thinking of an image library, so if you are using a module for that you'll likely want to keep doing that. But for those using the current built-in system to approximate an image library, plans for the core are to make it a lot more friendly to that. For instance, default location for CKEditor image upload or selection, when the page doesn't have an images field. And bookmarks for pages that are used in this manner, so that the user doesn't have to locate the resource page(s) themselves using the current PageList inputfield that's present in the dialog.
I definitely like the idea of storing files on s3, but I have trouble imagining that more than 5% of installations would actually use the feature. Meaning, I'm not sure it belongs in the core, and may be more appropriate for a module. But if there's any additions that need to be made to the core in order to support it in a module, it would certainly be worthwhile.
Reply
Joe Regan
That makes sense. I have heard it may not be possible with out some core changes, to get the admin side to check in another location, but i am not sure. I saw it discussed in the forums though.
Reply
thetuningspoon
Ryan, this would still be using ajax to retrieve the data for each js $pages operation, right? It would just be resolving the js call to the equivalent php call behind the scenes and returning a json object? Seems like this could be very handy in some cases, though in others it would probably lead to more server requests than would be ideal. Also have to be mindful about security, as has been mentioned.
Reply
tpr
This was a great year for PW and hopefully the next will be even better!
As for the roadmap the new admin theme could perhaps include some features of the AdminOnSteroids module - feel free to use the ideas or even code though I'm sure most of them could be done better.
http://modules.processwire.com/modules/admin-on-steroids/
Reply
Szabesz
Bulma looks promising, but I vote for UIkit instead :) Both for the admin and the bundled site profiles.
Reply
Mike Rockett
- 8 years ago
- 70
★★★★★Yeah, UIkit is great - can't wait for v3!
Reply
ryan
Well I think any web service API would probably count as doing this. While I'm not aware of anybody else doing this in quite the same way, it amounts to JS read-only access to a database, which isn't anything unique. You can already do this with PW pretty easily. But what we would be doing is just taking the API that's already familiar to our users, and making it available to them from the JS context as well. That would make things quite a bit simpler on the JS side than they would be without it. Like you mentioned, it would have some potential uses in our admin environment as well.
Reply
Holly Valero
If you're looking for a CSS framework that's less bloated than bootstrap, foundation, etc. I've started using Bulma http://bulma.io/ ... it's open source, flexbox based, a nice combination of smart, lightweight components ... It's fast and a great complement to the speed of processwire. :-)
Reply
Can
- 8 years ago
- 10
★★★★★same thought :D just dove into the vue world ;)
Reply
Bora
One reason I asked this was the security issue you mentioned, to open something like this to public requires a quite consideration. When we look at the WordPress Rest API example(this has a potential to be more awesome than that), it is for sure it would definitely opens whole new level for PW.
Maybe a good starting point could be admin section implementation of this (starting with superadmin only maybe).
One more question: is there any other cms or framework out there doing this already?
Reply
3fingers
+1 for the JS api, I'd really love to use pw as a data store for, let's say, a Vue.js app. New website! I'm sure it's going to increase pw in popularity a lot, as it deserve.
Reply
AndZyk
Please don't, in my opinion this should be handled by the developer only.
Reply
HC
- 8 years ago
- 00
★★★★★Would really love to see responsive images handled out of the box for the front end.
Reply
ryan
See Joel's message below which has some use cases. Essentially, if you've got a $pages API var in Javascript, you can do most of what you do in your site template files (PHP) from within Javascript as well. Having access to that data without it being based around the usual pageview cycle. Things you might use ajax for in the past, like in-page pagination for example, would be quite a bit simpler to implement.
The biggest challenge to supporting this feature is security. When you use $pages from PHP, it's quite secure in that the source of the API calls is just from you, the developer. When $pages is available as a Javascript API variable, then it means it's accessible to anyone that can see your site and wants to experiment. So the scope of what will be allowed will have to be defined by the developer. Like what page templates and fields can be used in find(), get(), and count() calls, and what include modes are allowed (hidden, unpublished), and rate limiting to prevent DOS attacks, etc. So there are definitely challenges in getting this right, but I think once we've got it right, it'll be a great thing to have.
Reply
Bora
What would be the capabilities of read only JS $pages API? Do you have some use cases in mind already?
Reply
ryan
The Admin themes use SASS/SCSS rather than LESS, but they should still be easy to update the colors for. In the Default admin theme, it keeps all the color definitions in main-name.scss files. In the Reno admin theme, it keeps them in _colors-name.scss files. In both cases, you'd replace "name" with the name you want to use for your color scheme, or modify one of the existing ones. But to keep things simple, all of the color definitions exist in just a single file. To compile the SCSS file to CSS, you can use your own workflow actions, or if you prefer, a shell script is included with both admin themes called compile.sh. For the future admin theme, we'll likely make it even simpler by making it as something that's configurable from the admin theme module settings, if at all possible.
Reply
Joel
- 8 years ago
- 80
★★★★★+10 for JS $pages API. I use Ionic (which is built on Angular) to make mobile apps. The JS API would play perfectly with that. Being able to feed content to a mobile app from the same Admin Area they use to manage their website would be a slam dunk for clients. (I know I can manually create the JSON feeds from PW now, but JS Api in the core would eliminate a ton of boilerplate work).
With a JS API, I can imagine the community creating react or vue or angular components that work out of the box with processwire. Would then be silly easy and fast to crank out mobile apps with this combination.
Reply
Zahari M
Happy New Year everyone PW!
Look forward to "Custom properties for image/file fields" and "Tools for exporting and importing of pages"
I think it's a fabulous idea Ryan you working on things that take longer than a week whilst not needing to update us weekly. Besides, since you have been such a prolific writer there is plenty of material for one to go back in time and re-read again all your earlier weekly blog posts as they contain so much useful info!! I know I do! I'm sure amazing things will emerge :)
Reply
gmclelland
@Ryan - Just a heads up, the multilingual url fields was also discussed a little at https://github.com/rolandtoth/AdminOnSteroids/issues/22
Reply
Bernhard
- 8 years ago
- 00
★★★★★Hi Ryan,
i just had to modify colors of the admin for a client it it was not as easy as all other things in pw :) i thought you could maybe consider to have the new admin theme colorizable? that could be very easy if the admin theme used LESS and a serverside rendering like AIOM does.
happy new year. looking forward to all the awesome things coming up :)
Reply
Yannick Albert
For the JS $pages API, let's get inspired by https://github.com/typicode/json-server ;)
Reply
Trazx
Yay rest API that we can leverage in javascript! (even if its read only)! awesome
Reply
Geoff
I for one would really like to see the JS frontend API!
Reply