Soma

You mean like here https://github.com/somatonic/AutoSave/blob/master/AutoSave.module

I experienced (something like) this in Chrome Canary yes, but it seems gone.

*Ping*

Templates -> Filters -> Show System Templates : look for "admin" template. Edit and go to -> "URLs" and look for https etc.

Yepsi dev, ths is what I assumed with "current".

Just to clarify things first. You have an actual page on your new domain that is newdomain.com/about/ ? First I wanted to mention that all urls in ProcessWire by default are with a trailing slash (unless you change template settings of this). And acessing newdomain.com/about will redirect you to /about/

And what is your rendertime... ?? Just so you know a loading time of the html of 200-300ms is pretty fast and standard.

Whats about hose strings to check? Yes those are coming from jQuery DataTables.

You may want to consider file an issue on github, as that is reather seen by Ryan and easier to manage: https://github.com/ryancramerdesign/ProcessWire/issues?direction=desc&sort=created&state=open

Problems solved, post removed

You could also debug the render time of your page with at the very beginning of your template code: $renderTime = Debug::timer(); and at the end of all when everything is output. echo "rendertime: " . Debug::timer($renderTime); And see what you got.

Yeah that's easy for them to blame your CMS Well you can try and for example save your homepage html to a static file, and upload that to your server and load it and see. (this would be same like using ProCache) I think we can't rule out ProcessWire, but most likely it's not but rather the server being busy with other things or some database connection lagging etc.

Your server response time has nothing to do with ProcessWire perse. This could have many reasons. Since I get response times from 300ms to 3000ms, it looks like your Server sometimes is busy. This could be database or other general server process running. You should ask this question to your hosting support. Template cache only works for not logged in users, as it shows on the template cache option settings.

Ok there you go. Just added a new module to ModulesManager 2.1.0. You'll just need to update the ModulesManager, after that you'll find the new module ready to install. Modules Manager Notification 0.1.0 Sends out update information for installed modules to an email This module required LazyCron core module installed Note this is something you want to run like once a week When the lazy cron is running the request will be blocked for a few second, this is currently due to how the lazy cron works. Maybe we will be able to optimize this in future. After install you need to define the interval, an recipient email, subject and optional a "from" email address. There's also a checkbox to activate/deactivate the module running the lazy cron job. Note that this requires someone to hit your website (or admin) to get executed, so interval times can vary. It will then refresh the module feed from modules.processwire.com on your installation and check for new modules. If any found it will send out an email notification to the email specified in the form of: Found following updates for installed modules: Module: TextformatterHannaCode v0.1.4 Found new version available: v0.1.5 More infos at: http://modules.processwire.com/modules/process-hanna-code/ –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– Module: InputfieldCKEditor v1.1.3 Found new version available: v1.1.4 More infos at: http://modules.processwire.com/modules/inputfield-ckeditor/ –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– It will also save a notification log modulesmanager_notification_log.txt with an entry when the lazy cron was executed in your site/assets/logs/ folder.

Found this also today. Yiiipi. Lots to explain

It's not only about "updates" it's about conveniently search download and install modules. It's also not about core features updates. Latest Additions is always the one on top, sorted by "Added". User favorites is not in feed, but likes, which is shown already. I'm working on a ModulesManagerNotification module for ModulesManager that you can install if you like and specify the lazy cron interval. Just need to test a little more.

a foreach = ? $floortypes = array('fliesen','stein','teppich'); foreach($floortypes as $floortype) { $page->floortypes->add("/floortypes/$flootype/"); } If you have the page referenced setup under /floortypes/fliesen/ etc

This code would work, but not really getting random entries but rather a random slice out of them. And query times are about the same. Strange thing is in my test I get a longer execution time of that code when I use $results = $pages->find("template=basic-page, start=$startOffset, limit=1"); // ~0.08 than with $startOffset = rand(0, $pageCount-4); $results = $pages->find("template=basic-page, start=$startOffset, limit=4"); // –0.03 Not sure why.

I don't really get your setup. Pretty exotic. What about /site/templates/ ? I'm not sure, but if you don't have your PW installed in a subfolder /5gum/ then it shouldn't include in it urls. But as I said I don't really get your setup here. Could be that you have the /5gum/index.php rendering something? Why do you have it this way? To your problem of the image url. It's simply because you do this in a bootstrap and there's no output formatting happening there. So if there's no output formatting any image field will be an array, regardless of the image field settings (set to max 1). So this will get your image echo $brand->meta_image->first->url;

I just did this random query over 45k pages and don't see any slow down. $pa = $pages->find("template=basic-page, sort=random, limit=4"); With 43k pages random query time: 0.0474 With 720 pages random query time: 0.0326 Almost as fast as a $pages->count()

I'm not sure I can follow but want to mention an easy way current PW version has You could use .. echo $widgetpage->render(); .. In the widgetpage you then have a $options array with some things in it. $options["pagesStack"] // an array with the page from where the widgetpage is rendered. You can also use some options on render() echo $widgetpage->render("custom_template.php", array("somevar" => "a value")); Then your widget page is rendering with the custom_template.php and will also have the custom var $options["somevar"]

You can filter them already enter "new version". About updates: The only thing would be using lazy cron to trigger something, that refreshes cache and looks for new versions. I can take a look at how exactly. Shouldn't be too much work. I like the idea. I think it's not something I want to use, cause most of the time updates to modules aren't really necessary to always update. Only if there's a security fix or other fix. Also some updates or more critical updates shouldn't be done on a live productive site anyway. What I also see possible is a general feed from modules.processwire.com one could subscribe to with updates.