mindplay.dk

Ideally, the system should perform a "dry run", validating the changes prior to physically applying the changes. I'd prefer to be able to connect up two systems by exchanging a private key of some sort - and being able to deploy via an admin screen, rather than having to drop to a command-line, which isn't always practical in a situation where somebody needs to make a quick correction to a live site...

That was actually one of my early ideas, but it suffers from the same problem as one of my later ideas: capturing the actual form-submissions, and then later simply repeating the changes by programmatically re-submitting the same post-data. Theoretically, doing so would reproduce the exact same result, with the same side-effects from hooks being run etc. It sounds great and very simple at a glance - just repeating your SQL statement. But it won't work, because either forms or UPDATE statements are based on numeric keys. If I create a new Field or Template on the other system, the next ID will increase, which means you'll have overlapping indices when you deploy changes from another system. So the updates must be keyed by name, not by ID - or you will have exact same problems as before, needing to freeze changes completely on one system before starting a round of changes on another system... and if so, you might as well deploy by just taking a snapshot of the database...

Well, yes, but technically, products.html is still both potentially a file and folder - if you were to add a sub-page, you would get "products.html/ipod.html" which demonstrates why doing so would be even more wrong and misleading Don't get me wrong - I love that fact that nodes are homogeneous in ProcessWire. But an option to add a suffix when requesting the actual document (rather than the folder) would eliminate the ambiguity in the URLs - "products" in "products.html" clearly refers to a document, whereas "products" in "products/ipod.html" clearly refers to a folder...

I also wonder if this is even the right approach, or if this is more of a back-fix for something that can't really be handled directly by the framework, as-is... What I mean by that is, perhaps I'm trying to solve an architectural problem that should actually be solved at the architectural level, rather than by a module? For instance, if meta-data (Fields, Templates, configuration) in general was kept in flat files, that would solve part of the problem. If meta-data was shielded from direct modifications, and could only be modified using command-objects of some sort, whenever those command-objects are run/applied to the meta-model, you could serialize and store those objects, and later on you could repeat those operations simply by unserializing those command-objects and running them. I wonder if it would make more sense for me to attempt to build that into the architecture on a low level, rather than building a module that tries to work around the absence of a pattern that would make these (and possibly other) operations much simpler?

I'd love hear from @ryan on this one, before investing a whole lot more time in this - potential pitfalls, situations where this might or might not work? Like for one, since this is an event-driven architecture, and some modules are going to tie into the actual controllers to do certain things - if I repeat a change at the API-level, say, updating a Field, that won't trigger the same controller-level hooks, and potentially the result might not be the same... (I guess maybe I should hook into Field and Template save-operations at the lowest possible level, to make sure that the results of any side-effects caused by other hooks are captured??)

There was a short wave of WYSIWYM (what you see if what you mean) editors at one point - one of which survived: http://www.wymeditor.org/ This does not address the visual disconnect that most normal users experience though - it probably makes it worse. I thought about using Twig templates as these micro-snippets - as there is a JS port of the PHP template engine, this would make it possible to render the templates in real time on the client-side, as well as storing the structured document/data and rendering it on the server-side. The other approach, is to render purely on the client-side, and send the document/data and rendered result back to the server, but this has one major drawback: if a template changes for some reason, you can't updated the rendered content. (same issue with buggy WYSIWYG's now, for that matter.)

I read it - I've read it every time, never occurred to me to post there. Sounds like the place to go for support as a user of a module. It does not say "development" anywhere in there. "Questions, answers and support for ProcessWire module development" would have had me posting there

EDIT: This project has been put on ice - I don't work with ProcessWire in my day job anymore, so this project is looking for a new maintainer. Knowing that, you can decide whether it's worthwhile reading through 7 pages of posts EDIT: The source code has been dumped on GitHub - feel free to fork and have at it. There's one thing about ProcessWire that pains me, and I've brought this up before - it's the same problem I have with e.g. Drupal... Because the meta-data (Configuration, Fields and Templates) is stored inside the database, once you have a live site and a development site, moving changes from the development site to the live site is, well, not really possible. Repeating all the changes by hand on the live site is simply not an option I'm willing to consider. Telling the client to back off the site and give me a day or two to make the changes, and then moving the whole database after making and testing the changes on a development site, is really a pretty poor solution, too. I had heard some talk about a module in development, which would make it possible to import/export Fields and Templates? It sounds like that would mostly solve the problem. Ideally though, I'd really like a solution that records changes to Fields and Templates, and allows me to continuously integrate changes from one server to another. So I started hacking out a module, but I'm not sure if it's going to work at all, if it's even a good idea, or if it's worth the effort. I'm looking for feedback on the idea as such, more than the code I wrote, which isn't real pretty right now. Anyway, have a look: https://gist.github.com/b7269bb7bd814ecf54fb If you install this, create a "data" folder under the module's folder - migration files will be written there. Basic overview of the idea and code: The module hooks into Fields::load() and takes a "snapshot" of the current Field properties and settings on start-up. It also hooks into ProcessField::fieldSave() and when a field is saved, it compares it's properties and settings to the snapshot it took at startup - if changes were made, it writes the previous name and updated properties into a file. The same thing is not implemented for Templates yet, but would be. The migration-files are named like "YYYY-mm-dd-HH-mm-ss.json", so that they can be sorted and applied in order. Each file contains a JSON representation of a method-call - currently only updateField() which would repeat a previous set of changes and apply them to another installation of a site. (not implemented) So basically, the module would record changes to Fields and Templates, and would be able to repeat them. How those files get from one system to another is less of a concern - would be cool if servers could exchange migrations semi-automatically, using some kind of private key system, but initially, simply copying the files by hand would suffice. I'm more concerned about the whole idea of capturing changes and repeating them this way. Any thoughts? Is this approach wrong for some reason? Would this even work?

Glancing over the list of forum areas, I'm never sure where exactly to take discussions about module development. Do we need a Module Development forum area perhaps? Or could one of the existing areas have the words "module development" added, so I'm sure where to go?

@teppo I don't disagree with any of this - you're basically saying what I said my previous post, that every node in PW is a folder with a default document attached to it. I guess at least in part, what gives rise to confusion here, is if you created a node called "products", it's probably hard to abstract from the fact that "products/ipod" is actually a folder - since this is the individual product, and most likely the end-node, why would you think of it as a folder? Some nodes are invariable leaf-nodes, and are unlikely to ever have children. In some ways, I would almost find it preferable to have an extension that indicates explicitly whether you're referring to a document or a folder - or rather, whether you're referring to the node/folder itself, or to the document attached to it. If you were building a static site (without a CMS), this is how you would do it - "products.html" is obviously a document, while "products/ipod.html" is obviously referring to a document in the folder named "products", which is conceptually a different thing from the document named "products.html", or in the case of ProcessWire, the document named "products". I think the confusion arises from "products" essentially being two things in ProcessWire: "products" the folder, and "products" the document. This is not consistent with filesystems, where you can't have both a file and a folder with the same name.

Come to think of it though, the problem is actually this: The trailing slash option is presented to you as a merely cosmetic thing, which really isn't consistent with the way that URIs work - the trailing slash is not just cosmetic, it actually gives the URL a different meaning, hence the problems with relative URLs, as well as (evidently) with a person's interpretation of it. The disconnect here, is the fact that "can the page have children?" is presented as a separate option from the trailing slash in the first place. Think about it: "foo/bar" is like "foo/bar.html" - it references a named document "bar" or "bar.html" in the folder "foo". Meanwhile, "foo/bar/" is like "foo/bar/index.html", which isn't the same thing at all - it references a default document in the folder "foo/bar". In other words, the trailing slash indicates (to browsers as well as to people) whether the last literal in a URL is a folder or a document. In a physical file hierarchy, only folders "can have children" - documents of course cannot "have children". In other words, for this behavior to be consistent with the standard URI scheme, things that can "have children" are folders, which is indicated by the trailing slash, while things that cannot "have children" are documents, which is indicated by no trailing slash. From this point of view, you really ought to have only option: "can the page have children?" - if so, it's a folder, and it gets a trailing slash, otherwise it's a document, and does not get a trailing slash. The option to manually control the presence of the slash shouldn't be present, because it enables you to break URI conventions. Just presenting a point of view here - I'm not trying to dictate anything, just giving the subject a good turn-over

Actually, I think I'm going to have to withdraw that statement. In ProcessWire, every page is a folder - there is really only one type of node. I guess the underlying problem or cause of confusion, is that the URI protocol, as such, distinguishes folders from files, and ProcessWire does not. This is one of the things I like about ProcessWire, so I'm not trying to argue against it, but it really does result in rather ambiguous URLs that are not interpreted the way a URI is normally interpreted. Case in point, consider the URI "foo/bar/": The way a URI is normally interpreted, this means: give me the default document under the "foo/bar" folder. The way ProcessWire interprets it, this means: give me the "bar" document under the "foo" folder. Now consider the URI "foo/bar": (without the trailing slash) The way a URI is normally interpreted, this means: give me the "bar" document under the "foo" folder. In this case, ProcessWire is consistent with normaly URI interpretation. One way to look at this, is to say that documents in ProcessWire do not have names. That is, the URI always indicates a folder-name, and it just so happens that ProcessWire always has a single, nameless, default document associated with every folder. From that point of view, eliminating the trailing slash is actually wrong - and the problems you have with relative URLs are just a result of the folder/document ambiguity that results from doing so...

Duh, it was turned off! ... it's hard to see on the icon in the client that it's even possible to turn it on/off ... man, I'm having a slow day

Anywhere. I've tried including and calling from a module, from index.php, and from the config-file. I'm using it on other projects, so I know it works. Just doesn't work on this one. Odd....

display:inline-block; width:auto; margin:0 auto; ?

All good points. Let's name it according to the primary use-case then - how about rotate() or alternate() ?

Understood. Maybe there should be a third option called "default" - where the use of a trailing slash or not is conditional on whether the Page allows subpages? Given what you explained, perhaps this is actually the correct default behavior? - so we would have nice, "final" looking URLs for end-nodes, trailing slashes for potential parents. The default behavior could also be conditional on whether or not the Page has any subpages, but this seems riskier, since URLs would change when you add/remove pages, so probably not safe. It seems safe to assume though, that a Page that isn't allowed to have sub-pages, won't Thoughts? Edit: a better name for this option would be "if Page can have children".

Boy, do I feel dumb now I'm not even sure how I managed to conclude that the indices were IDs... The real problem in my case was that $pages->count returns null, while $pages->count() returns the actual number of items. (unrelated, but that seems to throw me off more often than not...)

Anyone else attempted to use ChromePhp for debugging with ProcessWire? It doesn't seem to work - doesn't output errors or anything, just doesn't seem to do anything at all...

I find myself doing a lot of this: <?php $index=0; foreach ($pages as $page): $index++; ?> .... <?php if ($index != $last_index): ?> <hr /> <?php endif; ?> <?php endforeach; ?> I find that I need $index variables often, because foreach($pages as $index=>$page) does not work - because $index is the Page ID and not the item index. Why is that? I can get to the Page ID in any number of other ways, if I need it - $page->id works fine for most uses. Rarely do I find myself actually needing to access a Page in a PageArray by it's ID - and if I did, $pages->get($page_id) would suffice just fine. Array indices are commonly useful, and they really should be numeric indices, and not some other key. My point is that items in an array do have an index - but that index is hidden/inaccessible during iterations with PageArray, which favors a specific use-case. Numeric indices are generally useful in lots of different use-cases, and in all of those, you're now forced to introduce intermediate variables... I guess it may be too late to change this without breaking backwards compatibility, but maybe something to put on the to-do list for a major release...

You, Sir, have awesome facial hair! You also solved my problem, thanks!

I built a basic "block" system, with reusable "blocks" you can add to sidebars, etc. - using just a couple of AsmSelect fields, and it's working great! No code was necessary, just a couple of fields and a few simple templates. One of those blocks is a menu-block, where the content manager can build a list of pages that should appear in a menu, which you can then add to any page. That's working fine too. Where I'm stuck, is I'm looping over my list of blocks and rendering them, like so: <?php foreach ($blocks as $index => $block): ?> <?= $block->render(); ?> <?php endforeach; ?> Very simple - I have different types of blocks that use different templates, and this works nicely. But I'm having a problem with the menu-block, which needs to know which Page is currently being viewed, so it can add an "active" class to the list-item. My menu-block template looks something like this: <ul class="menu-block-links"> <?php foreach ($page->pages as $item): ?> <li<?= wire('page')->id === $item->id ? ' class="active"' : '' ?>><a href="<?= $item->url ?>"><?= $item->title ?></a></li> <?php endforeach; ?> </ul> The problem here, is that wire('page') seems to get overwritten whenever you render() a Page? In other words, wire('page') gives me the menu-block, because that's what's currently being rendered - but what I need is the Page that was actually requested. Is there any way to get your hands on that, or is it lost as soon as you call render() on a Page??

This is turning into a different discussion, but I don't really care which WYSIWYG editor I use - they all suck, they just suck in different ways. At the end of the day, WYSIWYG (for most clients) is just not a good idea in the first place - clients are notorious for messing up designs, pasting bad markup, pasting from Word, picking colors that don't fit the design, and so on and so forth. Most WYSIWYG editors go to great extents to try to suppress and clean bad/faulty markup, and succeed to varying degrees, with varying degrees of negative impact on those of us who do know HTML. I have long been thinking about a new kind of WYSIWYG editor based on structured snippets, rather than raw markup. I believe it is possible to provide a WYSIWYG experience, giving the client the freedom they need, without giving them the power to mess things up - while at the same time, actually providing them with something that is faster, easier and more comfortable to work with. I have been coming back to this idea now and then for at least five years. Anyway, I'm going completely off-topic here...

Okay, it looks like this is a bug in Chrome - I don't think this is specific to TinyMCE at all. I became suspicious of this today, when I experienced the same problem with an iframe on a page that was not using TinyMCE at all. This bug was first reported on the Chromium bug tracker on August 17: http://code.google.c...etail?id=143354 So hopefully they're working on a remedy - please go and vote for this bug, and don't start integrating another WYSIWYG port for this reason, because it'll most likely just suffer from the same problems...