mindplay.dk

I'm sure that's great for public-facing pages that don't have anything to do with ProcessWire as such - what I'd like to see though, is a more complete solution to validation in ProcessWire itself, for validating content entered by content managers.

You could certainly reference an existing validation framework for the actual validation logic - but the feature itself would probably need to be designed for use with ProcessWire Templates, Fields and Pages.

I realize you can do your own validations using code and hooks - I'm talking about making those validations visible and configurable from the UI. But having a real framework for componentized validation and error-reporting wouldn't suck when working with code either - some field-types (such as integer) currently just "sanitize" values, quietly erasing them, rather than producing a user-friendly error-message. And again, you can hard-code all of that per Fieldtype and/or Inputfield, but that just doesn't seem like a very structured approach to me...

We have an increasing number of Fieldtypes and Inputfields, and I just had a realization: validation is baked into Fieldtypes and Inputfields, wherever it fits. That seems wrong? Or at best, rather arbitrary - these concerns seem to get baked in wherever they might fit. So now we end up with things like InputfieldEmail, InputfieldURL and FieldtypeTextUnique, all of which have various types of validations baked into them. Well, now suppose I want a field that validates both as unique and as an e-mail address? That's two validations. I would need to write another class, and even then I might have to duplicate some code to make that happen. Basically, any arbitrary combination of validations would require a new type. Have you thought about adding a validation framework of some sort? Allowing for multiple validations on the same Field, configurable error-messages, etc.? This might reduce the number of Inputfields and Fieldtypes considerably? A lot of fields are just some variety of a text-field, with different validation - it would be nice to be able to apply validations such as uniqueness to either e-mail, URL, integer, Page-reference, etc. It would also be nice to be able to write site-specific validations and reuse them across multiple fields on some sites. A configurable general-purpose validator for regular expressions would be another possibility - this could be extremely useful, for example when a field should accept URLs referencing a specific site, like YouTube or Vimeo. Componentized, modular, and configurable validation is something most major CMS have - is something like this in the stars for ProcessWire?

I don't find it "scary", but I have been building web sites for long enough to know that many clients will reject the idea of having to type in codes, out right. It doesn't matter how "easy" or "clever" your codes are - code is code, and many clients want WYSIWYG and simply will not accept that. For myself, personally, it would work great - probably much better than a WYSIWYG. But you and I are programmers. A lot of non-programmers will throw their arms up in despair at the sight of an angle bracket. And I get that. We should be able to come up with something better for those people. Something that is as easy and as visual as a WYSIWYG, without sacrificing ease of use or introducing codes. I say we should be. I don't think it has been done yet - if it has, I still haven't found it...

I have a Template that has a field with a list of images. To my surprise, the image list returns two different things when accessing the images in two different ways: <?php var_dump($page->images->first()); // => Pageimage var_dump($page->images[0]); // => Page Is this deliberate? It seems really inconsistent and, well, weird...

Okay now, let's not throw out the baby with the bath water For the time being, I had to simply use the image-field the way it was designed - in conjunction with a WYSWIYG. I keep the image field "always collapsed" in templates where this field is exclusively for use in one or more WYSIWYG fields. It still doesn't make a whole lot of sense to me, personally - but the guys who populate the CMS are quite happy with it. One guy remarked that he likes the idea of being able to expand the image field and get an "inventory" of the images that are in use on that page. I'd like a better solution eventually, but if the end-users are happy, it's probably not a big deal. This solution is acceptable to me for the time being, until I can find the time/resources to build (or help build) something more advanced...

I've tagged release 1.0.0 and the module is now listed in the modules directory.

Since we're on that topic, any thoughts on adding a real UI for the TinyMCE configuration? The current UI is not much better than simply typing into a text-file - there's the same margin for error, and you still need to look up keys/values in the documentation to get it right. Also missing for me, is the ability to create and share configurations - most of the time, I really want one, or at the most two configurations, for all of the fields, not one for every field. If a UI isn't going to offer an advantage (convenience, transparency) over editing a text-file, in my opinion, a text-file would be preferable, so at least you can check the configuration into source-control and deploy it easily. So a much simpler solution would be to simply provide a folder where you can place plain JS (or JSON) configuration files, and then simply pick one from a drop-down - I'd be happier with that solution than the current one, since it's the same amount of work, and addresses the issue of sharing configurations...

The placeholder is replaced when the content is rendered for display - it can't be replaced while you're still editing in a textarea or WYSIWYG. In this old prototype, the markdown is actually rendered on the client-side, in real-time, while you're editing - and so it would have been able to make the substitutions in real-time, but that only works because you've got the markdown source in a popup, separated from the actual view. It might could work with in-place editing - you would need something like Aloha editor, where you can make certain areas of content editable, so that the rendered macros would not be editable in-place. I'm not sure if this would ever work in IE though.

Okay, I found this old prototype and it's not so easy to deploy for various reasons, but I got it running locally, and here's a screenshot: This implementation used in-place editing, so the ugly crap in the background is a webpage, and the editor in front is editing the content (which is markdown) in the main content area. As you can see, the placeholders {fish} and {cat} appear on the list on the right, as you're typing - and this doesn't work or was never fully implemented, but imagine the "+" icons would pop open another dialog that lets you select a "macro" and configure it... simplest possible example would be an "image" macro that lets you upload an image and simply substitutes each placeholder for an <img> tag. I don't know if that really clarifies anything...

There's no drag and drop... hmm, this is hard to put in words, I should dig up that prototype and post it somewhere...