Leaderboard

Woo! Progress!! I fixed the main bug and it is now working. A couple of limitations so far. No easy way to clear the cache, which is in a bad spot to begin with. Is there any way to integrate Twig's cache with PW's? At the moment I have just made a cache folder under my site/views folder. As the cache needs to be regenerated every time the template.php or twig view files are edited are there any suggestions for making this a simple process? I thought maybe have some url/page/?cache=clear get function? Would this be easy to do? Still have the __DIR__ paths in the module itself. I found out the problem with the $config->urls variables was to do with my .htaccess rewritebase having a ~porl at the beginning. I couldn't find an easy way around it (changing it to /home/porl broke other things so I don't know how else to do this setting. Any ideas?). Apart from that it seems to run brilliantly.

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.