ryan

Because when PW presents you with an upload field, it wants to know where the file is going to go. There's more to it than that too. Every page has an optional delegate object called a PagefilesManager. That class manages all disk-based files for a Page and it doesn't know anything about who's using it (whether a Fieldtype, Inputfield, API access, etc.). This is a good thing. And it's only called on demand. But when it's called, it makes sure there is a place for that page on the drive. Ultimately, it's not just having an file/image field that causes the directory to be created, it's the actual calling upon the file/image field, which ensures they have a home. A prerequisite for a file-based asset is a place to put it. This limits the dependencies and complexity between these systems and it's the way I think it should be. They could be, but that's trading processor time for disk space. Disk space is cheaper. I also think that if you are putting file/image fields on huge quantities of pages that don't need them, you are adding unnecessary overhead to runtime that's a far bigger affect to performance than some empty directories on your server. If you've got tens of thousands of pages with file fields on them that you edit in the admin, and you don't want them to have directories, then run the new empty dirs module once in awhile.

Thanks for the testing guys. I'm actually thinking the problem might be in this function from /wire/core/Pagefile.php: public function setFilename($filename) { $basename = basename($filename); if($basename != $filename && strpos($filename, $this->pagefiles->path()) !== 0) { $this->install($filename); } else { $this->set('basename', $basename); } } I think that Windows must be returning a different path or $filename than where PW stores them (perhaps an alias, or wrong slashes or drive letter in it or something). Can you try replacing the function with this? public function setFilename($filename) { $basename = basename($filename); if($basename != $filename && strpos($filename, $this->pagefiles->path()) !== 0) { $this->message("Filename is: $filename"); // ADD THIS $this->message("Basename is: $basename"); // ADD THIS $this->message("Pagefiles path is: " . $this->pagefiles->path()); // ADD THIS $this->install($filename); } else { $this->set('basename', $basename); } } This should reveal what's going on, I'm hoping. I'm double posting because I know editing it will break the code examples. But wanted to mention that the part where I added "ADD THIS" is what I suspect is getting called, and it shouldn't. But if we've got different paths to the same file, that would explain the problem. What do you know, it connects double posts automatically now... here's my triple post, betting it gets appended to the first. Nice upgrade Pete.

It sounds to me like the master module doesn't know ahead of time what the slave modules are? Otherwise, I'd say let the master call them up on demand as it needs them. But based on what you said, I'm going to assume the slaves might know about the master, but not the other way around. What I would do is have the slave modules descend from a common class or interface: class AdamSlave extends WireData implements Module { } // or interface AdamSlave { } Then let the slave modules extend or implement that (whether you add any functions to it or not doesn't matter for this concept): class AdamSlaveTest extends AdamSlaveModule { ... } // or class AdamSlaveTest extends WireData implements Module, AdamSlaveTest { ... } What you are doing above is just establishing a common type for your slave modules, so that your master can identify that they are slave modules. But since PW doesn't actually keep modules in memory (unless they are autoload) you also need to be able to identify them by class name. This you can do without loading all the modules because PW just keeps tiny placeholder objects for them in memory with a className() method that reflects the full modules real class name. In fact, the creation of a type above is just a secondary confirmation and you could technically get by without it (though I wouldn't). So what you need to do is name all the slaves in a consistent format like ProcessWire does for Inputfield or Fieldtype modules. Lets say that you've decided your name format will be "AdamSlave[something]" as above. You'd name your module classes like this: AdamSlaveThis AdamSlaveThat AdamSlaveSomething AdamSlaveSomethingElse (or whatever) Now you can probably guess how the master finds them: $slaves = array(); foreach(wire('modules')->find('className^=AdamSlave') as $slave) { // use instanceof just to double check this is really an AdamSlave // this is just in case someone else uses the name 'AdamSlave' for // something else in the future, it won't break your module if($slave instanceof AdamSlave) $slaves[] = $slave; } Now $slaves has the modules you want, ready to use (their init() method will have also been called at this point).

It gets created the first time a file or image field is accessed on the page (even if it's an empty file/image field). If the page has no file/image fields, then the directory won't get created. If you create a page with the API and don't populate the file/image field, the directory won't get created at that time. Though if you create a page in the PW admin, you'll likely see its directory created when the page is created (since ProcessPageEdit iterates all the page's fields when it saves). Ultimately you'll still have empty directories, but they will only be for pages that actually have the file-based fields to need such directories.

If anyone wants to stake a stab at it, I think this is where I would start if I had a windows machine to test with. This is in the file /wire/core/Pageimage.php: public function removeVariations() { $variations = $this->getVariations(); $this->message("There are " . count($variations) . " image variations"); // ADD THIS foreach($variations as $variation) { $this->message("Removing file: {$variation->filename}"); // ADD THIS if(is_file($variation->filename)) unlink($variation->filename); } $this->variations = null; return $this; } The two lines above that say "ADD THIS" are the ones I'd add to this file. Now when you delete an image, you should get your messages on the next screen. Let me know what you get? Thanks, Ryan

This module goes through all of your /site/assets/files/ directories and removes those that have no files in them. http://modules.proce...ean-empty-dirs/ Pages with file/image fields require a directory, so you should expect that some of the removed directories will be re-created by these pages. As of today, ProcessWire no longer creates directories for all pages, so this module is mostly useful to existing sites rather than future sites. I am listing it as "alpha" just because I've only tested on my own sites. Once I get confirmation from others that it also worked well for them, I will change its status to stable. Until it is considered stable, I suggest only running it in dev/test environments (not that it does anything dangerous, but just a good practice).

Thanks Pete. Here's a link to the new module that removes empty directories from /site/assets/files/: http://modules.processwire.com/modules/page-clean-empty-dirs/

I just pushed an update to the source that should prevent it from creating directories for pages that don't need them. Next up: going to make a module that removes empty directories, for those that want it.

Does windows not support more than one period in a filename? That would be news to me.

I'm not sure I understand -- what extra "." in the filename? If there really is an extra "." somewhere, I'd want to look at that first. But I've not seen that before, so need more info.

Thanks for testing. I agree, it does sound like it's a Windows thing, but probably something we can fix if we can track down why the files aren't getting deleted in Windows. Can one of you running Windows try turning on debug mode (/site/config.php, $config->debug = true), then upload image, make thumbnail, then delete image. After that, go look in /site/assets/logs/errors.txt. Do you see any errors at the end of the file that look like they might be related to this?

Thanks ijsga! We're glad to have you here.

Can you clarify whether you are talking about the CropImages module that Soma mentioned or ProcessWire itself? There was no mention of CropImages, so wanted to double check. I did just test here, uploading a photo, making thumbnails in the API as well as through TinyMCE, and then deleting the original, but all thumbnails were also deleted (and they are supposed to get deleted). If you aren't talking about CropImages, I might need more info on how to reproduce and exact steps to follow. I don't think PHP version is a factor, but possibly platform. Also, what method are you using to confirm that the file is still there? Due to browser caching, the only way to tell if an image really is gone is to look on your file system in /site/assets/files/[page-id]/[filename].

The Map Marker Fieldtype/Inputfield is another good one to look at. It was originally created as a way to show someone how to make Fieldtypes and Inputfields, so it's documented in the code with that intention. Feel free to ask any questions that come up along the way. If you are able to, please share your module--it sounds like quite a useful field to have.

You are right it probably would be a theme job, and certainly doable in that context. As you probably know from the other thread, I don't like any more on the screen than I absolutely have to have at once. So keeping the page list out of the page editor is intended in the default admin theme. But I also understand why many might find it useful to have. Frames may not have a great rep, but that would probably be a good way to look at approaching it, so that the PageList doesn't have to reload on every request. And the editor wouldn't have to run on top of a layer of ajax/js. But there is likely a better way to implement it that I'm not thinking of. I think it would be a great option to have in one our custom admin themes.

I committed the update today that adds a template class to all the PageList items. The class it adds is PageListTemplate_[template name], i.e. PageListTemplate_basic-page. So it should make it possible for modules or admin themes to go further with icons, colors or what not. I don't think we'll be implementing any of this output in the core/default admin theme, but wanted to make it easy for others to add the capability if desired.

Doesn't sound like DB corruption, but there's no way to answer that definitively. You might try disabling those 3 modules just in case, but it seems not that likely that any of them would be interfering here. Can you PM me a link to this site so that I can try to access the URL and see what happens? I'll monitor the HTTP headers to get a little more detail about what could be happening. If you have an FTP login, this would also be helpful to get a look behind the scenes, but that's up to you.

I tried to implement a double click to edit a long while back. jQuery has the dblclick() event, which makes it pretty easy to differentiate from a click() event. The problem is, I never could get it working. dblclick() would never fire for me. It might have just been a bug in jQuery at the time or something. Maybe worth trying again.

I've now used Foundation (2 & 3), Skeleton and HTML Kickstart. Skeleton fits its name in that it doesn't really do anything more than provide the skeleton for a responsive site. It's not what I'd use for a rapid prototype because it still assumes you are going to handle most of the front-end development stuff (and this is one reason why I like it). I was pretty pleased with Skeleton when making the Blog profile, and didn't run into any real mysteries or time sinks with it. Foundation and HTML Kickstart provide a lot more stuff for rapidly prototyping. If you need responsive, then HTML Kickstart is probably out. But if you don't need it, then I would stick with HTML Kickstart. That's because Foundation has a tendency to sometimes fall apart as soon as you throw anything at it. Example: put one too many items in a horizontal nav-bar and it breaks the whole thing. Troubleshooting this stuff sometimes takes longer than if you'd just started from scratch. I don't think that they did much "stress testing" with Foundation. Whereas HTML Kickstart is much more bulletproof and a lot more stuff "just works" without requiring a lot of your time. In addition, it comes with a few more ready-to-use components than Foundation. No doubt that Foundation just plain looks good, but it's kind of fragile. Still, it's got more going for it than not. But out of these 3, if you don't need responsive, I prefer HTML Kickstart.

The subfields on page references update is now committed in the core so that you can do these types of queries (as mentioned above): referenced_pages.title*=$query Also want to mention a limitation: You can't do this with in-memory selection (at least not yet). So the find(), filter() and not() in WireArray/PageArray won't recognize this… just the PageFinder ($pages API var). I'm guessing it'll be awhile before someone even tries it, but just wanted to mention it. I think so. It was a pretty simple matter supporting the subfields of page references, so I think the same would go for parent. I will look into it here more and hopefully get this added soon. Seems like a very nice thing to have. This bug should now be fixed and committed to the core. It sounds like MadeMyDay mentioned this issue too (?), but somehow I missed that message. Thanks to both of you for tracking it down and sorry I missed the message about it the first time around.

That makes sense to me. To add to your list of ways to check, here's another that should be pretty bulletproof: if(strpos($page->url, wire('config')->urls->admin) === 0) { /* hello admin */ }

And would be nice to have Nico add this and his other modules to the directory too (when you have time, of course).

The fact that /abouts/ worked and /about/ didn't makes me think this is browser cache. Can you try from another browser? Sometimes browsers get a redirect cached in there and it's hard to clear. I don't think that you should need anything for your RewriteBase--leave it commented, and try from another computer/browser to see if it does the same thing. Another thing to check is if you have any modules installed that might get involved with redirects, like any of these: http://modules.processwire.com/categories/seo-accessibility/ ... I don't think any should cause problems, but it would be good to know if there were any other factors at play, just in case.

This is really a beautiful site you've put together here! Thanks for posting it.

I agree that type of functionality is very useful. I think that Nico's blog module basically did this. But there is no doubt a lot of untapped potential here, and possibly dedicated tools to use for the import/export of this stuff.