mindplay.dk

A few more tweaks today, and apparently a bit more work to do still - the script was not handling built-in PHP classes and interfaces correctly, and still doesn't handle it completely optimally, but better. Note that the script is now a lot slower - it may be very slow on your machine, depending. This is because the script now takes two passes already during the analysis, in order to provide more warnings...

Well, the script as such works - the problem is, there's a number of inconsistencies in the ProcessWire codebase itself... that's what all the warnings are about - these are issues you can't automate a script to fix. Long story short, the codebase needs some updates to conform with PSR-0 for autoloader interoperability. And, after running the script, some things will need to be tweaked manually - for instance, spl_autoload_register('ProcessWireClassLoader') will no longer work because it's now namespaced, so you'd need spl_autoload_register(__NAMESPACE__.'\ProcessWireClassLoader') instead. Anything involving strings would need to be fixed after running the automated namespace-migration. In summary, it's only really feasible to do the broad strokes using an automated script - this script isn't for end-users to convert ProcessWire (or any other codebase) on demand, it's a tool to help maintainers update their codebases to use namespaces...

I just fixed a bunch of issues in the conversion script and added buttons to convert/revert - I believe it's closer to finished now.

That's why I'm suggesting namespaces for version 3 - clearly there is no way changing all the class-names to using namespaces is going to be backwards compatible. Though on the other hand, I don't suppose it's unthinkable you could actually write out the class-name mappings from my tool, and derive an upgrade-tool that would rewrite third-party extensions and applications the same way it rewrites PW... I personally would worry less about upgrade paths - in my 14 years of experience, upgrading an existing application to a new major release of a framework is very, very rare. For the most part, it just doesn't happen - and major revisions should not sacrifice major improvements to support 5% of the applications that upgraded; most likely 95% of applications will be new applications...

I wonder, should I finish that script? Any interest? (Ryan?) I was thinking I might have it actually rewrite the code to a separate output folder, and (perhaps optionally) break classes into separate files, so that they can autoload without a class-map. Is this useful?

Sounds interesting - yes, import/export features would do it as well. You could encode entire change-sets, including binaries, as JSON if you wanted to - you could base64 encode them. Granted, there's a substantial performance penalty and bandwidth overhead to consider there, but it might be useful to have it as an option for those who do want to archive an entire change-set in a single file. Phar-archives would be another option - they are self-contained, bandwidth-efficient, and supported on every PHP installation. Worth considering anyhow.

It's a decision you'd have to make about how you're going to use the framework - for instance, if you decide that all development happens on your local machine, and you set up users/rights on the production site so that metadata (fields and templates) can't be modified, that simplifies things. I don't necessarily need a solution that enables me to create/change the metadata both on the running server and on my development server and then expect to merge them. That would be an extra benefit - but the key requirement is that I be able to develop the site off-line, and continuously integrate changes to the live site.

Makes sense. In my opinion, breaking backwards compatibility (with modules, as well as with the language itself) in something that should only happen with major releases of any platform. Major releases should target new development, while minor releases should target maintenance and provide an upgrade-path. For major releases, in my experience, providing an upgrade-path is "nice to have", but not "must have", as major upgrades very rarely actually happen in reality. Anyways, I'm sidetracking...

Alright, I added support for the "implements" keyword and tweaked/improved a few other things. The code is here. The issues described above (as relates to the PW codebase specifically) still persist - I can't (won't, shouldn't) fix those, but they should be easy to fix by hand. This is currently set up for testing - it's "non-destructive", at the moment it won't write any files, just lets you preview the changes on a file-by-file basis, so we can evaluate whether this looks correct, or whether this approach is feasible to begin with. Let me know what you make of this? EDIT: posted some additional updates and improvements. By the way, currently the core classes are namespaced as "wire\core" and modules as "wire\modules"... this is simply due to the folder-structure. I started tinkering with a "remapping"-feature that would allow you to override the mapping of a folder to a particular namespace, but quickly realized that was a total waste of time, since you can just rename the actual folders. In other words, to change the namespace-hierarchy, just move files around or rename folders as needed. But my guess is, we're already happy with the folder-structure of WP? Makes sense to me anyway. I think it would be fine to separate the core from the modules entirely. Also note, in the last update I turned of namespace capitalization. I used to argue that a namespace is a name, in the same sense that a class or interface is a name, and therefore all should be capitalized. But lately I've changed my mind - unlike a class, interface or trait, a namespace is not a type, and I prefer the visual distinction between namespaces and actual types... EDIT: another update - the script now reports inconsistent class/file-names, and produces a warning when multiple types are declared in the same file. I would prefer to see PW3 comply at least with the PSR-0 convention of one type (class/interface) per file. And use regular *.php file-extensions rather than the esoteric *.module extension - smells like Drupal. If you must use a magical file-extension, it's better practice to use a double file-extension, e.g. "foo.module.php", designating that this is in deed still a PHP file, with a special purpose, and preventing accidental loading by an auto-loader. On the namespace issue, consensus among those I have spoken to seems to be, both camel-case and all-lowercase is equally acceptable.

I just gave it a go - yeah, it seems to work. As said, it's not finished - looks like I still need to add support for the "implements" keywords for it to fully migrate scripts correctly. Some other minor issues with PW is it uses functions - I don't have any support for functions, just classes. Shouldn't be too much work to do those by hand though, only a handful of functions in there as far as I can tell. It also expects a 1:1 mapping between filenames and classnames... PW seems to break that convention in a few cases, e.g. "core/Array.php" actually contains a class "WireArray" - I'm not sure why that is... I will tinker with this a bit more and post my results.

That looks workable, probably fine for most sites. If I need something more complex, maybe I'll spend more time on this, but for the moment I don't feel like I'm missing anything... I had a chance to really dig in today, and I'm very, very impressed with what I've seen so far!

I tried to integrate parts of another site with ProcessWire today, and quickly gave up, as my existing (older) site has a bunch of classes in the global namespace that collide with some very generic class-names in ProcessWire: Database, Config, Session, Page and so forth. Would you consider introducing support for namespaces? Perhaps in ProcessWire 3.0, as clearly this would break backwards compatibility with the current API. Simply placing PW classes in a vendor-namespace (e.g. "wire") would probably be sufficient to avoid 99% of collisions. I think it would be great if PW-modules followed the "{vendor}\{package}" namespace convention for modules, as this eliminates practically all namespace collisions. Both conventions are compliant with the PSR-1 recommendation - though vendor-name is the minimum required, but I think that's fine for the framework itself. A "smart" IDE like PHP Storm could probably refactor most of the codebase to use namespace more or less automatically. If you're interested, I also have a script somewhere that rewrites entire codebases to namespaces, picks up folder-names and maps those to namespaces as configured. (it's not complete, but would probably get you roughly 971/4% of the way...)

Migrating changes to a live site is a big pain-point for me in Drupal at the moment - simply replicating changes by hand is not acceptable to me, not on a production-site, due to potential mistakes and "weirdness" during the repeat of changes, with features half-done or content missing in the interim. The root of the problem, is the idea of storing data (content) and meta-data all together in the database - treating it all as "one thing" makes for very efficient and elegant development, but makes it difficult (impossible really) to migrate changes incrementally. A couple of ideas to address this issue: 1. Separate data from meta-data. In my own CMF architecture that I've been dreaming up for some years now, meta-data is stored in flat files rather than in the database, which means you can check structural changes into a VCS, and deploy those changes easily. In the case of PW, this would mean you could check-in changes to meta-data along with matching changes to template-files, so that there is no chance of inconsistency between those. 2. Have a "recorder mode" that you can switch on during development. This would simply record all insert/update/create/alter SQL statements to a flat file, so you can repeat all the operations by just running that. Not quite as simple as it sounds though, due to primary keys possibly colliding with the same primary keys on the server you're deploying to - the only real way around that, as far as I can figure, is to not use numeric sequential keys, and use GUIDs instead. 3. Record (certain) form-submissions and controller/action, so you can repeat operations by simply running the controllers/actions again, essentially simulating the same sequence of requests that generated the original changes. Again, not necessarily as simple as it sounds, if for instance auto-insert IDs are posted via hidden-fields on a form, it wouldn't "just work". Clearly neither of these are a "quick fix", but I think it's something we should discuss - it's not a small problem that you can ignore, in my opinon.