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.

@SiNNuT either here or GitHub is fine. But since we're here, might as well just submit it here. I did commit a few updates this morning, including a fix for the /site/profile/ vs. /site/templates/ typo. I honestly have no idea where I got /site/profile/ from… I need to get more sleep.

I would go ahead and do the redirect that you are talking about. Most likely your output is getting generated before your $page->save(), so the redirect should solve that issue. It also prevents a 'reload/refresh' from re-submitting the form. Basically, there are a few good reasons to redirect after a save, and that's also what PW does in it's admin. You don't necessarily have to redirect to another page, you could just redirect back to the same page, right after you complete the $page->save(), i.e. $page->save(); $session->redirect('./');

You can do this: $cache->removeAll(); If you want to remove an individual cache, you'd want to do what Pete suggested.

The cache is not connected with any page. The only thing that identifies it is the name that you provide for it in the $cache->get('name-of-cache', $seconds); call. It only works for strings. It's intended to cache markup (HTML) per the name MarkupCache. But I don't see any reason why you couldn't serialize an object to a string and cache it with MarkupCache, but you'd have to do the serialization yourself. When the cache is cleared is determined by the duration you specify (in seconds) as the second param to the $cache->get() call. You can also configure it to clear on every page save in the module settings (Admin > Modules > Markup > Cache). There is also a manual cache clear toggle there as well. Modules, templates and core in ProcessWire all use the same stuff, so there's no limits there. You could certainly use it from a module if you wanted to. But get() your cache only when you intend to output it or save it right there, because cache calls can't be nested.

Sure, if it's not any trouble that'd be great. I tend to make changes manually (copy/paste or re-type) from pull requests just so I don't miss anything, but actually having the pull request is a good help thanks to GitHub's very clear diff tracking.