Leaderboard

Most of this week and ProcessWire 3.0.10 has been focused on covering issue reports and related tweaks/fixes, which you'll see in the commit log. But we've also got a major upgrade to the core in 3.0.10 as well, with the introduction of ImageMagick and a new module type: ImageSizerEngine– http://processwire.com/blog/posts/processwire-3.0.10-expands-image-resize-options/

Here's a short module that adapts href and src links in CKEditor fields when a page is cloned: ProcessPageCloneAdaptUrls Normally, href links and image urls still point to the original page's assets folder when you copy (clone) a page. This module hooks into Pages::cloned and adapts all src and href attributes found in HTML tags that point to the old assets directory, rewriting them to link to the copy's assets. This module was motivated by a feature request (#1687) on PW's github tracker. Requires: ProcessPageClone (Core, but not installed by default) Status: beta Download: git repo Module directory Feedback: welcome!

Small update that enhances links from the PW Info panel Summary section - now you can have shortcuts to either view (page name) or edit (page id) each of the linked pages that are related to the current page. The children item now has: an "open tree" link (opens this page in the page tree expanded to show all children) an "edit" link (opens this page to the Children tab, which is particularly useful if you have Batch Child Editor installed). The template filename in the Template Info section uses the defined editor protocol handler to open the file directly in your code editor. Hopefully you'll all find these nice little time/click savers And page edit and template file edit buttons are also in the footer of this panel for instant access:

I think you're right, but it's more a case of "will be solved" rather than "can be solved" because the module isn't available yet. Eagerly looking forward...

@houseofdeadleg At the moment only the title is supported. You would need to change some code in the module: https://github.com/madebymats/FieldtypeLeafletMapMarker/blob/master/MarkupLeafletMap.module#L115 -> add another line 'markerBodyField' => 'body', https://github.com/madebymats/FieldtypeLeafletMapMarker/blob/master/MarkupLeafletMap.module#L192 -> add another line $body = $options['markerBodyField'] ? $page->get($options['markerBodyField']) : ''; https://github.com/madebymats/FieldtypeLeafletMapMarker/blob/master/MarkupLeafletMap.module#L193 -> change line 193 to $out .= "$id.addMarker($marker->lat, $marker->lng, '$url', '$title', '$body'); "; https://github.com/madebymats/FieldtypeLeafletMapMarker/blob/master/MarkupLeafletMap.js#L65 -> change line 65 to this.addMarker = function(lat, lng, url, title, body) { https://github.com/madebymats/FieldtypeLeafletMapMarker/blob/master/MarkupLeafletMap.js#L98 -> change line 98 to marker.bindPopup("<b><a href='" + marker.linkURL + "'>" + title + "</a></b><br>" + body); Then in the template where you render the map, you need to include the markerBodyField in the options that you pass to the render function, e.g. $options = array(); $options["markerTitleField"] = $page->title; $options["markerBodyField"] = ($page->body) ? $page->body : ""; // ... more options $map = $modules->get('MarkupLeafletMap'); echo $map->render($items, 'map', $options); I have not tested this but it should work. Please report back here.

Your page needs a parent.

Thanks Ryan and Horst for this great improvement! Newer ImageMagick versions preserves the color profiles as I know. Perhaps this is causing some of the file size difference in the examples. If explicit no profiles wanted, they could be removed with the "-strip" parameter. If you have AdobeRGB profiles embedded, image colors could be flat on sRGB-Monitors and/or some Browsers without color management. With IM you could convert these profiles to sRGB.

This can be set in My Settings > Notification Options...

This is a Leaflet version of Ryans Google Maps marker module. @Github

ImageSizerEngine NETPBM CLI Version 0.1.0 beta (requires PW 3.0.10+) Get it from the modules directory or from github. https://github.com/horst-n/ImageSizerEngineNetpbmCLI For information what it is and how to use and install, please read this Blogpost. Currently supported by Version 0.1.0: only JPEG, - no PNG, - no GIF GIF and PNG will fallback and handled by GD currently. This will be changed when I have a bit more time.

@Jugibur: that's all right what you are saying. - But, ... the -strip param is only available in the CLI version of ImageMagick, not with the PHP extension. But the PHP extension can handle embedded image markers as well, if, and only if: needed dependencies are compiled in. For ICC conversion, the lcms lib needs to be compiled in, what seems not by default or not with all extensions. Other cons are: with the PHP extension of Imagick, you cannot determine if it is supported / compiled in or not! And if it is supported, it will expand the processing time up to 3-4 times, compared to the processing time without ICC conversion. Therefore, and to have a homogenuous behave across all engines, we strip all image markers by default, but excluding IPTC. (stripped ones are: ICC, EXIF, XMP, JPEG-Comments, and others) Here are two more modules for the new ImageSizerEngine System: ImageMagick CLI Netpbm CLI

Just got that on a local json endpoint using ProCache. TTFB is surely improved, but there's still data to download.

Since browser support for flex is now pretty good, I am looking into using flexboxgrid. It looks very promising and looking at their github repo with all those likes and forks it sure will last. Has anybody here used it and what do you think?

The init.php file needs to be: /site/init.php Have a read about this here: https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/#new-core-files-for-site-hooks PS - the hook would also work in /site/templates/admin if you only want to prevent the view link in the admin. If you want to prevent separate viewing on the front-end of the site as well, then it should be in /site/init.php

I used quicksilver.js on the cheatsheet.processwire.com not sure that's what you're looking for. http://ejohn.org/blog/jquery-livesearch/

3 years PWired, but PW still surprises. Right marriage.

I suggest to read https://www.littlebizzy.com/blog/ttfb-meaningless, and especially look for TTLB (Time To Last Byte). IMO, TTFB is completly meaningless,the only thingthat matters is: how fast can a user read / see the content of a page. And if you read on Wikipedia TTFB_vs_Load_Time or the more in depth article why it is meaningless, you may see that this doesn't matter. One thing, what is described there for example, is, that if you use gzip compression for your html / js / css content, you get a higher TTFB, but the TTLB is 20-30% lower! But besides that, using ProCache is the fastest way to serve your content. It also includes a part that assist you to setup the server for gzip, caching etc, it can collect and minify your JS, CSS, and HTML files, and you completly ommit invoking the PHP engine and connecting to a DB.

(https://en.wikipedia.org/wiki/Time_To_First_Byte) ProCache does serve static HTML files! PS: TTFB is meaningless

@pwired There's nothing fancy about it. I've a small process module as well, which does the execution of the functions as well as storing which migrations are migrated and which aren't. // Migration.php abstract class Migration extends Wire{ public static $description; abstract public function update(); abstract public function downgrade(); } // 2016-03-03_18-27.php class Migration_2016_03_03_18_27 extends Migration { public static $description = "Update Homepage title"; public function update() { $this->pages->get('/')->setAndSave('title', 'Super fancy new Homepage title'); } public function downgrade() { $this->pages->get('/')->setAndSave('title', 'Home'); } }

Perhaps this module from kongondo will let you do what you need without need to add your own hooks: http://modules.processwire.com/modules/fieldtype-runtime-markup/

Before PW my approach was to keep data of the content and data about the system in separate tables (and files). That helped a lot. Given PW's great API, migration scripts is the way to go. I'm not there yet but I've been doing massive data imports using scripts and API and am very pleased with how well that works. The challenge is keeping track of what you did while trying out different approaches and refining things. Probably makes sense sometimes to have Sandbox, Staging, Live. Do the messy creative work in the sandbox. Reproduce those changes deliberately and systematically on a fresh copy (Staging) using your scripts. Repeat as needed. Then (make a backup and) apply scripts to Live.