adrian

PW caches any image sizes you create with $image->size(), $image->width() or $image->height(). They are all stored in your assets folder and called directly if they already exist.

Why the "deny from all" ? Do you have something overriding that elsewhere for the site specific directories?

Phillip - thanks for a great writeup of your experience. To be honest, I am starting the get the feeling that too many clients/developers don't know/care about image file sizes. It amazes me the number of sites that I visit these days that have images of 500Kb to 1MB, sometimes bigger. I think some have gotten caught up in fabulous full page images, but don't realize that they can be made smaller and still look good. Also, I have to say that I think I would have a hard time getting clients to fork out an annual subscription for an image compression service when with a little care they can make sure the images are properly compressed before uploading. Of course this will depend greatly on the client - I am sure some will love the ability to not have to worry about anything when uploading images and would be happy to pay for your service. I hope your new pricing model works out for you - best of luck!

http://modules.processwire.com/modules/audio-mp3/ and also: http://modules.processwire.com/modules/local-audio-files/

Hi gunter and welcome to PW. I am not sure why you are losing fields - perhaps you can elaborate, but regarding template name changes - if you go the advanced tab of the template settings you can rename the template. You can also choose to use an alternate template filename if that is at helpful in your scenario. Hope that helps.

That's weird that you are seeing that. I get the following in this order: <script type='text/javascript' src='/wire/modules/Jquery/JqueryCore/JqueryCore.js?v=183'></script> <script type='text/javascript' src='/site/modules/ProcessPageDelete/ProcessPageDelete.js?v=1'></script> and the confirm alert works fine!

Hey Nico, I am curious why you went back to the old method for loading the js file? The way you have it now referencing an external js file doesn't seem to be causing the issues I was having with your old way of injecting the script code directly, but just wondering why you aren't letting PW handle the js file inclusion? Also, while I think of it, it is using .live which is deprecated and needs to be replaced by .on Thanks

A couple of posts that might help you out: http://processwire.com/talk/topic/3384-search-with-merged-pagearrays-pagination-not-working/?p=33360 http://processwire.com/talk/topic/4257-ordering-by-date-reversed-then-time-normal-order/?p=42365

$modules contains all the loaded modules, so you can foreach through that and echo the $module->name. This returns them in alphabetical order though, so I am not sure how to determine the order they are loaded. Not sure exactly what your requirements are, but if you want to know if a specific module has been loaded at a certain point in the code, this recent post might be helpful: http://processwire.com/talk/topic/5477-check-if-a-module-is-loaded/

Not sure, but it looks to me like you're logging in with a user without any editing privileges. Is that possible?

If you are worried about possible overwriting with users uploading at exactly the same time, perhaps you should consider uploading each user's files to a unique subfolder within the tmp_uploads folder. If the users are logged in users, rather than guests, you could name the subfolders based on the user's ID. If not, generate a unique name - lots of ways to do this in PHP. Anyway, just some ideas for you.

Well I see that you are wanting to rename it based on the POST value for qquuid. My module is not designed to rename based on user supplied values at upload time, but rather standard formats set up in the config based on the values of PW fields. You could use my module to rename the file to the value of a qquid field. The only catch is that the field would have to be saved before the file was uploaded. You have got me thinking that maybe my module would benefit from the ability to rename a file at any time if the value of a field used in the rename rule is changed.

With Lazy Cron you will not be able to guarantee exactly when a task will be run - a page on the site will need to be loaded, just as you noted. You could skip lazy cron altogether and use cron directly on your server, or you could use the technique that Ryan mentions at the bottom of: http://modules.processwire.com/modules/lazy-cron/ (How to make it not-lazy) If you are running your site on a shared host, you will probably find a tool in your control panel for setting up and managing cron jobs. If you don't have a control panel, you can simply google it and you'll get lots of tutorials: https://www.google.com/search?q=limux+manage+cron+job

Just wanted to point out to others that if you are using this (and the Map Markup module) along with zurb foundation (I am still testing, not convinced it's worth the bloat) and you come across an issue with the zoom controls looking not right, it is due to: img { max-width: 100%; } I just added this to my site's css to override this and it seems fine again: .gm-style img { max-width: none; } Hope that helps someone else out.

Ok, gotcha. I did this on a site a while back. I'll dig up the code and get back to you in a minute. Actually I did this on the very first PW site I built, so there might be a better way, but this still works. Create a new datetime field called last_page_load and add it to the user template (remember to "Show System Templates" so you have access to it). Put this code somewhere that is included on every page of the site: if ($user->isLoggedin()) { $user->last_page_load = date('Y-m-d H:i:s'); $user->of(false); $user->save(); } Then you can do this: foreach($articles as $article){ if($user->isLoggedin() && $article->modified > $user->last_page_load){ // echo article here } } Let me know how you go with that. I don't think I have missed any components in making this work, and maybe there is a better approach, but one advantage of this over cookies is that it won't matter whether the user clears their cookies or not, or if they are visiting from different devices. EDIT: Thinking through this - in my case I had already limited $articles with a find. You may want to do the same as foreach'ing through 100's/1000's of articles won't be a good idea, so you could use something like this: $new_articles = $pages->find("template=articles,modified>{$user->last_page_load}");

Thanks Willy, Try it, I did not I do think it might be nice if these options were not shown in the first place though.

You should just need this: if($user->isLoggedin()){ //show new articles here }

Not sure if I am missing something obvious, but I haven't used the Administer Users permission very much and just realized that if you give someone that permission, they then have the ability to add the superuser role to themselves, or to any new user they create. I would really like to limit assigning of superuser to just superusers. The current way this works seems dangerous to me. Am I missing something very obvious about how to disable this?

Make sure you read the instructions for the module: "getThumb returns url to the thumbnail you have asked for" So all you would need would be: $child->overviewimgbig->eq(0)->getThumb('thumbnail') There is also a great video on the usage of the module here: http://processwire.com/videos/using-the-image-thumbnail-plugin/

Things in PW generally are simple Also, in case you haven't seen it yet, you need to read through the cheatsheet: http://cheatsheet.processwire.com/

Hi Xpn and welcome to Processwire. Accessing the url for the image is as easy as: $child->overviewimg->url The only caveat to that is how your overviewimg field is set up. If the Max Files Allowed setting (Details tab) is set to anything but 1, you will need to use one of the following; $child->overviewimg->first()->url $child->overviewimg->last()->url $child->overviewimg->eq(x)->url //where x is the number of the image in the array of images, starting with 0 as the first. Also, have a read of: http://processwire.com/api/fieldtypes/images/

Thanks for that info. I have a late 2011 model so hopefully ok, but I did see some people in that thread with 2012 models also reporting issues. Not exactly encouraging. Anyone else have any Mavericks experience to share?

Interesting to hear given that I am probably just about to upgrade from Lion to Mavericks. I avoided Mountain Lion, but now there is starting to be too many things that won't work on Lion that I am being forced into it. I can't say I am thrilled about the dumbing down on my desktop that seems imminent, but maybe I am making too much out of what I have read on the subject. Do you know if this was a common error for these machines when upgrading to Mavericks, or just an unlucky situation?

This is one of those cases where an SQL query would be easier. WHERE DAYOFWEEK(date) = '6' But it probably isn't worth it to do an SQL query for such a simple situation, so you might be best just removing the non-Saturday dates from the results. $results = $pages->find("date>=2014-01-01, date<=2014-12-31"); foreach ($results as $result) { if (date('l', $result->date) != 'Saturday'){ $results->remove($result); } }

Why not just have them enter the period and the rate type and the rate in the repeater. If you used page fields to store the period and rate types, they could add new ones as needed using the "Allow new pages to be created from field?" so they wouldn't have to retype them each time. Do you think that would work at all?