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>

You can not know the client time at the point when the server is first hit, it would require two pages/requests - the first to serve the javascript and the second to recieve the result of the javascript. That is why it's much eaiser to pass PHP time() to the page as a javascript variable and let the client-side handle the locale, if you need to syncronize. <script type="text/javascript"> var d = new Date(<?php echo time(); ?> * 1000); document.write(d.toLocaleString()); </script> If you must do it the other way around, you can redirect to the session - but it's a bag of worms. I'm using a non-processwire session to keep the example simple. <?php session_start(); if( !isset($_SESSION['client_time']) && isset($_GET['client_time']) ){ $_SESSION['client_time'] = $_GET['client_time']; } ?> <script type="text/javascript"> var server_time = '<?php echo addslashes($_SESSION['client_time']); ?>'; if (server_time === ''){ var d = new Date(); window.location = window.location + '?client_time='+encodeURI(d.toLocaleString()); } document.write(server_time); </script> EDIT: Beaten by Adrian and Pete, also good answers.

Thanks Joss - that's a good workaround. I hadn't thought of that. Though, there would still be some instances with more than one image (varies template to template).

Does anyone know if it's possible to configure the images field to require description text? A fallback would be to write an onsubmit handler in javascript for the admin - but if it's possible to enforce at the configuration level, that seems like a much cleaner solution. EDIT: the core image field is already in heavy use. If possible, I'd like to modify existing instances rather than create a custom field.

As long as your environments are hitting unique server names (dev.example.com, www.example.com), I don't think session collision should be a problem. In the login form, do you have a CSRF token (the _post_token hidden input)? Any chance you're using a custom admin theme? EDIT: You could try another setting, in config.php: $config->protectCSRF = false; It's best to leave it enabled, but it might help rule out other issues.

Thanks Ryan. That may have something to do with the Linux/WIndows deviation - Windows (localhost dev) is on Apache and Linux is running nginx. I'll have to take a closer look at the .htaccess file and make sure to create a parrallel rule for nginx. I believe I may have overdistilled the test case above, a better example would be (apologies for the oversight): http://www.example.com/news/*/news I'll dig a little deeper into the rewrite rules angle. EDIT: Forgot to mention -- I am just pasting the url into the browser. I'm running PW 2.2, PHP 5.4, and nginx. EDIT #2: Digging deeper, I don't think the htaccess rules stop the behavior because they are encoded before leaving the browser - they're coming through in the logs as hexidecimal encoded characters.

I've seen a couple of these myself happen due to malformed markdown links, it's reproducible. To cause it - you take any page above the homepage, and add a special character (!@#$%^&*()) followed by a backslash. It'll throw the rootparent error. For example, http://www.example.com/news/*/ seems to throw it consistenly in LAMP, though not in a Windows environment for some reason. Not sure of the etiquette, perhaps I should've created a new thread rather than reanimate one that's over a year old?

I think it is normal, just checked and I see 7k session files - the oldest of which is from yesterday. The directory seems to be cleaning up after itself. You may be approaching a hard limit of 32k if your filesystem is ext3, plenty of headroom if you're on ext4 though. I'd make sure that the files are being removed (automatically) - if not there may be a permissions issue. Edit: incorrect. 32k is the ext3 limit for subdirectories, not files.

Nevermind, I must be blind. The setting is in the images field setup on the input tab - the last field in the fieldset, "Max Image Dimensions".

I was wondering if anyone had experience with placing a threshold on the size of an upload using the images field. It doesn't matter if the constraint is by dimensional/pixel area or by kilobytes, the point is to only to keep gigantic camera jpegs off the system. Limiting the global php upload maximum isn't an option because the site needs to handle pdfs and other media. While the optimum strategy would resize the image programatically on upload (if it exceeds certain conditions), throwing an error would also be fine. Poking around InputfieldImage.module, I'm seeing maxWidth and maxHeight properties (applied in ___fileAdded the method) that look like they would be perfect, but I can't figure out to apply the settings to the field. Thanks!

I'm working with a events calendar myself, though I elected to take a more service oriented approach using google calendar and outlook generated *.ics feeds. If your calendar is going to be as simple as you describe, you might be able to get away with the following approach. Set up three datetime fields - event_start, event_end, and recurrence_end. Set up a text field, recurrence_rule (rrule). Add the PHP When library to your project. For recurring events, set your rrule based on byweekday, bymonthday, etc. You can generate rrules with a google calendar (add a recurring event and look at the ical feed) if you're new to them. For the range to be displayed (e.g. today + 3 months) you can use the api to get all events that have start/end OR start/end-recurrence overlap with the displayed range. Set up an array and loop the events, using PHP When to generate a list of occurences if an rrule exists, push rule occurences and non-rrule events in as as siblings, sort by event_start/occurence_start. Render the list of occurences. That's the basic formula anyways.. If you are avoiding google only because of the look of thier embeded calendars, you might consider rendering your own calendar of events with PHP When and the raw icalendar (*.ics) feed they provide. Edit: grammar.