MarionRaven

neat text description but the the video ...

I'm now able to reproduce my "automatic" sign out. Maybe others are affected by the same problem. I'm using firebug and firephp once in a while. Without firebug my firefox transmits the user agent string : ... Firefox/16.0 With activated firebug the uas is: ... Firefox/16.0 FirePHP/0.71 This change in uas kicks me out of my processwire backend session.

Hi danielholanda, as the other forum members I suggest you to start with the dummy site from process-wire. In this case you already have images which are showing up on the web page. Two things to keep in mind: 1) The generation of your html output is mainly done by head.inc and foot.inc in the folder site. These files are PHP scripts. And you edit them outside of processwire. 2) The thumbnail module only adds some sugar to the field image and delivers that as a new field type. A Gallery does not demand this module. And it delivers nothing new to the front end. Nevertheless it is really useful, I.e. a Javascript Gallery may benefit from scaled and cropped images.

Let's again keep in mind, that the value of a forum comes from its members. So this forum is great. But concerning the software I can contribute a nice bug feature: I tried to insert an image and always got the error: "Your post is to short" (Flickr comes to rescue)

I think the answers sum up to: If you need to shift content around, then it should be organized as pages, which can even have templates attached. My understanding therefore is, that I really tried it the wrong way, since repeaters are not exactly the same as page references.

I agree with both your claims. My case is just between. As an example: I'm using a repeater field for an accordion (perhaps 20 items). How can I shift the accordion (and only the accordion) to another page?

I wonder, how you can enable a client to copy or move content from one page to another. I'm aware, that template constraints my be a hindrance, since what is a valid element on the source page may not be valid on the target page. Is this simply a task, which is not in concord with the spirit of PW?

The necessity to include "virtual" pages in the page tree comes often from the customer. So you have no choice. Then <a href="<?=$page->get('redirect_url|url')?>"><?=$page->title?></a> instead of a redirect is preferable. But there is an other reason you might wish this "short cuts". If you expect external links to change frequently and you have them scattered over your site you would appreciate the benefit of changing them only at one well known place. So if you do some work on it, I suggest not to limit yourself to the menu.

I had this picture in mind. I thought, this will bite you (me), if you ever disable your cache. Luckily this is not regular done by anyone. With your knowledge, I wouldn't have suggested the small reduction which is achievable.

I'm nearly sure now, that your client has a 16 Mega-Pixel Digi-Cam. Search for agile-uploader if you want to mimic the e-mail-client-behaviour.

Your client might transmit a false mime-type. Can this yield trouble? And he may lie to you - unconscious. Maybe he tries to upload a link rather than the actual image. Just an example. Another idea. The real images are really big - to big. And his mail client is nice enough to scale them down if he he send them to you.

@ryan; I just made a post concerning a similar topic Working on it I got aware of the heterogeneous collection of Javascripts. So I instantly decided that the task is not something I can do. I hoped, you are able to collect them to at least to chunks. But I agree it is not a critical issue at all. Thank you for the long explanation.

I like to share a few code snippets to accelerate the delivery of fancybox content. Newer versions of fancybox might use css-sprites like ryan does for the images in the searchbox. For the sake of simplicity I use url-data to put all images in the css-file. (/wire/modules/Jquery/JqueryFancybox/JqueryFancybox.css) Despite the greater total size (base64 encoding) this is already a gain. With gzip compression the size will not even increase significant. Then a .htaccess should be used: <Files "*.css.gz"> ForceType text/css </Files> <Files "*.js.gz"> ForceType text/javascript </Files> <Files "*.gz"> AddEncoding gzip .gz </Files> Since IE less than IE8 don't support url-data I have a conditional comment in my template for them: <!--[if lt IE 8]> <style> #nav { height:38px; } </style> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/urldata.css" /> <![endif]--> Of course I also changed the reference to the css-file: <link type="text/css" href="<?php echo $config->urls->modules?>Jquery/JqueryFancybox/JqueryFancybox.css.gz" rel="stylesheet" /> A change in the init-function of ModuleJs.php let's even the PW backend benefit of the compression. But that is optional. public function init() { $class = $this->className(); $info = $this->getModuleInfo(); $version = (int) $info['version']; if (is_file($this->config->paths->$class . "$class.css")) $this->config->styles->add($this->config->urls->$class . "$class.css" . ((is_file($this->config->paths->$class . "$class.css.gz"))? ".gz" : "") . "?v=$version"); if (is_file($this->config->paths->$class . "$class.js")) $this->config->scripts->add($this->config->urls->$class . "$class.js" . ((is_file($this->config->paths->$class . "$class.js.gz"))? ".gz" : "") . "?v=$version"); } urldata.css JqueryFancybox.css.gz

Proposal: Combining css-files and js-files to one file each would be a nice option. The number of files reduces by means of the cache. So it is a minor problem. Anyway I'm asking for it, cause it may not be a big task for you. I got far more blocking (and waiting) time than transfer time, if I request a backend page for the first time.