Joe

Thank you diogo! Yes with this I arrived at the perfect solution! I actually placed the site settings template under the setup tab now, where it is accessible to the guest role user together with the function to restore pages from the recycle bin (Trashman module), which also resides there. That way things appear more logical to the user, as the site settings options are not any longer presented as a "page". Great! SiNNut: Thank you too! Since diogo´s solution is working so well I am not looking into this more closely now. But I think that would work too. However I´m not aware of how to add a custom tab to a template, if you could point me in the right direction that might be usefull for future use.

An answer to my own post: I have found one possible solution for now: I manually set the value in the database for sort for the site settings page in the "pages" table to a very high value. That seems to do the trick of keeping the page at the end of the list as new pages are created. But of course this does not protect the page from being moved by drag´n drop.

Hi everyone! For a PW-based website I´m doing for someone I have created a "site settings page", a page where the website admin (guest role) can change the site title, meta description tag and page footer for all pages. The page is not made visible on the website (no template file). Now to keep things simple and logical for the client I would like to keep this "page" always in the last position in the "Pages"-view. How can I assure it stays there as new pages are created and can I block the "page" from being moved about by drag and drop? I feel an even better option would be to keep this site settings page from being visible at all in the "Pages"-view for the guest role but make it accessible via a link. Is that possible? Or is there maybe another way I have not thought about to allow users to set basic features common to all pages? Thanks for your help! Joe

Thanks, titanium! That did it. Thank you too, Radek.

Hello everyone! I´m having a little problem here: I have a PW installation with the Admin (superuser) and another user with a guest role. The superuser´s language is set to the default (English), the other user´s to another language. The login screen still appears in English though. How can I change things so the login screen appears in the second language? I have another installation of PW, with almost the same setup and strangely there the login screen appears in the language set for the non-admin user. But I just can´t remember how I did it... I´m sure it´s a simple thing, thanks for your help. Joe

Thank you interrobang! I put this into the .htaccess file and bang: The images load lightening fast! I still don´t quite understand the mechanism, not sure if the second part below "# Prevent mobile transcoding" is needed here and how it affects things. >> Looking again, I suppose I do understand it. - The php-output is kept from being re-written and thus having the proxy address inserted into the image URLs. Also, the images seem to still get delivered via a proxy, as their URLs still have "1.2.3.9/bmi/" in them. >> Turns out this only happened at first, or at least so it appears. Now the "1.2.3.9/bmi/" is gone! So thank you again everybody for your advice and in particular to interrobang for the solution that worked!

horst, thanx, you mean I talk too much ? well: <FilesMatch "\.(jpg|jpeg|png|gif)$"> Header append Cache-Control "no-transform" Header append Cache-Control "private" </FilesMatch> ...seems there is no effect. I'm also no apache expert....

Thank you, Horst Actually I am struggling to accomplish this right now. I put the following lines into the .htaccess file of the directory ProcessWire resides in: <FilesMatch "\.(jpg|jpeg|png|gif)$"> Header set Cache-Control "no-transform, must-revalidate, private" </FilesMatch> with no effect whatsoever. Header set Cache-Control "no-cache" instead did not work either.

Hello, apeisa: It is not really just a matter of me living with it - The images really load incredibly slowly, even small ones. When I visit other sites though, images load normally. And I had the same feedback from a prospective client trying out my test version for a PW-site, so this would affect visitors to the site. As far as changing mobile broadband: That would only solve the problem for me, not for other users visiting the site via mobile broadband providers that set this up in a similar fashion, and I gather this is done quite a bit by mobile broadband service providers.

So I finally found out how the "1.2.3.13/bmi/" gets into the image URLs! It´s not a virus or the like, rather the Mobile Broadband provider injects this into the URL and you get the image via a proxy (a more compressed version of it, it is being reported). So I suppose for the CMS, when the new content just has been added the proxy doesn´t have it in the cache of course and therefore fetches it and compresses it, that´s why it takes so long. Whereas if you visit a more high volume site the images already are in the cache and so it´s not noticeable. I checked: a large percentage of the image-URLs of sites I visit have the "1.2.3.13/bmi/" in them, I just hadn´t noticed because they seemed to load normally. (I have only been using my current Mobile Broadband provider for a few weeks now). This seems to be fairly common with mobile broadband. They do it in order to save bandwidth (serving more compressed images rather than the original). I saw some hint that it is accomplished via an inserted javascript. Well, whichever way it´s done, I certainly don´t like the fact that my pages are changed on the way to the browser! The solution is probably to insert a a header that prevents caching - I still have to work out whether to do this by setting it on the server or inside ProcessWire. But anyway, it is not actually really a ProcessWire problem as such. Thank you teppo and kongondo for your advice. When I have resolved the issue I will post it here.

So here I found a possible hint at what might be going on, even though I can´t make sense of it yet: Like I described at the beginning, the problem is that "1.2.3.13/bmi/1.2.3.11/bmi/" gets inserted into the image URLs of the images on the pages, only the image URLs though, not the page URL. They still load, but much slower. It also happened on another server, got these instead: "1.2.3.10/bmi/1.2.3.12/bmi/" Now I found that all these IPs point to: IP Information for 1.2.3.12 IP Location: Australia Australia South Brisbane Apnic Debogon Project ASN: Australia AS15169 GOOGLE - Google Inc. (registered Mar 30, 2000) IP Address: 1.2.3.12 [Whois] [Reverse-Ip] [Ping] [DNS Lookup] [Traceroute] Whois Server whois.apnic.net (Info from http://whois.domaintools.com/1.2.3.12 ) On some forum I found the following: A 'bogon' is an unallocated IP address. There are still ranges of IP addresses which are reserved but not yet in use. These are filtered or ignored by many ISPs as they will only show up if something is misconfigured or something malicious is going on. But IP addresses are running out. The 'debogonizing' (ugh) project is designed to get these addresses assigned to companies and out of the ISP filters. 1.2.3.11 would have been a bogon, but isn't now (although your ISP might still think it is). A google search implies it's something to do with mobile phone proxy servers. If you remove '1.2.3.11/bmi/' from the URL, you should see the picture as it was originally intended. But why and how would that get into the image URL? I also read some vague hints about trojan infections or the like. However, where would that be? On my computer locally? On the servers?? Anyway, I´m going offline to run a comprehensive antivirus security check locally to see...

PHP Version 5.3.27 mysql Client API version 5.1.70 It is TinyMCE, because for tracking down the problem I use an "out of the box" installation, as downloaded without any changes of adjustments whatsoever. But the same thing happened with CKEditor, which I was using before. It happened with all images. The .jpg I used for this last test is about 30KB. Now I just tested with a .gif and a .png as well, both under 5KB, same thing. And like I said, this happened consistently with each and every image, on several test installs on two different servers. The images were always loading very slowly - I only found out that this is related to the image URL today.

Hello kongondo, yes, just checked again, there is nothing written in errors.txt (after repeating the test). No, it happens with each and every image. And also it happened the same way on another apache server I was testing on first.

Hello kongondo, I manually created the errors.txt in /site/assets/logs/ . I then created a new page and repeated the image upload and insertion. Same problem - image URL is given on the page as: 1.2.3.13/bmi/1.2.3.11/bmi/this_domain.com/folder_for_this_installation/site/assets/files/1006/x.jpg instead of: this_domain.com/folder_for_this_installation/site/assets/files/1006/.x.jpg (leaving "http://" in front out here because then the URL becomes unreadable here in the post) I must point out that both URLs work, but the one I get on the page with "1.2.3.13/bmi/1.2.3.11/bmi" in it takes much longer to load. But since both work there is not really an error I suppose and therefore probably nothing written to errors.txt I assume.

Hello kongondo, yes, I first tested locally on a WAMP-Server, did not notice the problem there. Well, the instance of ProcessWire I used for testing this now I installed by uploading the ProcessWire-master.zip to the server and unzipping it there. Ok, I will put an errors.txt file there. Greetings

Hi, teppo, I just checked: /site/assets/logs/errors.txt does not exist, /site/assets/logs/ is empty. I´m on shared hosting and do not believe the server logs are accessible to me.

Hello teppo, thank you for your quick reply. I just saw I made a mistake when posting: I´m calling the image "x.jpg" here to make things clearer. It is the only image, "cabin1.x.jpg" doesn´t exist. (corrected in the post now) No, there are no other images, except "x.300x0.jpg" and "x.0x100.jpg" - I resized the image when putting it on the page. It is a Linux-Apache server, if it will be of any help I can post the output of phpinfo. And actually it is the second Apache server this is happening on, I tried it on another server first. It is the latest stable version 2.3.0 just downloaded about a week ago directly from http://processwire.com/ , and as I said, for testing purposes I installed a fresh copy without making any changes to it.

Hello everyone! I have been testing ProcessWire to use as my new CMS for clients. I quite like it. Now I´ve run into a curious problem I couldn´t find any explanation for searching this forum, so I decided to join and see if anyone knows. So here my question: I upload an image on a page and put it in the page body via the editor. When I view the page the image takes an exceptionally long time for loading. I finally found the reason for this: The URL for the image on the page is: (I had to remove "http://" in front of all these URLs here so they stay readable and are not posted as an actual link, so you have to imagine the "http://" in front of each of these URLs) 1.2.3.13/bmi/1.2.3.11/bmi/this_domain.com/folder_for_this_installation/site/assets/files/1006/x.jpg whereby "this_domain.com" represents the domain the installation is running under and "folder_for_this_installation" is the directory it is installed in. Everything else seems to be running fine and all the pages are visible under this_domain.com/folder_for_this_installation/ (this is not the actual URL, just for illustration purposes). When I call up the URL for the image it does load, both with: 1.2.3.13/bmi/1.2.3.11/bmi/this_domain.com/folder_for_this_installation/site/assets/files/1006/x.jpg and with: this_domain.com/folder_for_this_installation/site/assets/files/1006/.x.jpg the difference however being that in the second instance it loads much faster, the way it should be. To make sure the problem was not caused by any modifications of mine I used a brand new "out of the box" installation. Does anyone know what may be causing this? Thank you! Joe