Ben

I took a conservative approach and added some stylesheet onload bookkeeping. I'm optimistic this will fix the flash of unstyled content once and for all.

I think the FOUC has been squashed in github (1.0.2). Thanks for the report, Adrian.

I can take a look at that, for whatever reason I'm not seeing the flash, maybe a browser thing but I should be able to track it down. By "details frame," are you referring to the area with the blue heading covering the majority of the page, or the summary off to the right?

I didn't see the edit button, very cool. Thanks.

Thanks Adrian, I'll get this update into the github repo this week--definitely a big plus to get 3.0 compatibility. Update: fix is on github, and version revved to 1.0.1--somewhat off topic, but do any module developers know if module pages (modules.processwire.com) pick up changes on github?

Perfmon Debug Toolbar is a Processwire module used in performance monitoring and optimization. This module has been kicking around for some time, but I finally got around to publishing it. The user interface is heavilly influenced by django-debug-toolbar if anyone is familiar with that project. During install, $config->debug must be set to true for the toolbar to run, the module is not intended to be enabled on production. The primary goal of the module is to identify bottlenecks and help tune up code. More information is here: https://github.com/KeeneState/DebugPerfmon Please let me know if you have any difficulty installing or running it. It's intended to be run on a development instance, though it can exist in a dormant state in production. Collapsed presentation (top right of screen): Expanded Presentation:

Having milliseconds retrieval time in the PDO querylog would shed light on an otherwise dark corner of performance monitoring. When the MySQL adapter transitioned to PDO, the query log timings were omitted from the log output. The older MySQLi logs included milliseconds elapsed, which was helpful in surfacing retrieval bottlenecks. Attempts to manually profile PDO queries often run up against a profiling_history_size of 100, a limit imposed by MySQL itself. That is to say that getting a complete list of timings over the course of serving a page isn't always easy. Having these added back to the querylog (if possible) would be extremely helpful.

One consideration -- if you anticipate customized instances, with different fields or templates for the various clients, you may run into scaling issues as you grow the site with a single install. That said, if every client is on a unified template/field setup, this isn't an issue.

One thing to rule out are the two main php variables that govern garbage collection. ; gc_maxlifetime -- this is a session keep-alive in seconds. php default is 1440, or 24 minutes. session.gc_maxlifetime = 1440 ; gc_divisor -- this will affect the probability of garbage collection executing after gc_maxlifetime has passed, it can make session expiry feel random. session.gc_divisor = 1000 You should be able to echo these out with: printf('session.gc_maxlifetime: %s', ini_get('session.gc_maxlifetime')); printf('session.gc_divisor: %s', ini_get('session.gc_divisor'));

Yeah, the random nature of it can make troubleshooting difficult. It sounds like a configuration issue. Kongondo has the right idea, but if it doesn't pan out you'll need to trap the error status in the network panel. You can do this by leaving the network on and mashing refresh until failure, then clicking that filter icon and filtering to "css". Basic gist.. 500 means webserver isn't configured correctly. 404 missing or misconfigured 403 permissions error

If you open up your browser's dev tools, and reload with the network panel active, what are the http responses for the missing js/css?

Would be great to see a new form of field-grouping in the template setup, one that conceals the inner workings of open and close fieldsets. The field nesting could use a UI similar to page listings where a field can sit under (indented below, draggable) a fieldgroup. Basically, this would make it idiot-proof. This comes out of an upgrade from 2.3 to 2.5. I was confused as all my fieldgroup tabs either broke (wouldn't open) or didn't display during page editing. It turns out that when I set up the site (originally 2.2), I was a little obsessive about keeping the field-names snake_case. I came up with an alternative convention to the groupname/groupname_END because it didn't look right to my eyes. I know, I know.. but it worked from 2.2 to 2.3. It took a while to track down what was going down. But the _END convention became enforced somewhere between 2.4 and 2.5. While I'm certainly a edge case, the convention can cause strange behavior as there's no way to know of the constraint until something goes wrong. Concealing the formbuilding mechanics would both eliminate the potential for misconfiguration and make field grouping more intiutive. *********************** Edit 9/26: I think my initial post was confusing. After using the new default admin in 2.5, the indented presentation already exists. I hadn't seen that before writing the above, which I think contributed to a poor presentation of my case. Were I to boil down the suggestion to its core, it's that the underpinnings of the FieldsetTabOpen are being surfaced unnecessarilly in the admin. The site administrator doesn't need to know of the <fieldgroup>_END. Better to conceal it from the front-end, or remove it altogether.

Joe, I don't know if there's a way to kill the session in Processwire - it could be one of the assumptions the framework is based upon, and therefore not optional. Someone more familiar with internals can speak to this, but yes, many websites can run fine without cookies. You could try to "unset" set-cookie, cache-control, expires, and pragma using mod_headers to get the response session-free and client-cacheable. I've never unset a header, and then set it to something else so I don't know how apache will handle resetting cache-control. Another option, albeit extreme, is to generate a static site from PW using wget. This will only work if the site rarely changes, but will ultimately be the most optimized way to deliver the site. FWIW - the reason I recommended not caching html to the client is that once it is out there, it's impossible to invalidate. Where a server-side cache can invalidate the cached page when updated through the admin, a client side cache will not check for updates and it can lead to trouble. The html itself is generally a very small file (relative to the download of images, css, js), so the performance gains are minimal. Looking at your headers, you could also get a nice performance bump using mod_deflate to gzip the transfer of text (html, css, js). Hopefully this helps.

You can modify your php.ini to use a different cache-limiter from the default "nocache". The others ("public","private") use different values, though they do still set the cache control. You're better off sticking with the default nocache option, if possible - it will be more predictable since that is what 99% of the PHP world is using. If you want to optimize caching for performance reasons, the most common strategy is to aggressively cache media (css/js/images) to the client and cache html responses on the server-side (either by proxy, the standard caching module, or the procache). Limiter Options: http://www.php.net/manual/en/function.session-cache-limiter.php

The first instance of the Cache-Control headers is from a session_start() - it's not Processwire per se, it's PHP initializing a session. http://www.php.net/manual/en/session.configuration.php#ini.session.cache-limiter EDIT: You may be better off only modifying the caching on css/js/images and letting the html pass unmodified - especially when a session is active. That can be done with a FilesMatch wrapper similar to the one used prior: <FilesMatch "\.(jpg|jpeg|png|gif|js|css)$"> <IfModule mod_headers.c> Header set Cache-Control "max-age=7200, must-revalidate" Header unset Last-Modified Header unset Pragma </IfModule> </FilesMatch>