• Content count

  • Joined

  • Last visited

Community Reputation

42 Excellent

About prestoav

  • Rank
    Full Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Ely, Cambs UK
  • Interests
    Consumer tech, guitars, rock 'n' roll, classic cars

Recent Profile Visitors

897 profile views
  1. Thanks abdus!
  2. Hi Abdus, Actually I assumed that so, when testing, I removed the image from the page completely and added an all new one. Same result, the width attribute still keeps being added.
  3. Hi all, PW: 3.0.42 I'm trying to have responsive images in the body field. First I need to stop the image tag generated by CKEditor adding the width attribute to the image tag on insertion. I found the 'Skip width attributes on image tags?' in the settings of ProcessPageEditImage and that suggests it does exactly what I'm after. Sadly, even when this checkbox is checked and a new image is inserted the width attribute is still added. Am I missing something? TIA.
  4. Thanks Abdus, that did the trick perfectly!
  5. Hi all, A very odd issue this one! I'm working on a site with 5 languages - English (default), French, German, Spanish and Polish. I have a set of pages set up as a country list (templae='country') which contain various country info like two-letter country code etc and where the page title is the Country name. This is so that I can use the country list in various parts of the site. When the site is showing in English, Spanish and Polish I can display the country list without an issue. However, when the page is displaying in French or German the country pages seem not to exist. So, this code... $countries = $pages->find("template=country"); foreach ($countries as $country) { if ($country) { echo $country->title . "<br />"; } } ...displays the country list just fine in English, Spanish and Polish but displays nothing in French and German. Just for extra info, the Title field is set up as PageTitleLanguage and all languages are setup the same. Any ideas? TIA.
  6. Now solved!!! The issue turned out to be one page field within a repeater. I'd set 'Template of selectable page(s)' to 'blog-post' and then set 'sort=-blog_date' in the 'Custom Selector to find selectable pages' field thinking the two selectors would combine. Turns out they don't, at least not in this way. All pages, repeaters and other admin sub pages were selectable within this field. The site has hundreds of pages, many with a large number of repeaters in so every time the page admin was loaded / saved it read all of them. Combining the required filters with only the statement 'page-template=blog_post,sort-=blog_date' for this page field did the trick and the admin for this template (and saving pages with this template) now works really quickly. Phew!
  7. Ah, sorry missed that!!! No hooks and no modules (other than core and ProFields repeater matrix) related to that template. Repeater Matrix is working on other templates OK and is only used once in the offending template. I've not come across Tracey debugger before. Do you mean this: ? Thanks again.
  8. Thanks berhard for the FieldSetTab option. Another very cool PW feature I didn't know about. That will come in useful! Sadly though in this case it's not made any difference to the load and save page of the pages with that template, despite moving some of the 'big hitters' from the page into tabs :-(
  9. Hi Macrura, Looks like all the repeaters are set to AJAZ load anyway (default behaviour). Are there any tutorials on creating a new tab in an admin page that you know of (not done that before)?
  10. Hi Macrura, Thanks for replying. really appreciated. I'll try the AJAX loading the repeaters. From memory, they are set this way already but I'll check. You're right in that both hosts are running the DB in localhost so no DNS in the way. Good idea though and I'll keep that in mind for the future. Will keep looking!
  11. Now solved, see reply at the bottom. Hi all. PW version: 3.0.42 Despite the usual speediness of PW, a site I'm working on at the moment is suffering an extremely slow load and save time in admin. We have the same site running on localhost (a brand new MacBook Pro with 3.1GHz processor / 16GB RAM) and a Media Temple VPS host both installations suffer in the same way. All pages open and save in admin very quickly with the exception of pages using one template which just happens to be the most used one (for products the site owner manufacturers). Opening the page to edit, or saving the page, can take more than a minute! The whole front-end of the site slows while this is happening. I should add that no caching is turned on at the moment, save the standard PW system. We are, however using the multi-language support with 6 languages installed. The template consists of the following number/type of fields: 1x PageTitleLanguage 3x TextLanguage 4x Page 4x Repeaters (2-3 fields, typically text / image / textarea / page, in each - up to 10 entries per repeater) 1x RepeaterMatrix (3 fields in each, up to 3 entries per repeater) 2x TextArea 1x TextAreaLanguage 3x Image 8x Text Has anyone had an experience like this before? Is this expected behaviour with this number of fields in a page (it's the first time I've used this many on one template)? As always, any help would be gratefully received!
  12. This is the second site we've built for Visualization. The first launched some 5 years ago and was based on a different CMS (before we started working with PW). The site is fully responsive and features a 'quick quote system' using the FormBuilder module to manage quote requests and email both customer and site owners with the calculated quote. The prices for each part of the quote calculation are editable by the client in the CMS at any time. Every page features Meta Title and Description override option fields with tag content falling back to values based on the page's content if these are not filled in. Other than PW core v 3.0.42 additional modules are FormBuilder, ProCache and markupBlog. Any feedback welcome!
  13. Posting in the hope this helps someone out of a hole! Having built 20+ sites on PW in the last couple of years (and loving it...) I came across a really odd situation recently. The client's IT company and I 've been battling for a couple of weeks and today, finally, we have an answer! The site is built and temporarily housed on a shared hosting account we have for development. All tested well here so Access was granted to the client to start adding content. The next day I get a call from the client to say the admin side of the site is logging them out every 30-40 seconds and they have to log back in again each time to continue. I tested again from our office with their login but all worked as expected. Other browsers, PCs etc. were all tried by the client but the problem persisted. So, I get in my car and drive to the client's site. Sure enough, I see the issue on one of their iMacs. So I open up my MBP, connect to their network, log in as them and the problem is there. So, next, I came off of their network and onto my tethered iPhone on 4G. Bingo! The problem goes away. So it's their network that's the issue. Their IT company were called and, with us helping them wherever possible, they worked on it for 2 weeks to find the problem. I captured the port numbers in use by PW admin (60992, 60993, 61000, 61001, 61002, 61003 by the way) and the IT company opened those ports on the router but still, the problem remained :-( And then the breakthrough... They have two VDSL lines into the building that feed their router through a load balancer. It seems that their setup meant that responses to outbound traffic did not necessarily come back in via the same line. Processwire admin does not like this! So, the IT company put in a rule to direct all traffic from the IP of the shared hosting through the same route in and out of the building and BOOM! it all works as expected. Phew! All's well that end's well but it certainly put us through the wringer tracking it down. Actually, I think it's pretty cool that PW does this. A good extra security measure. Several other CMSs (no names...) worked just fine with this scenario but not PW. Anyway, happy client, happy me. Hopefully, this story helps someone else here too.
  14. Just confirmed this behavior is the same with a fresh install of PW (Minimal Profile) and ProcessBlog. Is there likely to ever be a fix to make ProcessBlog compatible with multi-lingual or is there an architectural problem? Thanks.
  15. Hi all, Is anyone using the super ProcessBlog module with PWs multi-language support? I have five languages setup and all pages are running correctly in all languages / falling back to default (English) when no other language is available etc. That is apart from the main blog page and it's children (the posts). I'm using the standard gateway method for urls (e.g. and standard language switch code as described here. I should also note I am only running manual input of translated content, no auto translation. All pages are present in my main menu (no matter what language is selected) apart from 'Blog' which disappears when any language that isn't the default (English) is selected. Also, if you visit the blog page in English the language selector (which shows all languages on all other pages) only shows 'English' as being available. I'm guessing this has something to do with the way the blog is rewriting URLs (in my case to, i.e. the posts are not children of a category) but I am only guessing! Versions in use are: PW 3.0.42 ProcessBlog 2.4.0 I've looked at the title field in use for the blog page which is set to 'PageTitleLanguage' as are all other pages. Anyone have any ideas as this is driving my nuts today! Thanks in advance, Geoff.