mindplay.dk

You only have a handful of Page objects and Fields? I think you misunderstood - this does not provide IDE support for ProcessWire (which still needs a lot of work in this area) but for your templates and fields. I'm sure you have more than a handful on complex sites, and I'm prertty sure they're not always the same? It's not about simple or difficult, it's about proofing your work - knowing in advance if you misspelled a property-name, or not having to go back to find the name of a property on an admin-screen, it saves time. With inspections in PhpStorm, there is also the added benefit of being able to automatically find errors - if you have dozens of templates and you have to make a change like renaming or deleting a field, automatic inspections will instantly reveal which templates are affected. Most of my day-to-day work is not little projects, but large complicated business-systems - while I used to be able to keep it all in my head, I'm not getting any younger. A good IDE will help you stay fast and accurate when you grow older, wait and see

Some updates: a use-clause is now generated, pretty big oversight there. PageReference types are now documented with their pseudo-types, which means you'll be able to directly follow a reference to a related page (or list of child-pages) while still getting IDE support. I simplified the class-name convention - "basic-page" now simply becomes "tpl\basic_page". And the generated documentation can now be viewed on the configuration-screen - you will see it when you install the module.

In Fields.php#415, the invokation of changedType() doesn't match the hook method - you forgot to pass in the $fromType and $toType arguments. EDIT: I added the missing $fromType and $toType arguments and integrate the new hooks - I noticed one important change immediately, when changing the Field-type, there are actually two events during the same request, first changedType() and secondly saved(), and those get correctly recorded as one migration, in the correct order. So this works much better and is surely much safer than the controller-hooks. Thanks!

I just noticed something odd too - sometimes, the number of pages is incorrect when you're viewing page 1 of a longer discussion. See here for example - it displays "page 1 of 4", but it only shows page links for pages 1 through 3 ... once you go to page 2 or higher, the 4th page link appears.

I've tagged and released version 1.0.4 with various minor improvements and fixes. NOTE: uninstall 1.0.3 before upgrading! It looks like dependency on the new icon-selector causes breakage if you simply drop in the new files.

This module generates a "stubs.php" file containing PHP-classes with documentation for the properties of each Template, based on it's fields - which means IDE support (auto-complete, inspections, documentation) for templates in modern IDEs that perform static analysis, such as PhpStorm. The output looks like this: <?php /** * Generated by TemplateStubs module 2013-04-13 15:29:33 * This file may be overwritten at any time. */ namespace tpl; use Page; /** * "basic-page" template * * @property string $title Title * @property string $headline Use this instead of the Title if a longer headline is needed than what you want to appear in navigation. * @property string $summary Summary * @property string $body Body Content * @property string $sidebar Sidebar * @property Pageimages|Pageimage[] $images Images */ class basicpage extends Page {} To use the generated documentation, start your template-file like this: <?php /** * @var tpl\basicpage $page */ Documentation and more details on this page: https://github.com/mindplay-dk/TemplateStubs You can consider this an alpha-release - I haven't tagged a release yet, and some details like template-class naming convention may change before I tag release 1.0.

Sounds good - though I am somewhat concerned about the reserved keys in $options, but I guess that's inevitable since they're already in use. They should probably be documented in the API, so that people don't accidentally overwrite reserved values. EDIT: you did already document them

@nik Gotcha! Thanks, that works better @ryan I favor the first option - I would prefer to have execute() and finished() trigger consistently. However, it may break backwards compatibility with existing modules that rely on finished() not getting triggered. Probably very marginal, though in theory it could cause a hiccup in some module... ProcessWire::shutdown() would be my second choice - if that's what you choose to do, I think it would also make sense to pass an argument to the hook, indicating what the result of the request is, e.g. the HTTP status code, or maybe just a true/false flag indicating whether the result is a redirect?

Yeah, I tried a before-hook on Session::redirect() but that doesn't seem to work either... I've resorted to __destruct() before but don't feel comfortable doing that in this case, since the order in which other objects get destroyed is unpredictable and might cause weird side-effects - if wire('templates') or one of the Template objects have been destroyed by the time my __destruct() method is called, for example, iterating through Templates or saving them could go horribly wrong. I posted the code here...

Is there a reliable shut-down or post-request hook in ProcessWire? I tried ProcessPageView::___finished() but it doesn't get triggered when there's a redirect - most admin-forms use a post/redirect/get approach, so there's no hook until the following request, which is too late. What I'm trying to do, is raise a flag on a number of different events - if templates or fields are saved, for example, I need to do some work when the request ends. Since the Session::redirect() method does a hard exit() the invokation of finished() in "index.php" is missed... Any ideas?

Looks like FieldtypeDatetime currently ignores timezone issues? Seems like this needs to be addressed somehow, at some point - it's fine if your applications are used in one timezone exclusively, or if users are aware that all timestamps are in ET say, but it seems this is going to be inadequate for applications used even across multiple timezones in the US, which most US applications probably are. This problem is particularly serious if you're storing dates only - since, without timezone information, a single date actually spans a 48-hour period worldwide. You can't really convert dates if you don't have a time. I would strongly prefer to have all timestamps stored in UTC in the database - with the ability to auto-detect a default timezone for anonymous users, and selecting a timezone for registered users. Anything like that already in the pipeline?

Just re-read your message, and just wanted to make this clear: I do not make assumptions about your design. When I ask questions, challenge your ideas, or propose alternatives, I'm merely testing the boat to see if it holds water - it's nothing personal, it's just the way my mind works. And most of the time, you are able to clarify your objectives or explain your choices to my satisfaction ... as Einstein said, "question everything" - this is how we arrive, not at perfection, but as you say, the best possible choices gives the context and goals. Please assume that I'm trying to help - if my tone suggests otherwise, I apologize, I'm not always eloquent with my words. I never got on the Drupal, Joomla or WordPress forums to try to help there - because I never saw any of those projects as being worth my time. This project is. So I hope you'll put up with me, even if I ask obnoxious or provocative questions at times. As Rafael Dohms just pointed out on Twitter: Discussion is evolution, whether you are right or wrong the exercise of discussing will teach you something new.

You rock, ryan