adrian

Yeah, I don't any issues with that. The temporary approach is probably actually best anyway. It is usually best to keep that setting at its default in the php.ini file unless there is a reason to have it higher for scripts that are running regularly.

No need to apologize. That module wasn't officially released because it hasn't really been tested in different scenarios, but it has been working just fine for me on a few sites, so I am curious why it's not working for you. Perhaps you will do better with Martijn's Image Interceptor. I know it might seem like overkill, but I have also used it and it works great, so long as you are happy using the image ALT field, rather than the images field description field, if that makes sense. Good luck.

I certainly don't see anything wrong with your approach, but if you set up a settings page in the admin and added a "signature_image" field to it, it would be easier for you / your clients to change this image in the future. Then you could simply echo the image in the same place using: $pages->get("/settings/")->signature_image->url();

Oh right now I understand - sorry I didn't read through the posts above properly to see what Ryan's module does and that you were using it. That might well be the issue. I'd be curious if you could disable it for a moment to see if the image caption module works.

If you are using my module, remember that it takes the description field from the images field, rather than the one that you get when inserting the image into the RTE, Do you have those descriptions filled out? I just pushed an update to the module. I have been using it on a few sites, but apparently forgot to push some recent fixes. Can you see if these changes make any difference?

This is a php setting, so if you have access to your php.ini file you can adjust the max_execution_time there. If not, you could edit the profile export module's .module file and add this at the top: ini_set('max_execution_time', 300); That will give you 300 seconds, instead of the default 30. Of course any updates to the module will override this, but hopefully it will get you through this current task.

I know you're sure the password is correct, but just in case (and maybe it will help reset something), have you tried this technique: http://processwire.com/talk/topic/490-how-to-reset-your-password-how-to-enable-the-forgot-password-function/ Lots of people have had success with this approach.

There are several other things you can try. Please take a read through the posts that come up with the google search: site:processwire.com "login failed" migration A key thing that keeps coming up is folder permissions: "the permissions on the folder site/assets/ and on the site/config"

Not sure if you have seen it or not, but this module by horst is currently the PW image manipulation option: http://processwire.com/talk/topic/4264-release-page-image-manipulator/ You may actually need to look beyond GD to imagemagick - it is much more powerful. If you also get the imagick pecl extension, you'll have a very powerful PHP-only tool. I bet you could use horst's module as a starting point to create an imagick version with more options, but you'll have a bit of work ahead of you. If you do want to start tackling this, take a look at my Image Rasterizer module: http://processwire.com/talk/topic/4632-image-rasterizer/ which uses imagick. It should give an idea of how you can manipulate an image on upload using PW and imagick in a simple module.

I've been getting this too with Chrome 32 and I think maybe even on 31 - thought I was going crazy

Try this: Redirect 301 /new http://www.newdomain.com That should keep things simple. Nevermind - that won't obviously take care of the pages below /new/ If it still doesn't work, try removing your index.php redirect as a way of testing this first.

Try adding this line before your redirect: RewriteCond %{THE_REQUEST} ^.*/index.php Also, remove the second forward slash: //$1 should be /$1

I just loaded it and it was much quicker than that (see attached). Is it possible you have a sporadic network slowdown at your end? If you really want to speed things up further though, you should perhaps consider the ProCache Module: http://modules.processwire.com/modules/pro-cache/

If I understand what you are looking for, the simplest way I can think of to achieve this would be to turn on the tags field for the images field and then enter "gallery" in the tags for the images that you want displayed in the slideshow. You could order by adjusting the order of the images in the field the normal way, or if you want a different order, you could have a second tag with the order number. Of course whether this is a good solution or not might depend on whether you are setting this up once, or your clients will be doing this regularly. So maybe not a great solution Personally I think it might be easier to have two separate image fields, one for the slideshow images, and one for any other images that need to be inserted in the body RTE.

The two examples you posted won't work because you are using $image in both instances and not $images and then $image. You were also getting the url, rather than just the imageK1 field in your initial line. What Mats posted will work, but if it makes more sense to you, you can adjust what you wrote to: $images = $pages->get("/leistungen/dekoration/")->imageK1; foreach($images as $image) { echo $image->url; } and it should work fine. What you are doing is assigning all the images in the imageK1 field on the /leistungen/dekoration/ page to the array $images. Then you want to iterate through this, making each item $image and echo it out.

No problem here with 2.3.11 logging in with different IP addresses. Have you tried this setting in your config.php $config->sessionFingerprint = false;

Moderna: http://modules.processwire.com/modules/moderna/ Although with all the new additions that Ryan has developed for the new default theme for the dev version of PW, I am now just using the default theme.

landitus, I haven't tested with FormBuilder (I don't have a copy). The "error" is just a php notice. Even though I can't seem to reproduce it in normal use, I think it's just needs another check to make sure $value->$key is set. Regardless, it shouldn't stop the module from working. Is the formatting actually working for you when you output the results of the form somewhere?

Not at the moment, although that is a great idea. I'll look into it and see what I can come up with.

Yeah, sorry for the confusion - I did read the announcement post for jQueryDataTables, but when it came to upgrading ModulesManager, I apparently didn't put two and two together! So I can't read and apparently can't add up either

Thanks kongondo - I didn't read things properly and assumed that the new data tables plugin would override the old one. I uninstalled the old, installed the new and the modules manager is working again!

DataTables is working - see attached. v 1.0.0

Hey Soma this sounds great, but I just installed JQueryDataTables which installed fine, but then I went to upgrade the ModulesManager and got this error: Warning: chmod(): Operation not permitted in xxx/wire/core/Functions.php on line 187 and this message whenever I try to open the modules manager: ModulesManager: ModulesManager requires 'JqueryDataTables' module since version 2.0. Any ideas?

There are two PW modules (not available in the modules directory) that might be of use. They are both mentioned in this thread: http://processwire.com/talk/topic/1344-captions-for-images-in-tinymce/ One is by yours truly and is a PHP solution and another by teppo which used JS.

Hey Joss, I have actually been playing around with your profile - everything looks great, but I did notice that the collapsed (mobile) version of the menu has "MENU" in grey with a weird box below it. I don't think this is expected behaviour. Any ideas?