mindplay.dk

I guess I don't completely understand where or how input-validation occurs. In input-fields or in field-types? I was trying to reference the Integer input-field and field-type the other night, but it just sanitizes the input and throws away invalid values without complaint. Come to think of it, this could be a problem if the user thinks they've actually put in a value like, say, a price, and a product gets published to the site with no price-value...

@ryan will that work for $settings in the Field class? I poked through the code, but I wasn't sure this would work for every attribute...

Of course! How did I not think of that! The only issue then, is how to enforce that this field must contain a unique value? Perhaps a very simple new InputField type could perform that validation? This would also enable you to have more than one type of ID, as you could add multiple fiedls, each with a unique value. I would be nice to have this be a standard feature. Could be useful for other things.

Yep, I backtracked through the code last night, and that's what I ended up using Lots of details to work out still, but it looks like every create/update/delete of Fields is now being captured correctly. Computing the difference between the previous and updated versions of Fields is tricky - the types seem to change? For example, the width (the 0-100 integer value) doesn't seem to be available initially after load (?) ... and to compute the difference, I now use != instead of !== which cleared out a lot of unnecessary values that would otherwise register as updated because they change e.g. from a string like '100' to an integer...

@ryan I'm taking another look at this, and running into a problem. It appears there is no way to enumerate Field settings? If I may suggest a small change in the Field class: /** * Get a Field setting or dynamic data property * */ public function get($key) { if($key == 'table') return $this->getTable(); else if($key == 'prevTable') return $this->prevTable; else if($key == 'prevFieldtype') return $this->prevFieldtype; else if(isset($this->settings[$key])) return $this->settings[$key]; else if($key == 'settings') return $this->settings; # <- ! return parent::get($key); } Or perhaps more explicit, and without the risk of colliding with a setting called 'settings', a method like getSettings() would do the trick, too. What do you think?

Yeah, I don't like that at all. What PW does internally is at least somewhat cleaner than that - defining the ID once and making it available globally, e.g. $pages->get($config->teamPageID) would work okay and is reasonably semantic. I don't think this feature would add any significant amount of complexity, it's a very simple feature. It would feel good in queries as well, with a CSS-like syntax, e.g. $pages->find('#team, template=team-member') Of course, not after launch - during development.

It had not occurred to me to overload the $page->get() method in that way, but I guess that would make sense, yeah - a simple check for number vs string in the method should make it easy to differentiate numeric ID requests from "key" requests.

In my experience, no. If two developers are working on local dev versions, they have to be careful about what they import/export when they're done - if you worked on "foo", and I accidentally export "foo", if I deploy after you, your changes will be lost. Logging repeatable changes is probably safer - this is essentially what database schema migration systems and source-control systems do, and most of the time, assuming two developers coordinate what they're doing just a little bit, this rarely causes any conflicts. I'm not saying this would be dead simple to implement - there would be challenges, for sure, but I think it's possible.

What complicates this in other CMS, is the fact that (at large) they don't have a unified data-model for the metadata (templates/fields) - lots of extensions create their own tables. This is very rarely necessary (and shouldn't be) in PW, where the data-model was designed from the ground up to support the entire metadata-model. I think this would be much simpler to implement in PW than in any other CMS.

Several times now, the following has happened to me: I place a page in the tree as "/team", and I have some templates for menus etc. that go and grab that specific page, to create a list of it's children. Another team member (someone who's working on content) comes in and moves that page from "/team" to, say, "/about/team" - the template that tries to list the children of the "/team" page are now broken and listing nothing at all. ProcessWire gets around this issue by placing the actual page IDs in a configuration file somewhere - I really don't like that approach, since those IDs are just auto-incrementing numeric keys with no particular meaning. I'd like to request a simple, small new feature: an optional, unique page ID attribute. This would work much like the ID-attribute in the DOM - where only one element with the same ID is allowed in the same document, only one page would be allowed to have the same ID on a site. And where in the DOM, you can find a particular element by it's ID, regardless of where in the document it's located, in ProcessWire, you'd be able to find a page by it's ID, regardless of where in the sitemap it's located. Thoughts? Edit: a different term would need to be used, since the numeric ID is already known as the "page ID" - so maybe "page key".

Agreed, that's not what I'm aiming for - this tool would provide continuous integration of template/field changes only, not for content. An import/export tool would be much safer and more useful for content, I think? An import/export tool for templates/fields, on the other hand, would not feel very safe to me, personally - there is an long list of possible problems to deal with (template/field name collisions, renamed templates or fields, missing fields, etc.) and a much longer list of possible ways to resolve those problems, many of which you would need to ask the user to select on a case-by-case basis. It sounds like a scary idea to me. In a continuous integration module for templates/fields, advance consistency checks could be implemented fairly easily - e.g. by maintaining a serial number and checksums for the change-sets, so that (in effect) one installation is designated "master" and can only push the next change-set to a "slave" in the right order. This would not be a magical tool that somehow resolves conflicts between template/field versions that are out of sync - it would guarantee reproducible result simply by preventing change-sets from being applied out of order. In other words, this would be designed for a workflow where you have (for example) a development server pushing changes to a production server, where the client would be permitted to edit the content, but not the templates/fields. I wonder if pushing or pulling would be the most durable approach. Perhaps pulling would be safer, and perhaps then pulling change-sets out of order could even be permitted, with a warning, so that one developer could pull another developer's changes on demand, and on success, the combined changes could then safely be pulled up to a production server...

Note that you can already "tag" templates using fields - I think you will find quite often that templates with certain tags are also going to have certain fields, so watch out for those cases and avoid using tags in those, since you may be duplicating semantics. For example, you can already select all pages that have the great_big_headline field, so you don't need a tag for templates that have a "great big headline". Edit: one case where I could see template tags being really useful, is to output the tag-names (probably with a prefix or suffix) in the class-attribute of the body-tag - something my HTML/CSS guy asks for all the time.

What do you mean, are you working on a module too?

I recently tried and gave up - many field-types actually store things in the "pages" table, so if somebody created a new page of content on the site while you were working on a local copy, you'll have overlapping page IDs. In the end, I had to tell people to back off the site while I was working locally and wait for me to signal the green flag - then replicate all the changes by hand. Ideally, I would like a module that provides automated one-click deployment and version control for all metadata, which, fortunately, thanks to good clean data architecture in PW, can be done by just handling Templates and Fields. I wonder, would anybody be interested in this module as a commercial option?

I wish I could dedicate the time to finish this - but it's not the sort of thing you can bill a client for, so... if I had to build this, it would be in my spare time - and I have a million things I'd like to build in my spare time...

There's a problem with this tweak - if a page is not selected/open (.PageListItemOpen) you can't drag it. This appears to be caused by "ProcessPageList.js", where the clickMove() function has a block of code with the description, "make an invisible PageList placeholder that allows 'move' action to create a child below this". I'm not sure how to fix this, or if that's even precisely the problem... any ideas?

Yeah, there's no Windows version of that. I thought your videos were pretty good - clear, concise, to the point, you explain things well I'll definitely have to put my own recordings through the Windows video editor myself for some basic editing

15 minutes time limit on the free version - that's pretty good. Most other tools have a 10 or even 5 minute limit... and just $15 for a year... I will give this a try, thanks

I used this recently, and it was terrible - it was very hard to even install and get it working on Win 7, the screen capture codec driver refused to install. I eventually did get it running, and it was still terrible - randomly, some videos come out garbled, and it doesn't always record the sound, but it will keep going without a warning or error, so I wasted a lot of time...