Search the Community

Is there a way to make JPGs progressive by default via the API? I've added the following to my site/config.php file but user-uploaded images are often displayed as non progressive. $config->imageSizerOptions = array( 'upscaling' => true, // upscale if necessary to reach target size? 'cropping' => true, // crop if necessary to reach target size? 'autoRotation' => true, // automatically correct orientation? 'interlace' => true, // use interlaced JPEGs by default? (recommended) 'sharpening' => 'soft', // sharpening: none | soft | medium | strong 'quality' => 95, // quality: 1-100 where higher is better but bigger 'hidpiQuality' => 60, // Same as above quality setting, but specific to hidpi images 'defaultGamma' => 0.5, // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0) ); Thanks

Existing PW site version 2.7.2 core running on php7.1. Site is perhaps 7 yrs old and never misses a beat. Can't speak highly enough about this solid version, but.... As new php versions are released (v8 in the next year I think?) and each seems to get quicker I'm looking at upgrading to php7.3 or 7.4 and upgrading the site to PW v3.x. I've been away from the forums since v3 was released so don't know much about it. I guess it's stable as it's been around for ages now, but what I'm wondering is: what are the real advantages of upgrading to v3 for a site which is actively used but with only periodic development. And what are the disadvantages if any? Is there any speed impact (good or bad) in either general site speed under 3.x or admin-use speed/ease of use? any issues with either PW version with newer php versions (>7.1) I should know about? is there any good write-ups/vids about new features etc of v3 compared to v2.7? Thank you

Hey Ryan, hey friends, we, Mobile Trooper a digital agency based in Germany, use ProcessWire for an Enterprise-grade Intranet publishing portal which is under heavy development for over 3 years now. Over the years not only the user base grew but also the platform in general. We introduced lots and lots of features thanks to ProcessWire's absurd flexibility. We came along many CMS (or CMFs for that matter) that don't even come close to ProcessWire. Closest we came across was Locomotive (Rails-based) and Pimcore (PHP based). So this is not your typical ProcessWire installation in terms of size. Currently we count: 140 Templates (Some have 1 page, some have >6000 pages) 313 Fields ~ 15k Users (For an intranet portal? That's heavy.) ~ 195 431 Pages (At least that's the current AUTOINCREMENT) I think we came to a point where ProcessWire isn't as scalable anymore as it used to be. Our latest research measured over 20 seconds of load time (the time PHP spent scambling the HTML together). That's unacceptable unfortunately. We've implemented common performance strategies like: We're running on fat machines (DB server has 32 gigs RAM, Prod Web server has 32gigs as well. Both are running on quadcores (xeons) hosted by Azure. We have load balancing in place, but still, a single server needs up to 20 sec to respond to a single request averaging at around about 12 sec. In our research we came across pages that sent over 1000 SQL queries with lots of JOINs. This is obviously needed because of PWs architecture (a field a table) but does this slow mySQL down much? For the start page we need to get somewhere around 60-80 pages, each page needs to be queried for ~12 fields to be displayed correctly, is this too much? There are many different fields involved like multiple Page-fields which hold tags, categories etc. We installed Profiler Pro but it does not seem to show us the real bottleneck, it just says that everything is kinda slow and sums up to the grand total we mentioned above. ProCache does not help us because every user is seeing something different, so we can cache some fragments but they usually measure at around 10ms. We can't spend time optimising if we can't expect an affordable benefit. Therefore we opted against ProCache and used our own module which generates these cache fragments lazily. That speeds up the whole page rendering to ~7 sec, this is acceptable compared to 20sec but still ridiculously long. Our page consists of mainly dynamic parts changing every 2-5 minutes. It's different across multiple users based on their location, language and other preferences. We also have about 120 people working on the processwire backend the whole day concurrently. What do you guys think? Here are my questions, hopefully we can collect these in a wiki or something because I'm sure more and more people will hit that break sooner than they hoped they would: - Should we opt for optimising the database? Since >2k per request is a lot even for a mysql server, webserver cpu is basically idling at that time. - Do you think at this point it makes sense to use ProcessWire as a simple REST API? - In your experience, what fieldtypes are expensive? Page? RepeaterMatrix? - Ryan, what do you consider as the primary bottleneck of processwire? - Is the amount of fields too much? Would it be better if we would try to reuse fields as much as possible? - Is there an option to hook onto ProcessWires SQL builder? So we can write custom SQL for some selectors? Thanks and lots of wishes, Pascal from Mobile Trooper

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!

I just had a duh! moment and thought I should share as it may be useful to others, especially PW beginners. I know a lot of you will go "yeah well duh...." and yeah, well I feel like a bit of an idiot but anyways.... I had a page outputting a table detailing data from about 200 records (PW pages). For each record it searched for child pages of a certain template, probably averaging 3 child pages per record and added some data from those pages to each row of the table. Simple stuff. The page was averaging about 12 seconds to load. Anyway, today I got frustrated enough to try to work out why it was so slow. Turns out I realised that the child pages I was searching for were all direct children, so I changed my search method from $pages->get(....)->find(.....) to $pages->get(.....)->children(.....) and blow me down the page load has gone from 12 seconds to a tad over 1 second. Turns out each child page had many child pages of their own (thousand of pages in total) and all these were being searched with the find() method. Stupid mistake, but I think right from the beginning of my learning of PW the find() method was ingrained. So hopefully this helps some newbies and others like me. Check out http://cheatsheet.processwire.com/page/built-in-methods-reference/page-find-selector/ and http://cheatsheet.processwire.com/page/built-in-methods-reference/page-children-selector/ for more info on these methods and others.

Hi guys I've a PW site running real slow in the back end and was wondering about diagnostic tools. It's fine on the front end but takes about 12+ seconds to even load a page once I click edit. I often get 504 Gateway Time-out messages too. I have Tracey Debugger installed but I'm not really sure which options I need to check etc. Having cherry-picked a few and loaded a page in the front end, I only have one error (a missing include file) which doesn't affect my site. PHP 7.0.12 PW 3.040 MySQL: 5.5.41-1 Any tips? Thanks Peter

Hi, i noticed on my sites and also on other processwire sites, that the time to the first byte is quite long (> 500ms). Is there a way to speed up this waiting time, without using plugins like ProCache? i benchmarked some sites from the showcase and from Processwire weekly and nearly all of them perform bad at First Byte Time. is this related to Processwire or just standard behaviour for php/cms sites? Here are the tests: First Byte Time - Grade F URL: http://c-logistic.de/ Test: http://www.webpagetest.org/result/150601_J7_3992e9491b6acf72f73f10441880e6a2/ URL: http://von-bergh.de/ Test: http://www.webpagetest.org/result/150601_8S_cc7abdaa6519aae4904ea067ca5adf3c/ URL: http://www.canton.de/ Test: http://www.webpagetest.org/result/150601_7S_a8d3c3cf3d4f8ad2c3d3048a31864c81/ URL: https://www.maletschek.at/ Test: http://www.webpagetest.org/result/150601_42_8379a987c81ee2b8aa11f50b7a74694c/ URL: http://www.deichtorhallen25.de/ Test: http://www.webpagetest.org/result/150601_SS_90b428db03a86a5a309bd80aec294706/ URL: http://www.orkork.de/ Test: http://www.webpagetest.org/result/150601_VJ_63b76ec1ab9f37a93b9776320059a0a6/ URL: http://www.dojofuckingyeah.de/ Test: http://www.webpagetest.org/result/150601_J5_db3c199ddb74cfae513bbbe775b947c8/ URL: http://www.schloss-marienburg.de/ Test: http://www.webpagetest.org/result/150601_KY_01db3003b66dfad3b91aa40cbfda8f82/ First Byte Time - Grade C URL: http://www.grupoolmos.com/ Test: http://www.webpagetest.org/result/150601_ZH_8b9a2af518a9ac0cb30130e2aa3d3f2d/ URL: http://www.pipistrello.ch/ Test: http://www.webpagetest.org/result/150601_RK_5cf4d97c7fe1d4db3a145c565a84069f/ URL: http://transformationswerk.de/ Test: http://www.webpagetest.org/result/150601_9D_f16e00a262ec9d30b19ff67a290216ca/ URL: http://transformationswerk.de/ Test: http://www.webpagetest.org/result/150601_9D_f16e00a262ec9d30b19ff67a290216ca/ First Byte Time - Grade B URL: http://brakhax2.com/ Test: http://www.webpagetest.org/result/150601_JE_6552783547f8f7b73945a4698af8f231/ First Byte Time - Grade A URL: http://www.1815.ch/ Test: http://www.webpagetest.org/result/150601_Z5_f97b31533f61453aaeefc6cafef20e83/ URL: http://new.korona-licht.de/ Test: http://www.webpagetest.org/result/150601_RD_37ece6079e30ff5858c95db932f91e30/ URL: http://processwire.com Test: http://www.webpagetest.org/result/150601_V0_c812f846f6555e506fbd2b8ba9efe2e6/ Thanks!

Playing around with the markup cache on a website which is listing accommodation/activities. The page in question displays a number of listings (info about accommodation operator) and then a google map with markers for all the listings. I've cached (using markup cache) each listing, and also the google map markers, and the performance boost from this is pretty damn good, I'm stoked with the result. In the process I've got a bit obsessed with page-load speed and done some benchmarks. the following image is a sample page-load. The troubling aspect is time PW takes to get up and running. As you can see from the benchmarking info the vast majority of page-load time is PW startup - that is everything prior to the page template - ie, the time is measured from the start of index.php to the start the the page template file. Is this normal? This is on a live server (shared host) and the value varies from 400-600ms. Do installed modules have any impact on this? Is there any way to speed this up? It's reasonably snappy but if this can be improved then I'm all for it

Short tip Use the ajax powered search to find pages you want to edit—it's a super-fast way to get around the admin. Longer (but same) tip I was on the cusp of not writing this because it is likely so obvious to so many, but just in case you are like me in terms of navigation in the Admin for editing pages... In PW 2.4 the new search makes finding pages lightening fast. While some themes from before 2.4 was released display recently edited pages to help speed navigation, the new default theme in 2,4 doesn't; and I missed that a bit. But the new search is super fast so now whenever and wherever I am in the Admin, if I want to edit a page I just type in the search box, it ajax-pops, one click and I'm in the page ready to edit—no need to visit the page tree Thanks to Ryan and crew for this small but great advance OK, back to work.

Hello together! I am working on a new site with pw. It is just a little gallery site. In the past I used MODx for this but since version 2 (Revolution) this CMS is pretty oversized and extremly slow. So I decided to give it a try with pw. So far so good. On my local dev environment a basic page needs about 1.1s to get delivered by the server (only html). A short and superficially check (= end_ts - start_ts) has shown that "new Processwire()" took approx. 1s. Is this a "normal" loading time or is there any space for performance improvements. Imho 1s seems a little long... :/ Thanks guys! Chris #UPDATE well... next time I should dig a little deeper: It is a documented problem within MySQL. Mysqli needs about 1 second to connect to the database: http://www.borngeek.com/2011/04/05/mysql-performance-and-localhost-performance/ A switch from dbHost = 'localhost' to '127.0.0.1' fixed this problem.