horst

If you like you can submit the site to the sites directory too.

"DASDA Theater Aachen" ?!? I need to read the Topictitle twice and had to pinch myself to be sure not to dream. Very nice Site! -------- >>> http://de.wikipedia.org/wiki/Klenkes

@Gabe: Welcome to the forums. I saw that you haven't got an answer until today. This is a shame Unfortunately I don't know the Page Edit Field Permission module. But I want to welcome you. Hopefully someone with knowledge about that module read it soon and can answer this.

Welcome to the forums Frank, this is a nice and sometimes funny place here. Do you also have a wife, (besides the two kids and the dog)? Your english is pretty good.

Not exactly what you are looking for, but maybe a (modal popup) alternative? http://modules.processwire.com/modules/fredi/

hmm, 2.0 can be to small. With the tests 2.2 was the smallest setting what never has failed. 2.1 has failed sometimes. good question. I don't know how vservers are configured and or how the memory management work in those web machines. As far as I have understood it until now is that the 128M, if it is set to this, is guaranted for every starting script. Otherwise it doesn't make sense to me. If on a server with 16G mem are 50 sites / accounts, each can have a guaranted minimum of 320MB. If this isn't enough, maybe it can use more "if available". If there is heavy server load and there is more needed, maybe some technic like swapfiles came into play? In fact I don't know. But guaranted doesn't mean it lets you script die / crash. Maybe slow down, delayed, but not crash in the first instance. Or? You need to go to the dev-branch and select "issues" from the tabs on the right (that one with the exclamation mark). Their you can post a new one. You may also include a link to a forums post / thread if this can be helpful for Ryan.

Hi Bernhard, ok, that is important information. Best bet is that this case is very near to the limit. One cannot exactly know how many memory an image manipulation will need. But if we calculate to small, the whole thing is obsolete, because it can crash the script as it was before. The cullprit is that there is only one setting for factor that should suite for all possible cases (downsizing, upsizing, croping, etc) The line in code where it is set is here: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ImageSizer.php#L1614, also I see it's default is 2.5, not 2.3. Maybe you can set it to 2.3 (or 2.2) and try again? Using factor 2.3 insteed of 2.5 results in 10MB more memory in this case. Only 109 estimated and not 119 of 128.

https://processwire.com/talk/topic/4550-debugging-tips/

@netcarver: looks fine! Thanks!

only 30 images of max 1 MB or max 1200px isn't much. I have 300 images at 800px per page on one site that works fast and fine. The only thing that rings alert here is the fcgi mode. I don't have enough experience with server adminstration, (in fact I don't have any ) but I have seen that servers configured as fcgi can have disadvantages that results in slow execution. (has to do something with that system threads need to wait for their rights to start, they are somehow queued and delayed) So, I believe an apache with fcgi could be tweaked to also run fast, but I don't know how. In the opposite I never have seen those problems when php is running as apache_module.

I have uploaded a file of 42MB to my site via the PW admin to a file field. It tooks 8 minutes for successfull upload. My settings from php.ini on this site are: file_uploads On max_file_uploads 20 // this I have found too, sounds like max number for simultaneous uploads upload_max_filesize 200M upload_tmp_dir post_max_size 240M max_input_time 60 // has nothing to do with time used for fileupload!! memory_limit 256M enable_post_data_reading On // this I have found too, don't know what it mean max_input_time is set to 60 seconds, so this is not relevant for fileuploads I think. ------ PS: @KentBrockman: thanks for the continued support.

@netcarver: good! Can you also please do a check if it is possible to increase / decrease the max_execution_time with set_time_limit() or ini_set('max_execution_time') and reflect that in the output? Normally it should work but some (cheap shared) servers may have it disabled.

I think this isn't relevant for uploads, but also remember that there is something called like max-input-time in the php.ini? EDIT: no, this (max_input_time) is also not relevant: max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60 ; Maximum amount of time each script may spend parsing request data memory_limit = 256M ; Maximum amount of memory a script may consume (128MB) file_uploads = On post_max_size = 240M upload_max_filesize = 200M upload_tmp_dir =

I wouldn't use the site/assets/files/id/ folder, you should create / use a temp folder besides site and wire: |-site |-temp |-wire and then I would try to add them via API: $targetpage->filefield->add('/fullpath/to/temp/basename.ext'); // or is it called ->addfile()? PS: if you would use a site/assets/files/id/ folder, it would create a basename-1.ext file I believe. (but not sure)

Nico, this is not a PW related thing. It is related to your server I think: Server responded with a status of 503 (Service Unavailable) What does it say in the phpinfo for: post_max_size upload_max_filesize You may try to bump that up in the htaccess: <IfModule mod_php5.c> php_value post_max_size 240M php_value upload_max_filesize 200M </IfModule> Maybe also you can check what is set as the temp upload dir in phpinfo, and if that exists and is writeable by PHP. And, does it work with small files, < 1MB ?

cannot really follow. Do you want to send both versions _everytime_ for every request, (also to mobiles with possible low bandwith) and want to hide maybe 50-70 percentage of the transmitted content? Why do you not serve two different versions with different (base) URL or (sub)domain? And simply let the user decide which one he uses, like here in the IP.board. (with mobile you have a link on every page: [use full version] or [use mobile version]) Or use a UA-sniffer of your trust and send one version. https://processwire.com/talk/topic/6354-server-side-mobile-detection-with-caching/#entry62205

This is by design. and everyone can replicate it by simply setting the amount of memory way to small for such large images on his server. So, the error message in the first example isn't that lucky because you see the error from the derivative image (admin thumbnail 0x100) what could not be created from the way to large original image that should be scaled down to a max-size. If you have a look into the original image (open it in a simple plain text editor!) you will see that it contains something like: whereas the 0x100 thumb contains: @Ryan: Maybe we need to display the error from original image too so that it is more clear what was going on? So, but in your second example you can already read it by yourself: not enough memory to load/resize Imagerendering with the GD-lib needs minimum ram memory 2 - 2.5 times of the uncompressed image! If you load to large images into memory GD/PHP crashes with a not catchable fatal error. PW since version 2.5 does look ahead to available memory at runtime before loading images into memory. This way it saves you from crashes! I like how it works. Great job @Ryan! Simple calculation example with your image: width x height x colorchannels = memory bytes 4.608 x 3.456 x 3 = 47.775.744 - just to load one of those images into memory (togehther with rest of PW) you need 60MB ram! - and if you want to manipulate / resize it you need 47.775.774 x 2.3 = 109.884.211. Do you have a minimum of 128MB memory available for PHP? No, you need to bump it up. I recommend setting it higher in available server configuration panels, php.ini file or in the .htaccess: <IfModule mod_php5.c> php_value memory_limit 256M </IfModule> But you should not transmit images 4 times larger than the largest needed display size. (Denk an unsere Umwelt und an unsere Kinder die diese auch noch brauchen!) g-translate: (Remember our environment and our children also need this yet)

Hi MuchDev, by default we prefer to bump up older posts then to create new ones. This way things that are close together are also stored close together and that makes it easier for followers (for us all). But no problem here. And, - if you want that people has a good chance to help you with your problem, you should provide as many useful information as possible. (focus is on useful == quality over quantity). Ah, found a post that is titled: Lots of images to resize, timeout in frontend I can ask you mainly the same things here: "Maximum execution time exeeded" doesn't say much. I think it has to do more with your server than with the Imagesizer because I know many sites with many thousand images where it doesn't run into this. Also mormally it doesn't matter if you have a million images on a site but how many images are belonging to a single page. I have running sites with single pages that have 300+ images that needs to be rendered into 4 derivatives each at first page view (1200 derivatives in less then 30 secondes). What are the most and/or the average number of images per page in your site? How many derivatives do you need? How big / large are your original images in MB and in pixels (maybe you have some with to many MegaBytes laying around?). You can set a maximum-width and -height in the image fields to downsize them directly on upload to for example 800px or whatever you prefer. Does the server have enough memory to work with? How many? Recommended is 128M or better 256M for large image sites. Are you on a shared host? Is PHP running as apache module or as cgi? If you read that other thread you will find a solution to render your derivatives directly on upload.

regarding the first part I think @Mike_Anthonys solution is the best one. regarding that with the alias maybe you can use the page-path-history module? and if I get it right, that with the concatenation in the admin, (you mean customizing the PageTree?) you may have a look here.

Seeing the error would be helpfull! what is app()?

It sounds your PC still is something blocking: "Failed to load resource" But I don't know enough about that, so I simply reply to your post and bump up the Thread a bit, hoping someone with more knowledge or experience read it and can help.

https://processwire.com/talk/topic/7283-ckeditor-how-to-adapt-configjs-and-keep-it-upgradeable/

What PW version do you run? Is your site hosted online or local? Have you installed the site newly or have you updated an existing site to a newer PW version? ------------ Just a thought: go to admin -> modules -> new and press "check for new modules" one or two times and then logout and login again. Go to edit a page, is it visible now?

what is set for TO (recipient) at runtime? echo "<pre>\n emailTo: "; var_dump($emailTo); die("\n\nDebugExit in file " . basename(__FILE__) . " at line: " . __LINE__);

use this for testing: $ret = mail($emailTo, "Contact Form", $msg); // no additional header for FROM, your shared host will create a generic one