PrevProcessWire 2.7.1 dev + coding style guide
This week we bring you ProcessWire 2.7.1 dev and introduce the new ProcessWire PHP coding style guide! More
ProcessWire 2.7.1, 2.7.2 + 3.0 alpha-3!
This week we've got three new versions of ProcessWire out there, 2.7.1 master (stable), 2.7.2 dev, and 3.0 alpha 3 on the devns branch, where we've got some particularly interesting developments.
- We are now running ProcessWire 3.0!
- ProcessWire 2.7.1 master
- ProcessWire 2.7.2 dev
- ProcessWire 3.0 alpha-3
- ProcessWire 3.0 adds front-end editing capabilities
- Happy Thanksgiving
We are now running ProcessWire 3.0!
We're happy to report that this site (processwire.com) is now running ProcessWire 3.0, and everything is purring along smoothly.
We didn't update any of our template files or modules for 3.0. We just replaced the /wire/ directory and /index.php file and that's it. Meaning, all of our template files, and all of our 3rd party modules (and we have a lot) are getting compiled for 3.0 support by ProcessWire 3.0's file compiler, without any issue at all.
The next time we do a redesign here, we'll upgrade everything to be native 3.0 (and use namespaces), but it's satisfying to know that you don't have to. In our case, the upgrade to 3.0 turned out to be just as easy as the upgrade from 2.6 to 2.7.
This site is the first production site that I've upgraded to ProcessWire 3.0, but I've got several development sites that I have already upgraded from 2.x to 3.0, with identical results. As a result, I'm starting to feel good about the stability and reliability of our new version, though we no doubt still have a lot of testing to do. But things are looking good for 3.0!
ProcessWire 2.7.1 master
This version replaces version 2.7.0 master/stable. It contains several small fixes and improvements relative to 2.7.0. If you are already running 2.7.0 we recommend the upgrade, though it's also not urgent. Here's a summary of what this version has relative to 2.7.0:
- Support for IDNs (international domain names) in URL fields and in the
$sanitizer->url()method. - Upgrade to Lister to enable sorting by subfield (when applicable).
- Fix for InputfieldSelector when using multiple datepicker fields.
- Fix for orphaned rows of data in field tables when removing fields from templates having fewer than 200 populated pages.
- Upgrade "check field data" in ProcessField to support detection and removal of orphan data per the previous bullet.
- Fixes to some 'requiredIf' field dependency issues.
- Add support for
page-edit-imagesoptional permission to enable access control to the image editor. - Fix
Pageimage::maxSize()method that wasn't always working as intended. - Fix issue that prevented Pages > Add New menu from appearing in some instances.
ProcessWire 2.7.2 dev
The updates on 2.7.2 dev are relatively minor coming from 2.7.1. The main difference is that it backtracks a bit on the bookmarks feature for "Pages > Edit" and "Pages > Tree" that you see in your top navigation.
These features can be genuinely useful on large ProcessWire installations, but are unnecessary elements on many others, especially smaller installations. Rather than having them always visible, they now are hidden by default, but can be enabled from the ProcessPageEdit and ProcessPageList module config screens. When you install 2.7.2, you will no longer see the "Pages > Edit" and "Pages > Tree" navigation items unless you enable them in each module's settings. I think this helps to keep things more simple, which is always a goal for our admin interface.
This is an update I think we should have in our official stable version of 2.7, but rather than putting it into this week's 2.7.1 version, I wanted to test it for another week on the dev branch before migrating to the master branch.
Note that this doesn't affect the similar bookmarks features available for "Pages > Find" and "Pages > Add New". I think those are useful in all installations, so they will be left as-is.
ProcessWire 3.0 alpha-3
The alpha-3 version of 3.0 primarily makes the same upgrades and fixes to 3.0 that appear between 2.7.0 and 2.7.2. It also continues with improvements and optimizations to the file compiler and other 3.x-specific features. This version also makes numerous updates to the README file to reflect the simpler upgrade process, as well as the deprecation of 2.x compatibility mode (a mode which thankfully turns out to be completely unnecessary).
ProcessWire 3.0 adds front-end editing capabilities
Note: after this blog post was written, there have been several improvements, changes and refinements to front-end editing, so some things have changed relative to the information below. See this follow-up post for more up-to-date information on front-end editing as well as our front-end editing documentation page. Front-end editing is now available and ready-to-use on the ProcessWire 3.0 (devns) branch.
Our philosophy for editing content has always been that it should be edited in an interface intended for that purpose. The front-end of a site is primarily for outputting content rather than inputting it, and the what's best for output is rarely best for input and management of content. Whereas the back-end of the site (admin) is built specifically for managing and inputting content. It also ensures that editors stay focused on the actual content rather than styling of that content.
…and yet there are those times where I spot a typo on the front-end and I want to fix it right there, before I lose track of it (especially in something like this post). And there are also those times where I'm working with a unique site design that seems like a few parts might lend themselves well to front-end editing… at least for some of the text blocks (like title and body). There have also been several instances where I know front-end editing would not be the best, but wished I had it for eye-candy purposes, potentially helping to seal the deal on a new project.
Even if I don't think front-end editing is suitable for most cases, I also can't deny that there are many cases where it is definitely a nice-to-have. ProcessWire aims to be the most flexible system out there, and part of that flexibility means supporting a diversity of input scenarios. So front-end editing is something that I think we should support as an option. Yet, ProcessWire doesn't control the front-end markup at all (you do), so it's not as straightforward of a thing to support as it might be other platforms out there.
A little surprise
Still reading? If so, I've got a little surprise for you. The version of ProcessWire we're using here fully supports front-end editing (and saving), and I'll be pushing this version to the 3.0 (devns) branch within the next two weeks, with the alpha-4 version.
Some more details
I looked into some existing solutions to build from, but in the end decided to roll our own using html5 "contenteditable" attributes and CKEditor. I think most of the value in front-end editing comes with fields that be represented by text, number and textarea types. That's because their output tends to be very similar to their input, and they don't necessarily need a supporting administrative interface to be fully editable. Rich text editing may be an exception, but CKEditor's inline mode is also exceptional – it's just as happy running on the front-end of a site as it is on the back-end. And when it's running on the front-end, you can edit your content in its exact context and appearance (which is cool, though maybe not the best for keeping editors focused purely on content). You can also manipulate images and links just like you can in the back-end.
How does it work?
When configuring a field (Setup > Fields), on the "Input" tab you have a new option to "Allow front-end input?" This appears for text and number fields, or any fields derived from them (like CKEditor). We may support more input types too, but we'll be starting with these, as they seem like the most potentially useful on the front-end.
Multi-language is also supported, so long as you are using multi-language page names. This ensures that you can edit each language content individually as a page, in its proper language context.
Does it require any front-end code?
If usin option A, ProcessWire takes care of it for you. Meaning, your field becomes front-end editable as soon as you check the box to enable front-end editing for that field. You don't have to code for it, unless you want to customize the output (though most of the time you might want to). For instance, if you wanted to make editable fields appear with an icon or a different background color, you could add a couple styles to your existing stylesheet.
A single API function $page->edit() is also provided which enables you to turn on or off the editing capability when you want to. For instance, if you are outputting $page->title in both an <h1> tag and a <title> tag, you probably only want it to be editable in the <h1> tag. So a single API function lets you control that for those cases.
Questions? Please reply in the comments below and I'll be happy to write more.
Happy Thanksgiving
Here in the US we are currently on our Thanksgiving holiday, which is one of the bigger holidays every year. The purpose is to reflect on the things that you are thankful for. I'm incredibly thankful for all of you, the ProcessWire community, and all that you do. Thank you for being here, we have an exciting future!
Comments
NextFront-end editing now in ProcessWire 3.0 alpha-4
4 December 2015 15
This week we've got front-end editing now available for download and testing in version 3.0.1, aka alpha-4. We've also taken them quite a bit farther than what was introduced last week, and this post will be focused on covering all that you can do with it and how to use them. More
Tom
- 8 years ago
- 60
★★★★★Very nice surprise! How about images? I wouldn't mind seeing a quick drag and drop to replace images. (Say a featured header image).
Yet again, another nice to have. I'm sure people could make a very extensive list on what they would like to see front-end editable. But I'm sure you (Ryan & Team) will know where that bar is :-).
Reply
Ryan
Just a focus on text-based fields and rich text (html/ckeditor) for front end, for now anyway. Most of the time images need more dedicated interface. PW focuses primarily on admin interface, leaving front end to you. Front end is not a substitute for a full edit interface, because who knows what's there, anything goes. We do support front-end image upload and manipulation within rich text (html/ckeditor) fields though. For inputs needing more edit interface (like images), we're thinking a front-end modal edit interface may be a good option for us to support though.
Reply
Tom
I completely agree, I think I got a little ahead of myself. (I'm always very excitable after every update).
Images aren't exactly a "oops there's a typo" situation. Then you are approaching a front-end editing philosophy, which let's be honest, many people think they want but end up being really clunky.
I've had nothing but praise about ProcessWires ease-of-use.
I completely agree, ProcessWire should never manipulate the front-end. It's one of the things that annoys me with WordPress and one of my biggest praises for ProcessWire. The fact that the front-end and back-end are completely separate.
I feel silly for suggesting it now.
Keep up the great work guys!
Reply
Jason
Might want to double check how the demo in this post works on touch devices. On iOS Safari, for me, the edit interface comes up every time I touch the page just to scroll down. And that's anywhere in the article.
Reply
ryan
Jason, it was working fine in Android, but sounds like that didn't translate to iOS. I pulled out my iPad and made a few tweaks to support fast double-tap to edit in iOS (slow double tap still zooms). Please let me know if you find it works better now. iOS/Safari seems pretty aggressive with the caching, so you may have to clear cache or open a "private" window to ensure you see the update.
Reply
Mike Rockett
- 8 years ago
- 20
★★★★★Awesome surprise indeed! Have a few clients who are going to love this.
Thanks, Ryan - great stuff, as always. :)
Reply
Ryan
Yes, it can be enabled on a per-template basis. It comes with a permission "page-edit-front" that a non-superuser must have edit fields on the front-end. This permission can be assigned per template on a template's access tab. You could also use the $page->editor(true|false) method to turn editing on or off according to your own custom roles in your templates.
Reply
HerTha
- 8 years ago
- 20
★★★★★Awesome stuff, every week again! What a pace... Thanks Ryan!
Reply
Renobird
- 8 years ago
- 00
★★★★★Very nice surprise! Can front-end editable be set on a per-template basis? I have a lot of multi-purposed fields, and can think of a few instances where I would want to allow front-end editing of a field, but only in the context of a particular template.
Thanks for the 2.7.1 updates, a few of those were particularly important for us.
Reply
pwFoo
- 8 years ago
- 10
★★★★★Thanks Ryan! :)
Reply
muchdev
- 8 years ago
- 00
★★★★★Woah! Frontend editing would be so cool!
Reply
Marcel M.
- 8 years ago
- 20
★★★★★A dream come true! For some clients the optimal usability solution. Processwire has changed my Frontend-Developer (UX-Designer) life. It's so flexible, thanx, Ryan!
Reply