ryan

Nice module slkwrm! Don't forget to add to the modules directory.

I like MadeMyDay's solution. A couple other possibilities are: 1. Use MarkupCache rather than template caching. That way you can cache just the parts of the output that you want to, and leave the things like your counter uncached. 2. Create an autoload module. Add a ready() function to it and have that function increment the counter of $this->page (using the same method you are already doing).

I'm not sure why you'd be getting a Page by accessing that, I would think it should be null. What do you see from get_class($repeater->images)? However, I want to mention that Pagefiles/Pageimages aren't indexed by number, they are indexed by filename, so am thinking at the moment that $images[0] may not relate to anything. $repeater->images->eq(0) is probably what you were after, or $repeater->images->first().

It's also just fine to use jQuery UI tabs if you prefer. WireTabs are mainly useful for tabbing PW's Inputfields, which jQuery UI tabs don't let themselves as well to.

I think the same applies whether site profile or not. Where have you written all your code? I'm guessing primarily just /site/templates/* but possibly /site/modules/ too.

Just wanted to clarify that it keeps the template names and meta data in memory, not the template files themselves. If you are seeing the basic-page.php file open in your debugger, and a page using that template is not being rendered, that doesn't sound right, so let me know.

The simplest solution would be to just put the 'featured' page reference on your homepage, and select the featured page from there (via a PageListSelect input). But if you need to do it from a featured checkbox on the actual page being featured, then you might want to add another component to finding the featured page: $featured = $pages->get("featured=1, sort=-modified"); That would pull the page that was most recently modified and featured. It would also be relatively simple to un-feature pages via a module or in your template, etc. $allFeatured = $pages->find("featured=1, sort=modified"); $featured = $allFeatured->pop(); foreach($allFeatured as $p) { $p->of(false); $p->featured = 0; $p->save(); }

PW keeps the meta data for all the templates and fields in memory. So I would expect to see basic-page somewhere in there whether it's used or not. This is basically just caching. Templates and fields aren't assumed to be infinitely scalable in quantity like pages are, so we take advantage of the performance benefits of having those things ready-to-go in one query. However, you shouldn't see any "template files" loaded that aren't being used in the request.

I think you guys are right on about this. I remember years ago (1990s?) I was using a full blown IDE, debugger and profiler. But I've rarely used such things in PHP. I suppose from-scratch debugging in PHP is a lot simpler than things I've used in the past, so it just hasn't come up as a need. I did experiment with XDebug years ago, but seemed like it was costing me more time than it was saving. Now I'm curious again, thinking I might benefit from a PHPStorm + XDebug setup in some situations (like mindplay.dk has mentioned as well).

Awesome module and really nicely produced! Thanks for making this. I ran into a couple really minor things, but figured I'd mention them before I forget. 1. Saw a couple PHP notices at the top of the screen, but can't remember exactly at what part. However, I'm guessing anyone with debug mode on will see the same. 2. Getting an overflow on the search keywords screen: Great job with the module and the code.

You'd just want /site/templates/ right? Or perhaps /site/modules/ too if you've got any module dependencies in the templates. If you want to make it installable as a site profile, then you'd want to run the site profile exporter and include the /site/install/ directory too. But you'd want to double check that none of your module-specific passwords are getting included in the profile.

The size() function is basically returning a brand new Pageimage object, so if you wanted kelvin to do the same, take a look at the size() function in /wire/core/Pageimage.php -- let me know how this works out.

I've been adding all of interrobang's PHPDoc comments to the core source code dev branch (great additions interrobang!) so thinking this will help a lot too.

Great, glad that worked. I'm putting a lot on the dev branch this week but will pull it all in next week. My internet access isn't all that consistent this week, so figured I'd avoid any unnecessary master commits temporarily.

I'll take a look and fix this when I get back to my office next week. I think I've already fixed this issue once already (with IE8) so it might be as simple as canceling a behavior if the IE version is 9 or above.

Default values sound good as a feature, but in practice the need seems to be rare in ProcessWire. There are so many other (usually more efficient) ways to accomplish the same thing. So when/if we implement default values, it'll probably be more about appealing to people's sense of features rather than something that will actually add much value. But there are those rare instances: like a page reference field with categories where you want 3 of them selected by default... I don't think I've ever had the need, but can see it coming up for somebody.

Someone correct me if I'm wrong, but IE9 doesn't support the HTML5 FileAPI, which IE10 does? To drag files into the browser and have them upload using HTML5 methods, the browser has to upport FileAPI. The only modern browsers that I know of that don't currently support that are IE9 and Safari.

A default value that is displayed but not stored is really no different than having no default at all. But one might assume that they could go perform a find() or something and match pages having that default value, and you couldn't. So it introduces some confusion there. There's also the danger of the default value getting set back to the field and inadvertently saved. That's why I kind of prefer letting the developer decide when and how to implement their default value in their own code. There's no ambiguity about it. But I do still think we'll want a "populate for new fields" like Adam mentioned, for some fieldtypes. The best example is a checkbox that you want to be checked by default.

Remove the "autoload" and "singular" lines from your getModuleInfo function.

I think that much of it would be simpler to implement than with TinyMCE, as the API looks super-simple and straightforward. At the same time, I don't think this editor is anywhere near as broad in scope as TinyMCE, but it probably crosses over with much of what we like TinyMCE for. I don't think we'd want to put a lot of time into building full integration around this editor, given the ambiguous license that says it's GNU compatible but obviously isn't. But I do think it's worth some trial and experiments. Rather than have anyone buy a developer license, we'd probably just include in the instructions where to download Redactor and where to put it's files. Then if people are really liking it, we can go for the developer license to make installation a 1-shot deal. But I think we'll have to keep this 3rd party (non-core) to avoid license interference.

Ouch I thought we were in the clear with IE9. But it's not a browser I use every day (running in OS X). Can anyone else confirm the issue? I'm not at a place where I have any access to IE. But the issue does sound like one that should be fixable on our end rather than TinyMCE's (since the add image implementation is part of our own TinyMCE plugin).

Glad you were able to solve this. Sorry I'm coming to the conversation late. You would have to do the same things to support Apache's RewriteEngine in any CMS. Most CMSs use this for URLs, so it's rare to find a web host that doesn't have it enabled by default. But if you are setting up your own *AMP that's not pre-configured for web hosting, then you do have to go through the steps you just did to solve it. Many legacy CMSs (like EE for example) came from a time before Apache's Rewrite Engine was used much, and thus had dynamic variable URLs and /index.php/path/to/page style URLs. These are a little simpler if you are starting from scratch on your own server, but you'd never want to launch an actual site using this style of URLs. As a result, support for that has been left out of ProcessWire, and it requires Rewrite Engine.

Thanks for the kind words, glad that you are enjoying ProcessWire. Regarding the module, I agree that Antti's Thumbnails module is probably the best one to look at since it is the only one I know of that lets you manipulate images in the admin like this. This line above I wasn't sure about. What you are attempting to do is add a "kelvin" method to a class called "Images". But I'm not aware of any class that we have called "Images", so don't think that this hook would do anything at present. Instead, you may want to add it to the "Pageimage" class: $this->addHook('Pageimage::kelvin', $this, 'kelvin'); public function kelvin($event) { $arg1 = $event->arguments[0]; // if needed $arg2 = $event->arguments[1]; // if needed $image = $event->object; // Pageimage object you are operating on // ... } That's assuming that the module goes the route of Antti's Thumbnails module. But if it's something that continues in the direction of the posted module code example, then it probably doesn't fit as a Fieldtype. Also, all Fieldtype modules should descend from the Fieldtype core class (or one of the other Fieldtypes descending from it).

I would probably just do as you said and give them a message. You could also have the module refuse to uninstall until they remove the directory by throwing an exception: if(is_dir('/path/to/views/')) throw new WireException("Please remove your /path/to/views/ dir before uninstalling."); I have added this update to the dev branch if you want to try it out: https://github.com/ryancramerdesign/ProcessWire/commit/bd5e549bc187a91cda47330181d5481674c41003

I think this would be the way to go, solving it with terminology. However, if someone is going to have a lot of the same default value in their database, it would technically be better for them just to leave it blank and then assume the default value from the API side. That way you aren't storing a bunch of duplicate entries in the database. It also solves the issue of what to do when the needs of the default value change. Beyond the issue, this is partly why there isn't a default value in PW now, because I've always used blank to assume a default. Automatically-populated or default values seem like an easy way to store a lot of redundant/duplicate values in the database, making it very unnormalized. So while it seems useful to have default values on the surface, I think there are a lot of cases where they introduce unnecessary overhead.