ryan

I don't think it's practical for us to maintain one board per module, nor do I think any major forum software is designed to scale boards rather than topics. But I understand the desire behind the request -- longer term there will be some modules that need more than just a forum thread. In those cases, I would suggest that the module author setup their own forum or link to a GitHub support/issues page or something like that. In the modules directory, we just ask for a support/forum link. It doesn't necessarily have to be in processwire.com/talk/.

Looks cool Adam, I look forward to checking this one out!

I don't think it's a related behavior here. Ultimately $this->config and wire('config') are the same call. But $this->config gets passed through a __get() method method, so it can be interrupted if __get() gets overridden and doesn't pass control to wire() when it finds an unrecognized property. It's still a mystery to me as to why $this->config didn't work in your module.

I'm not sure how to answer just yet, but will take a look at this one when I get back next week. However, a good alternative might be to use the Language Alternate Fields (halfway down that page).

If you are running the latest commit of ProcessWire, there's not really any reason to run this module more than once. And when you start a new site today or in the future (using the latest version of PW), then there's no need to run this module ever. I think this module would only be worthwhile as a recurring maintenance task if you are running an older version of ProcessWire. The only other situation I can think of is if you had files fields on some pages and later removed the files fields, the directories would still remain as long as the page existed, and this module would remove them.

Thanks for your updates to this module, and for posting to the modules directory. My opinion is that the more you can help the user, the better, so long as it's something that can be removed in the same way during an uninstall(). If it's something that would be more tricky to uninstall, then maybe better to let the user create it so that they also have some ownership if/when it comes time to uninstall. Just to confirm, you want to have a way to prevent ProcessWire from throwing an exception when a method is called that it doesn't recognize? You could definitely override it for any given class, by extending the class and defining your own __call() method, but that will only affect calls to that particular class, and I'm thinking that's not what you want. It will be relatively simple for me to make PW's behavior (as to whether it throws an exception or not) configurable, so that may be the best bet, unless there's some way for Twig to catch the exceptions and continue normally.

Adam I'm not sure I understand the question fully, but if you want to poll for what functions are available in a given class, definitely take a look at PHP's Reflection classes (included with PHP5) as I think they may fit the bill for what you are asking. ProcessWire also uses them in a couple of instances, though for something different.

Actually I think your screenshot reveals the problem. Take a look at the "Filename is:" line: D:/wamp/www/pw-2.2/site/assets/files/1\lala_restaurant.0x100.jpg Notice how the slash right after the "1" is a backslash rather than a forward slash. Then notice that the Pagefiles path is correct (ending with a proper forward slash). Now the question is where that backslash is coming from. I'm really starting to wonder about a PHP bug here. Look at how PW constructs that filename: $filename = $this->pagefiles->path() . $basename; We already know that $this->pagefiles->path() ends with a proper slash from your screenshot. It's getting replaced somewhere. But I don't see any code between the two functions that manipulates it. I need to get XAMPP installed on my wife's laptop so I can properly debug this. Thanks for your help testing here.

I'm guessing Media Temple? That's the only place I've seen allow_url_fopen disabled. It is only a security risk with poorly written PHP code. Anything powerful is a security risk if it's coded blindly. Disabling allow_url_fopen makes a host feel more secure because they are placing extra limits on what you can do with your web hosting account. It means they don't have to have as many people looking after things (drives profit). It also means you have a disabled web account. Unless you are getting free or super-cheap hosting, I would not consider this type of intentionally-limited account unless there is an override for those that want it (like being able to specify your own php.ini to enable such things).

You can call the getChanges() method on any object in ProcessWire and it'll return a plan array of field names that changed. So what I think you are looking for is $page->getChanges(). This assumes that change tracking is enabled for the page (which it usually is). $page->setTrackChanges(true); // true to turn ON, false to turn OFF $page->resetTrackChanges(true); // clear the change log and start tracking again $changes = $page->getChanges();

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.