mindplay.dk

@kongondo: Shortcodes are mark-up. The tag parser is actually not just mark-up but code. Hanna is code/mark-up, depending on your definition. These modules define new inline mark-up syntax, and while that may be great for some people, learning yet another mark-up language isn't going to be everyone's cup of tea. The key difference from what I'm suggesting, is that the meaning of a specific tag, mark-up or placeholder in those modules, is defined externally from the document where they're used. So a placeholder like {fish} only has meaning within the document you're editing - there is no definition of {fish} external to the document you're editing, and it only has whatever meaning you attribute to it by (visually) defining what that placeholder will be replaced by. To give a practical example, let's your site contains articles, and some of those articles have inline image galleries - inline with the body-content of the article, between two paragraphs, wherever the author elects to place it. Let's say each image gallery has a summary and a list of images each with a caption. You could do it with inline code/tags like this: <p>Nam consectetur mollis elit sit amet commodo. Cras fringilla, turpis pretium vestibulum adipiscing, massa est scelerisque odio, vitae pharetra dolor erat in nisi. Maecenas magna augue, volutpat in consequat id, feugiat eu lacus. Aliquam erat volutpat. Pellentesque vehicula mi vitae est vestibulum nec volutpat dolor blandit. Duis eu gravida sem. Sed et ligula ut est pretium ornare. Ut dictum tincidunt est a scelerisque.</p> [[gallery float="right" summary="Colorful photo gallery of Piranhas in action" width="400"]] [[image id=789 caption="Adorable Piranhas flocking around my legs"]] [[image id=123 caption="Piranhas attacking my legs"]] [[image id=456 caption="What was left of my legs after the attack"]] [[/gallery]] <p>Maecenas malesuada facilisis lacus eget sodales. Phasellus ut quam a sem molestie egestas non non enim. Pellentesque orci lectus, auctor mattis ornare vel, tristique sed quam. Cras ac dui vel dui varius iaculis vitae gravida arcu. Curabitur non nulla felis. Sed viverra sagittis odio non ornare.</p> What I'm proposing is you do it with a simple placeholder instead of code: <p>Nam consectetur mollis elit sit amet commodo. Cras fringilla, turpis pretium vestibulum adipiscing, massa est scelerisque odio, vitae pharetra dolor erat in nisi. Maecenas magna augue, volutpat in consequat id, feugiat eu lacus. Aliquam erat volutpat. Pellentesque vehicula mi vitae est vestibulum nec volutpat dolor blandit. Duis eu gravida sem. Sed et ligula ut est pretium ornare. Ut dictum tincidunt est a scelerisque.</p> {piranha gallery} <p>Maecenas malesuada facilisis lacus eget sodales. Phasellus ut quam a sem molestie egestas non non enim. Pellentesque orci lectus, auctor mattis ornare vel, tristique sed quam. Cras ac dui vel dui varius iaculis vitae gravida arcu. Curabitur non nulla felis. Sed viverra sagittis odio non ornare.</p> As soon as the WYSIWYG or textarea detects the {piranha gallery} placeholder in the content, the placeholder will show up on a list, and you can populate all the properties of the inline gallery block via inputs instead of typing mark-up. It's just more user-friendly and faster to work with, in my opinion - and I like the fact that the placeholder {piranha gallery} has semantic meaning to a person editing the article, whereas actual mark-up has to be interpreted by the person editing when encountered. Because there's no mark-up, you can't make typos or other mistakes. It eliminates a learning curve. And perhaps most importantly, it builds on existing ProcessWire concepts and introduces as little new functionality as possible, instead of introducing entirely new concepts and/or syntax.

In fact, come to think of it, these "macros" don't have to be a new concept in ProcessWire at all - they could simply be Templates, and their user-interface would consist of Fields, and their php-templates would render sections/snippets for inline use, instead of full pages. That way, you could make full use of any Fieldtypes you have installed, and you wouldn't need to write code to create new types of "macros".

I'm seeing more token replacement modules crop up lately - modules that pick up various tokens (with various syntax) in text/html fields, replacing them with various types of mark-up, snippets, images, etc. Just a point of view: I think parsing and replacing tokens, and (more importantly) introducing augmented syntax, is the wrong solution for all of the problem I have seen people attempting to solve using this approach. Actually that's not specific to PW - a lot of CMS (and contributors) take this route, and it never leads to a very pleasant end-user experience. In my opinion, from the end-user's perspective, it beckons the question: if you're going to make me learn other forms of mark-up, why not just give me a bare plain-text HTML editor and make me learn HTML? At least HTML is one consistent syntax, it's universally useful, and it's not some strange mix of a whole bunch of other HTML-like syntaxes mixed into what is actually HTML. I'm not posting this just to gripe - I've actually worked on (I think) a "better" solution in the past, but unfortunately it was never completed. Rather than making people learn and type actual syntax, I used an approach with simple placeholder tokens, like so: <h1>Welcome!</h1> <p>Pretty picture of my pet fish:</p> {fish} <p>And my pet bird:</p> {bird} The placeholders are not "tags", and they don't have any actual "syntax" - the names are arbitrary and don't mean anything at all, except in terms of semantics used by the author. They don't have attributes, and there is no concept of "blocks" or start/end tags. They are all local to the body/content field you're editing, and have no shared meaning outside of the current context. Instead, the client-side editor recognizes the {fish} and {bird} placeholders, while you're typing, and a graphical user interface appears, presenting you with a list of placeholders you've used in the text or WYSIWYG content-area you're editing. You can then click on the placeholders in the list and decide what type of "macro" you would like to replace them with - then configure the properties of that macro. In the above example, you might select the {fish} or {bird} placeholder from the list, select the "image" macro, and upload or select from a library of images, configure cropping or resizing, perhaps watermarking, etc. In ProcessWire, two very useful macros would be Page and Field - allowing you to expand a placeholder, replacing it with a rendered Page or an individual rendered Field from a specific Page. This very simple solution could enable you to build things like block systems or navigation without any additional programming - just simply define reusable Pages with snippets of content, images, or Page references and so on, in a reserved folder in the root of your site, and then pick from those using macros. Is this comprehensible? (I might be able to dig up the very old prototype and post some screenshots) And what do you think of this idea?

The current approach makes it possible to share images between Pages - that's nice, but what happens if I delete a Page that contains images reference by a body-field in another Page? I see at least 3 different common image use cases: Inline images belonging exclusively to the body-field where they're used Inline images shared between multiple body-fields Associated images for specific purposes (non-inline use) You can handle number 1 with the current approach, but you can't guarantee the images won't be shared with other pages, hence you can't be sure it's safe to delete a page that contains images - or worse, you may have to delete a certain page, and you will need to first somehow recover the images, place them somewhere else and update you references to those images. You can handle number 2 with the current approach, but it forces you to create dud pages to hold the images. Number 3 is handled perfectly, and that seems to be what this approach was really designed for - basically any inline use-case seems like a bit of an afterthought and the solutions aren't really ideal. I looked at soma's module, but it kind of seems to solve a different set of problems. Ideally, I'd like to have some sort of media manager, not only for images but for audio, video, documents and links to external media, as the same set of problems apply to all of those - in particular, the ability to share and track the usage of all media items. I think this is why most other CMS have a media management component of some sort? The ability to organize a media/image library into categories etc is a nice bonus, but simply being able to manage and use media in a controlled way seems more fundamental to me...

I understand everything you're saying, but I don't agree - having to add a separate field for images that belong to a different field, it just doesn't make sense to me. Basically, in my point of view, there are images (fields) and there are inline images - the latter are not independent documents, they are just part of a body of rich content. I don't like having to explain to a client why it works that way, especially if the explanation is "technical limitations". Is there a better (logical) explanation for the need (desire) to separate inline images from body content?

Images should be kept in the Page by default, I don't disagree with that - but should be associated with the (body) field they belong to, rather than with a separate (image) field - it's confusing to the end-user. Can you provide a link to the clarification by Ryan you mentioned? It's a start. I'm not in love with the idea of making users type in codes to reference images.

I only recently attempted to use the image-button in the WYSIWYG, and I don't feel like this really works well. I have to add an ImageField to the page, and put in the description something like "these images are for use in the body field, and won't automatically display on the page". Looks and feels like a patch solution. I looked but did not find something like an "image library" module - the way most CMS work, is they let you have a shared/global image library, typically organized in folders, where you can upload and reuse images on different pages. I know I could create "dud" pages and organize images into fields, but it kinda creates the same problem of having to explain on these pages that they're not actually published or visible but just there to organize images. Any ideas?

Consider referencing (or possibly even integrating with) apeisa's Fredi module - some datatypes do not lend themselves well to in-place editing, and I think that includes images? If you want things like drag-and-drop uploading and drag-to-resize on img elements, I think you have your work cut out for you - probably simpler to allow datatypes that can't be edited in-place to be edited in a pop-up? Also consider that, whenever you rebuild the editor for a particular datatype, you may lose access to any enhancements made for that datatype's regular editor.