mindplay.dk

Anyone used ezvid ? ... I'm afraid of download this - it looks suspiciously free, and by that, I mean loaded with ads. Could be packed with ad-ware - I'm always suspicious of free software with no apparent business plan. I wonder what Ryan used for his ProcessWire videos?

Haha, I am pretty picky, I'll grant you that! ;-) I really like video for demonstrating things like this. I haven't been able to find a good, free screen recorder though - anyone?

Thanks for sharing that, apeisa - really useful and reassuring. This kind of thing really should be in the Wiki too - I wonder if the Wiki should have a dedicated area with descriptions of how to build and customize such features? I wonder what such a section would be called. (the word "Recipes" comes to mind - or perhaps "Patterns", or "Information Patterns" if you want to get really technical.) It's really important to collect and encourage new users to learn how common features can be built without (or with very little) code - many new users are going to be coming from CMS where such things require a plug-in, and a lot of people are going to assume that's necessary. Most CMS have a tagging/taxonomy module, for example, and it's features are set in stone. This kind of information needs to be readily available (even promoted) to developers. Of course, you can learn from the forums, so perhaps that's all that's needed - the trouble is finding the solutions in all the talk and long threads. Perhaps this could be solved by having some way to tag posts, so that they appear on a list somewhere. Stack Overflow does something similar - where you can post a reply to question in the "community wiki", making your post editable by others... Thoughts?

After sleeping on it, I've decided to use Pages, as suggested. I'm going to create a template called Taxonomy - this template will allow children of it's own type. I will create one root Taxonomy page ("/taxonomy"), and each taxonomy-type will just be a Taxonomy page under it ("/taxonomy/article-type") - the individual classifications will be child-pages under those: "/taxonomy/article-type/sports", etc. After thinking about it, compared to the idea of having simple enumerations/sets as a Field-type, I like this idea better, as it can grow - it will have only a title-field, but who knows, maybe somebody will want a summary and/or body-field on those one day, so that category overview pages can be displayed. Or some other need I haven't foreseen. Another thing I like better about this, is the fact that Taxonomies can be trees, not just flat lists - again, I don't need that right now, but requirements can change, and this way I'm not locked in, or risk having to write more code to extend a Field-type to support that. Perhaps an article about building Taxonomies should go into the Wiki? I will try to take notes and draft something while I build this. This is definitely a case where it would be very easy to over-engineer the solution in ProcessWire - for example, I was thinking at first that I would need multiple templates for different Taxonomies - then I thought, I need two templates, one for the taxonomy-type, and one for the taxonomy-classifications. But the absolute simplest solution is to have just a single template, so that the whole taxonomy data-structure is homogeneous. It's another great example of how the ProcessWire data-model really excels - the more I use it, the more convinced I become that there really isn't much you can't do with this data-model, and plus, it scales very nicely, both in terms of performance and complexity

That would make sense if there was any information associated with them - but this approach would require you to create two templates, one for the value list, and one for the values, and neither template would have any fields. And then creating pages just for those values. It seems wrong.

And what would you do when you need a multi-select list with a fixed set of options? (in my case, I want to provide a list of checkboxes that add select classes from a pre-defined set of class-names, to the class-attribute on a div-element in the template.)

What is this then? public function ___getConfigInputfields() { $inputfields = parent::___getConfigInputfields(); // if dealing with an inputfield that has an associated fieldtype, // we don't need to perform the remaining configuration if($this->hasFieldtype !== false) return $inputfields; $isInputfieldSelect = $this->className() == 'InputfieldSelect'; $f = wire('modules')->get('InputfieldTextarea'); $f->attr('name', 'options'); $value = implode("\n", $this->options); if(empty($value)) { $value = "=\nOption 1\nOption 2\nOption 3"; if(!$isInputfieldSelect) $value = ltrim($value, '='); } $f->attr('rows', 10); $f->label = $this->_('Options'); $f->description = $this->_('Enter the options that may be selected, one per line.'); $f->notes = ($isInputfieldSelect ? $this->_('To precede your list with a blank option, enter just a equals sign "=" as the first option.') . "\n" : '') . $this->_('To make an option selected, precede it with a plus sign. Example: +My Option') . "\n" . $this->_('To keep a separate value and label, separate them with an equals sign. Example: value=My Option') . "\n" . ($isInputfieldSelect ? $this->_('To create an optgroup (option group) indent the options in the group with 3 or more spaces.') : ''); $inputfields->add($f); return $inputfields; } What would be the use of entering your own "options" if this works only for a page selector?

I may have lost my mind, but I can't for the love of me find a way to create an InputfieldSelectMultiple - the module is installed, but when I go to create a new Field, I don't see an option to create such a field. I have tried every field I could think of, including Checkbox, Integer, Page, Text and TextArea, but "Input field type" either doesn't show at all, or doesn't show the "Select Multiple" option, except for Page, but that doesn't seem to be the right field-type. Looking inside "InputfieldSelect.module", I see things like "To keep a separate value and label, separate them with an equals sign. Example: value=My Option" - that's precisely what I want, but I can't seem to find any way select it... Help, please!

Just thought I'd share an idea that has popped into my head a few times by now, while working with PW. The purity of the central tree data-structure that powers the ProcessWire data-model, is very elegant, and for the most part works really well for me. One instance where it does not always work well, is in terms of optimizing URLs. Most of the time, simply having items grouped under other items works quite well, but at other times, you can end up with URLs that are littered with keywords that aren't really relevant. Not great for SEO, and not always great for URLs you intend to share via various channels. (Twitter, printed material, etc.) This happens with deeply nested menu structures in particular. On one site, I ended up with a URL like this: "/articles/some-topic/some-page/" - the keyword "articles" has no particular relevance here, it's just a logical grouping, not something you expect people to search for. And "some-topic", in this particular case, was unwanted. The client was asking for a short, user-friendly URL, e.g. "/some-page", and in order to do that, he would have to place the actual page in the root of the site, which was not appropriate in this case. So this brings me back to an idea I've been kicking around (for my own CMS) for some years - the idea of having more than one hierarchy. Actually, an arbitrary number of user-defined hierarchies - with the ability for the user to place a given page in either one or more of these hierarchies. I've had various versions of this idea over the years, but in the simplest version, one of these hierarchies is the designated URL hierarchy - so this would be the hierarchy ProcessWire has now. Other hierarchies are just logical (taxonomic) hierarchies that could be used for whatever purposes you like. So as an example, "product categories" might be a dedicated arbitrary hierarchy, in which "product" pages can be organized logically, independently of the hierarchy that drives the URLs. If somebody is selling iPads, for example, you can place the product in the "product categories" hierarchy, e.g. "tablets/apple/ipad/32gb", which might determine where the product appears on a menu, but does not affect it's URL. This particular product might be placed in the URL hierarchy as simply "/apple-ipad-32gb", for example. (maybe not the best example, as in this particular case, it might make sense to include all the keywords from the category - it's just an example.) This problem could also be addressed, apparently, by allowing a page to be referenced more than once in the tree, or by introducing an "alias" template, so that you can "optimize" URLs by creating "aliases" for pages in the tree. Mathematically, this solution doesn't speak to me - in a real tree, a node should have precisely one parent, otherwise you introduce the potential for things like circular references or circular queries, e.g. traversals like A->B->C->A->B->C->... Or, in the case of aliases (as opposed to references), you introduce "dead" nodes from which you cannot traverse or find subpages, because the "alias" node is a leaf-node, even if the page it references has children. (otherwise, mathematically, it would be a reference and not an alias.) Another possible solution would be to simply allow a custom URL alias for any page. This would probably be relatively simpler to implement, perhaps as simple as adding a "URL alias" text-field to templates that need it, adding a very simple module that does a query for the exact value of that text-field prior to PW doing it's normal traversal and dispatch. (This might not be great for SEO though, as you end up with two URLs for the same page.) Clearly that's a much simpler solution than introducing multiple hierarchies, but for other reasons, the idea of multiple, user-defined hierarchies has always appealed to me. For one, it's not uncommon for the same page to appear under two different menus. As an example, on a site I'm building right now, some blog-posts double as articles that also appear organized somewhere in a category on the main menu. It's the same logical page, and it should have the same URL, regardless of whether you found it in the blog-roll or on the main menu. But because the logical and URL hierarchies are one and the same, there is no simple way to accomplish that. Perhaps the best real-world example I can give, is a product catalog - for one company we worked with, their products were organized by two entirely different hierarchies, because their products are used in two entirely different industries. So you have two independent logical hierarchies, but the pages (and URLs) are the same. I could provide more examples, but I think I've made my point, so I'll leave it at that. Is multiple hierarchies a good solution, or is there another, simpler, more direct solution to these issues?

Author of TwigJS confirms that it is, quote, "full of bugs" JSON-template doesn't look viable, and after thinking more about Mustache, I don't think that will work - it doesn't support any kind of manipulation or filtering of the content it outputs, only via lambdas, which would need to be implemented consistently on both the client and server-side, but besides the content passed to a lambda, it doesn't look like you can actually pass arguments to those, so not much use. Not sure where to go from here...

Separation of markup (design) and content - something you do not normally get from a WYSIWYG. So, for example, you might have a template called "paragraph with zoomable image" which would have an input for the content, an input for an image file, and a text-input for an image description. It might render the image with a zoom-button, nice framing, and the image description, and have the paragraph content float neatly around it. Today, your site may use a particular template and markup for that - next year, when your site is redesigned, the markup may change and existing articles can be re-rendered. Same goes if you discover a bug in the markup of a template - all your articles can be re-rendered. For comparison, imagine you discovered your WYSIWYG is generating bad table or image markup. Not easy to back-fix when all of your articles have their content baked into markup. Or imagine you decide articles should use h2-tags instead of h1-tags for the article headline. The arguments for micro-templating in articles essentially are the same as for templating in general - separation of content and markup.

Here's another option, JSON-template - this has Javascript, PHP and other implementations. It doesn't look like these implementations have seen much maintenance in the past couple of years though. (?)

I was leaning towards Twig, so I took a closer look - I'm not sure what the status of TwigJS is, and I wrote and asked the author. But I don't see any of the standard filters, functions, etc. in the codebase, which looks very, very small... Perhaps Mustache does have what is needed - essentially, a simple JSON view-dictionary gets mapped to a view, which may be enough for simple templates, which may be all that is required for a template-based article editor. Perhaps more complex functionality could (or should) be running exclusively on the server-side anyway, in order to guarantee that it's consistent. There are after all things we can't do on the client-side - for example, uploading and resizing an image has to involve the server-side. Mainly, the point of re-rendering the templates on the client-side is for performance, so that they can be re-rendered in real-time while editing the content/data. The simplicity of Mustache is also appealing in terms of learning curve - developers won't use this, if it involves a lot of proprietary syntax, I think. It has to be easy to set up and must be able to integrate with just about anything. Even if it uses templates and real-time client-side rendering while editing, the eventual output must be HTML, same as if you were using a traditional WYSIWYG editor...

Still thinking about starting a template-based content editor... First thing required for something like that would be a template engine for the actual templates, that works on both the client (JS) and server side (PHP). I poked around and see two options that look viable: Twig for PHP and the TwigJS port for Javascript. Mustache for PHP and the Javascript port. I guess Twig is more of a traditional template engine style, where logic is placed in the templates - whereas Mustache is simpler but has less functionality and almost no syntax, but any moderately complex logic has to be implemented in the view-model itself, which may not be suitable for this. Users in general may be more comfortable with a more traditional template engine, anyhow. I've never used either Mustache or Twig myself, so... thoughts? Know any other engines with both PHP and JS implementations?

Sounds like the bug has been fixed in Chrome, and we're just waiting for an updated release now. http://code.google.com/p/chromium/issues/detail?id=143354