mindplay.dk

You should have the changes available in $page->trackChanges() ?

Edit: or foreach and use $page->isChanged('field') for each field.

@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...

// you could also use your own custom field for this and define it global if you want it to always exist
$pages->get('page_id=team'); 

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.

You should be able to use the $field->getTableData() function. In addition to what is in $settings, it will also have a 'data' property which is an array containing any custom field settings. Let me know if that doesn't provide what you need?

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?

This will had complexity and force the table to have one more index, no?

Personaly I'm happy with

$pages->get(1919); // get "teams"

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')

I'm going to state the obvious here and point out that you shouldn't change a site's structure that significantly after launch anyway.

Of course, not after launch - during development.

So you mean instead of:

$pages->get(1919); // grab the teams-page

You would like to have:

$page->get("teams"); 

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.

Wouldn't it then be sufficient to have a tool to export your field/template schema data to a file and safely reimport them, so you can make it part of your version control? This should even be more secure than the idea of logging changes, which might be a problem if you have several developers working on local dev versions.

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.

there hardly any CMS that has this functionalities for a good reason.

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".

Doing just template/field synchronizing maybe a good way to start and can save time, but a full blown deploy tool I hardly would trust in it and have always fear it doesn't work and causing more work at the end. 

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...

For those that wanted field/template categorization, I've got them implemented for fields and now development the same for templates.

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.

I am a little closer to 'kind of' this, but it's… not done yet

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

It might be possible to at least figure out some guidelines to help people know how to manually export SQL at one end and then import the right bits at the other end.

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

I always use screenomatic online screen recording. It is free and you can directly upload to youtube or computer.

http://www.screencast-o-matic.com/

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

Is Camstudio still going?

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...

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

You create those options as pages and use page field.

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?