ProcessWire Dev Branch

[k07n]

Posting this here as I'm using 2.5.17.

If I go to save (I'm not cloning it) a PageTable field I get this error: Unable to clone field because name "" is already in use or is a reserved name.

https://github.com/ryancramerdesign/ProcessWire/pull/898

[alan]

Stumbled on this-see when your log files were last updated, so smoooth. Thanks Ryan/colleagues for this ever-improving fabulous product.

[ryan]

Glad you like it Alan. For some more fun, keep one of those often-updated log files open in your browser, and watch it update automatically to show you the new log entries every time something gets added to it. 

[alan]

Fab challenge accepted! >_<

[ryan]

New dev branch updates for this week:

• Field editor now lets you target templates
• Optimization to field cloning
• Live-updated session viewing tool
• Session cleanup on certain Debian-based servers
• Configurable session fingerprints
• Session history from the API

[horst]

I have downloaded 2.5.18 already an hour ago or so. So, cool to be able now to read everything here what is new!

Thanks Ryan.

[alan]

Thank you very much Ryan; you had me at Field editor now lets you target templates—Fab!

[renobird]

Ryan,

Whatever train you are on -- don't get off. All this new stuff is great! I should just go to bed now (7:00pm here) so I can wake up at 3:00am and check all this stuff out while my kids are still asleep. Of course, that can be risky, one "this rules!" that's a little too loud and I have a one year old up several hours early. That's no picnic.

[OllieMackJames]

anybody know where I can find the iridium profile?

thanks!

[Mike Rockett]

anybody know where I can find the iridium profile?

thanks!

Doesn't look like it's been released yet. Page says it's not in dev branch yet.

[OllieMackJames]

Doesn't look like it's been released yet. Page says it's not in dev branch yet.

tnx mike, too bad

[OllieMackJames]

Today updated one site from stable to latest  dev 2.5.18 no trouble whatsoever, all works great.

Anybody any idea when it is ok run this on production sites?

Thanks for such a wonderful CMS!

[alan]

Other will answer this with more authority than I Ollie, but I have found PW beta to be more stable and robust than some other production s/w. So on occasions I have used beta for production sites, after extensive tests (so far all of which always work flawlessly). It really is a very, very good CMS. Enjoy

[ryan]

Another Friday blog post with core updates just posted. This time we've got several image editing updates, particularly with regard to image editing for images placed in rich text fields. Also included are HiDPI/Retina support, an image variation tool, and more… Read all about it here, plus a video and screenshots: https://processwire.com/blog/posts/new-image-editing-features-2.5.19/

[ryan]

@OllieMackJames my advice would be to use the dev branch for new projects, and the master branch for existing projects. Though I mostly use the dev branch for both. If you use the dev branch on a production site, you just want to make sure it's one that you keep track of and can report any issues if/when you see them. The current dev branch actually has a lot of bug fixes from 2.5.3, so it may technically be more stable in many ways. However, it also contains a lot of new features and code that doesn't yet have as much mileage on it. 

[Pierre-Luc]

Another Friday blog post with core updates just posted. This time we've got several image editing updates, particularly with regard to image editing for images placed in rich text fields. Also included are HiDPI/Retina support, an image variation tool, and more… Read all about it here, plus a video and screenshots: https://processwire.com/blog/posts/new-image-editing-features-2.5.19/

[amazing video]

It's such a shame I can only like this once !

[owzim]

ryan, everything you put out there is so friggin' polished. Outstanding work!

[Soma]

@Ryan, love the new features. 

Regarding inserting images in a RTE, is this something you guys still do? How do you handle it so clients don't mess up? I don't see how that is convenient? I mean if we allow clients to insert images in the Text, shortly after there's a complete mess of images to clean up.

So I'm not sure what to think of the new image features being focused on this?

What we love to see is a image manipulation tool to cut an original image, to then create thumbnails from. Croppable image does a good job, but still missing a cut the original image feature.

[LostKobrakai]

I'm with Soma on this one. I don't like using RTE's as well. What I would really like to see is something like craft is doing:

I can see, that this is a quite complex thing with processwire's pages methodology and PageTables even provides something slightly similar already, but I see it more as a RTE replacement. You'd use it in places where you used only the RTE before. In my opinion such a field doesn't need to support more complex things besides images or textual elements. It would also just save markup for the frontend, while it would probably need to save the different fields somewhere as well. For me it's mostly about the interface. It just guides the user much more, so I would even think it's easier for them to understand, while in the same time limiting the potential points of error.

Edit: I don't fully understand, why there's still a image-icon in the screenshot's RTE.

[apeisa]

I agree. Still think this is most promising open source "block rte": http://madebymany.github.io/sir-trevor-js/

LostKobrakai has been building modules like a crazy: maybe this one next?

[LostKobrakai]

I have. But mostly stuff, that's not as complex as I'm not as comfortable with such big featuresets. I've also "ProcessStitch" on my someday todo-list, the module to drag and drop fields to templates. So I don't think I'll do such a thing in a really near future.

[Pete]

@ last 3 posts - I agree but there are still times where, as long as you trust the person editing to do it properly, this is still okay (although not usually ideal, I agree).

With regards to the craft screenshot and Apeisa's link to SirTrevor - this is the ideal way to handle this and I did actually start to play with an inputfield to accomplish this using SirTrevor but couldn't get it to work properly (I may go back and check it again now I've got more experience).

The idea is simple enough - allow as many image fields and text editors as you like in a single fieldtype (I got that working) and simply have ONE textarea field that stores the order of the elements and the editor content as JSON. That way you just need one multi-image field to store the actual images, and the textarea field stores all the editor contents. A nice little render function would pull the content together to display on the frontend and you're sorted

I think if I revisited it I wouldn't even bother with SirTrevor to be honest and I'd roll my own interface so as to keep the styling in line with the PW admin themes.

[adrian]

Sounds great Pete - please revisit this if you get the time. Like lots of us, I have been using PageTableExtended for this sort of thing, but I would love to see a fieldtype like this - would make it much easier to set up and be better for selector driven searches, and would generally feel cleaner - at least to me!

[ryan]

Regarding inserting images in a RTE, is this something you guys still do? 

Absolutely, I consider it essential. Placement of images is one of many reasons to use an RTE, but it's a big one. Our tools were somewhat lacking in this area before, and that may have even been a reason not to use them. CKEditor is perhaps the Inputfield that our (or at least my) clients interact with the most in PW, and I'm committed to making sure the tools we provide in this area are the absolute best they can be, as with all areas of ProcessWire. 

That doesn't mean you have to use all the features an RTE provides. In fact, I rarely recommend doing that. You may find some features suitable for some situations more than others, and you have control in your field settings to determine what is available. There are some site designs I work with where I'll turn off the ability to insert images at all (or even turn off the RTE all together). But there are also plenty of site designs I work with where that ability is very important to the client or the needs of the site. One of ProcessWire's key benefits is not pushing assumptions about the front-end, or pigeonholing the software into some specific types of sites. We're trying to accommodate a diverse range of needs, not just specific ones. We accommodate specific needs with configuration.  

We've always provided image placement capability in our RTE, but with limited ability to manipulate the image beyond just resizing it. I've been looking to make this part better for a long time for the needs that I see with my own clients. That's what the first paragraph of the blog post was trying to explain. Beyond that is selling PW itself. It's one of those things that users look at when evaluating a CMS. Regardless of what you may think about RTEs in general, lack of RTE is a deal killer for many/most, and how good the RTE and related tools are is a seller. Look at WordPress, which is limited relative to PW in so many ways, but their tools like the one discussed here have always been significantly better than ours. ProcessWire has very little in common with WordPress, but when compared side by side for editing features, things like this make WordPress look better to the casual evaluation. This is one reason why you see WordPress used in so many inappropriate scenarios. So when it comes to tools that we provide already, I want to make sure they are the best they can be, and not just half way. 

How do you handle it so clients don't mess up? I don't see how that is convenient? I mean if we allow clients to insert images in the Text, shortly after there's a complete mess of images to clean up.

That has not been my experience. I have had clients mess up things in RTEs, but rarely related to images. It's usually about typography, so I like to introduce limitations about what markup elements the client can use, particularly headlines. CKEditor with ACF and Purifier enabled has also solved the vast majority of clients-messing-things-up issues I've had in the past. Maybe your experiences are different, but these are the problems with images that I've seen with my clients: 

• It's nearly always about poor image selection, not placement. By that, I mean the client will upload really bad stock imagery of business people on 1990s cellphones and such. This issue has nothing to do with an RTE, and is an issue anywhere the client can upload images. 
• Clients rarely have the image tools [on their own computer] necessary to prep their image before uploading. They've not had a way to crop images to make them right for the context. For instance, needing to show a picture of a specific person but instead having only a photo with a group of people, and using anyway. Though this update does solve that problem among other things. 

I understand there are site designs where you want limit what the client can do with images, or maybe you want to prevent them being able to place images in text at all, leaving that for your own code to handle. This lets you have more control over the resulting layout. I get that, and I work on plenty of those too. But understand that this is a specific need in some layouts, not a universal need in every site or design. The same goes for use of an RTE at all. There are plenty of situations where entity encoded plain text or an LML like Markdown or Textile is more appropriate. But for situations where an RTE with image placement capability is the appropriate tool, I want it to be as good as it can be. This is a tool we already have, and so this update was about enhancing that tool to make it better for its intended purpose. 

[ryan]

The problem I have with SirTrevor and other similar projects I've seen are that the actual editor experience just isn't as good. It feels downright unnatural relative to anywhere else one might edit text. When I experiment with SirTrevor and others, I can't convince myself I'd want to use it on my own site. And if I can't convince myself, I won't be able to convince my clients to use it. How would you like it if we switched to SirTrevor for the editor in these forums? I think we'd have a lot less activity. 

There is an assumption with these tools that the end user is actually authoring the content directly in the editor. That's what I do most of the time, but most of my clients author content offline or work with existing content created by somebody else. Basically they are pasting content and often lots of it. These block editors become an especially huge pain when you are doing that. Many other types of edits just become unnatural and clumsy. It's not about the implementation of the block editor being faulty in anyway, its just that the entire concept doesn't result in a better editing experience. 

Where I like the block editors is that it's less to accommodate and worry about on the front-end development side. It also opens up some other kinds of element placements and previews that would be difficult with a regular RTE. So I totally agree there is a place for these editors. But I don't think we'll ever see RTEs replaced entirely by block editors, no matter how good the implementation is. Though I'm sure we'll see some good hybrids.