Leaderboard

Thanks for this module, it works even as expected in a 3.x ProcessWire installation. But it took me a while to understand how this module works and what I have to set up. At the end it's pretty easy but I had to read 9 forum pages and failed initially by installing the wrong module. I summarized all collected information and updated the Readme file (see PR at Github), maybe someone else could benefit from this. To prevent others from installing the old module as well, could @apeisa or someone else having access rights maybe add a litte note to the first post? One more thing: I use MarkupSEO and got some trouble overriding the module config data for each site. Unfortunately I found no way to hook into that specific function and decided to submit a PR as well. Now I can use the following config: $config->MultisiteDomains = array( 'domain1.com' => array( 'root' => 'www.domain1.com' ), 'domain2.com' => array( 'root' => 'www.domain2.com', 'http404' => 1932, 'markupSEO' => array( 'piwikAnalyticsIDSite' => 12, 'titleFormat' => '{title}' ) ) );

Hello! Thank you for mentioning! I'm the author of Gor, feel free to ask any questions.

One way to do it: Grab a coffee (optional) Copy over the core module to your /site/modules/FieldtypeCommentsCustom/ Rename the files, e.g. FieldtypeComments.module to FieldtypeCommentsCustom.module Rename all PHP classes in that folder to e.g. 'OriginalNameCustom'. For instance: FieldtypeComments could become FieldtypeCommentsCustom Make your changes to the files in FieldtypeCommentsCustom folder Install the module FieldtypeCommentsCustom (could have been done before #5 if no database schema changes made) Create a field of type FieldtypeCommentsCustom, add it to your template, edit a page...the usual drill Take your third sip of the coffee in #1 (optional)

Hi justb3a, thanks for your effort. A simple like didn't feel sufficient enough. I use soma's new version on several sites and didn't even consider creating a readme. Great work. edit: and soma too offcourse for creating the new version

http://modules.processwire.com/modules/process-custom-upload-names/ That module will ensure nice filenames - you can configure however you want. That's great for future images, but for the current ones - there is an option in the module to "Rename on save" - generally I don't recommend this one, but in this case it would allow you to create an API script to loop through all pages and resave them. I would test first on a sandbox PW install to make sure everything works as expected.

I have just delivered this website: Into Nature (Dutch only), about an 'Art expedition' through the province of Drenthe, in The Netherlands. I built the site for Vandejong. The site is made using two distinct parts/techniques: Processwire for the back-end (through a RESTful json api) and the front-end is built on Ember.js. This is my third large site built this way, and the first I am completely happy about. A page called 'API' is the main interface between the two: it uses urlSegments and parses the content from the PW pages into Ember-friendly JSON data. As Ember is very strict (heavily based on the Convention over Configuration concept), and Processwire is extremely versatile, the way Ember requires its data dictates the way I shaped the API. Both @clsource's REST-helper and ProCache are used to format and cache the API responses, making the API very responsive. Something that was initially hard to wrap my head around was how to deal with the site's routing/pagetree. While Google now indexes modern 'single-page' web applications, for instance Facebook still scrapes their opengraph from the raw HTML pages. I dealt with this by giving the Ember app and the PW page-tree use the exact same routes / pages. Every Processwire page is a valid starting point for the Ember app, while also including the scrapeable meta tags belonging to that exact URL. As a result, the whole thing is nicely CURL-able and bot-friendly.

Hi @Roope, before we go into detail, I have one question about what PW version you want support: PW 2 or PW 3? If you are not rely on PW 2, there will be lot more possibilities. But there are ways for both versions. What I suggest for both versions is, not to hook into Pageimage or that like, you only need and should hook into Imagesizer::resize. You can add any option to the options array of Pageimages. You can do this with individual API calls, or you can do this as a sitewide setting in the site/config.php under $config->imageSizerOptions. $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? 'sharpening' => 'soft', // sharpening: none | soft | medium | strong 'quality' => 90, // quality: 1-100 where higher is better but bigger 'hidpiQuality' => 60, // Same as above quality setting, but specific to hidpi images 'defaultGamma' => 2.2, // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0) 'tinify' => true, // your option for all imageformats here // or your options for specific formats 'tinifypng' => true, 'tinifyjpg' => true, 'tinifygif' => false, // or whatever you like ... ); Regardless if you use sitewide or individual options, they will make their way into the ImageSizer. Using sitewide options and overwriting them with an individual value passed as $options array in the API works too. This is all supported in PW since version 2.5.11. The only thing what I would hook in, (if you need to support PW2 too), is the Imagesizer::resize method: before: check if tinify is requested and if true, adjust quality for jpegs to 100%, (and, maybe, add "tiny" to the suffixes array ??) after: pick up the resized image variation and transfer it to your tinify service If you can go with a PW 3 version only, I have some thoughts to standardize optimizations like yours: they should be able to register themself into the ImageRenderingChain as optimization / compression tools. This way, the PW ImageEngines would take care for most of the above stuff and simply call (at last step) your provided service. ---- // example for PW 2.5.11+ public function init() { $this->pages->addHookBefore('ImageSizer::resize', $this, 'hookEventBeforeResize'); $this->pages->addHookAfter('ImageSizer::resize', $this, 'hookEventAfterResize'); } public function hookEventBeforeResize($event) { $this->image = $image = $event->object->image; // first do a check if tinify is requested if(!$image->tinify) { // or do we need to look into $image->options['tinify'] ?? for user options ?? $this->tinify = false; $event->replace = false; return; } // tinify is requested, set a flag for the hookafter and adjust quality $this->tinify = true; $this->image->quality = 100; } public function hookEventAfterResize($event) { // was tinify requested or not if(!$this->tinify) $event->replace = false; return; } // pick up the variation file and pass it to the tinify service ... }

Yes, use a custom date field. We do this in the module Blog with an autoload module. Here's the code if you are interested.

Check if the module AdminRestrictBranch can help you: https://processwire.com/talk/topic/11499-admin-restrict-branch/

Hi Alxndre', I suspect this will require a core change to support. The %= selector maps through to a MySQL LIKE statement - which is a string comparison operator. Edit: Perhaps you could store a text field (let's say: controlnumber_string) which stores the string version of the value of the controlnumber field. You could make it hidden and have a hook populate it whenever controlnumber was changed. You could then use controlnumber_string in your selector.

#1 Yes...that is what this would entail. This approach is for those who either have a temporary need (e.g. until a PR is accepted) OR for those who've bought a one-way ticket; no looking back . Going by what you are saying, this is not for you #2 Yes, what you are describing is called overriding in PHP (and many other OOP languages). You would have access to protected and public methods and properties but not private ones. Overriding occurs many times in Fieldtypes. Take for example the method ___getConfigInputfields() that's present in quite a number of Fieldtypes. FieldtypeComments has that method. But that's not its origin. FieldtypeComments extends the class FieldtypeMulti, so it inherits it through this class. But wait a minute. FieldtypeMulti is not the origin of that method. Instead, FieldtypeMulti also inherited the method from its parent class, Fieldtype. Look the table here 'Methods inherited from Fieldtype' (you can follow the links deep into the recesses of PW ;-)) Here's some links to helpful resources about this (and similar/related) OOP concepts http://stackoverflow.com/questions/2994758/what-is-function-overloading-and-overriding-in-php http://www.techflirt.com/tutorials/oop-in-php/overloading-and-overriding.html https://www.codecademy.com/forum_questions/516763621eb11e53a20018d5 http://www.phpro.org/tutorials/Class-Hierachies-And-Overriding.html http://www.phpzag.com/overloading-and-overriding-in-php/ http://php.net/manual/en/language.oop5.visibility.php http://stackoverflow.com/questions/4361553/php-public-private-protected http://www.techflirt.com/tutorials/oop-in-php/visibility-in-php-classes.html

It's a very nice website indeed. I just had an issue while viewing the site from my mobile phone (Chrome on Android): there appears to be no background on the navigation, so it is very hard to read depending on the scroll position. I would suggest to add some kind of background color to make the navigation links more visible.

In this case, I would actually suggest to create a new field for the order number, since it complicates things to have a multilanguage field for this value. And as a multilanguage title doesn't make much sense for an order, you could make the title not required and hidden (under the visibility setting) for this specific template.

Reddal is a global professional services firm offering business development as a service. The company has expanded rapidly to offices in Helsinki, Seoul, Dubai and Kuala Lumpur. http://www.reddal.com/ From the ProcessWire point of view the Reddal.com was designed and developed for maximal flexibility. The site was arranged in sections in which each layout segment is represented by a ProcessWire page. Segments can be re-arranged like Lego blocks within a set of visual constraints. This allows for long and visual pages throughout the site. Modules used: - Form Builder - Lister Pro - ProCache - InputfieldMapMarker - Redirect Branding, design and development by Nordenswan & Siirilä. http://www.nordenswansiirila.fi/ Primary site photography by Marek Sabogal.

Bea, thanks so much for your work here, very appreciated! I pulled the R. https://github.com/somatonic/Multisite/tree/dev I'll have a go and add a note on the first post. Sorry for the confusion.

Nothing special in the backend, just a very practical arrangement of pages and templates. Each top-level page is a template "section" which basically contains: foreach($page->children as $child) { include('_' . $child->template . '.inc'); } Then each building block is a template such as "block-main-header", "block-one-column", "block-video", "block-map" etc (dozens different kinds). These building blocks each output one type of page segment (or pattern) and can be used anywhere on the site (also re-useable across projects with relative ease). Some block templates are coded to vary content depending on where on the site they appear. Others are coded to be aware of blocks around them. Clients seem to like this arrangement as it allows rich and flexible pages without too much complication on the admin side. All templates need to have strict parent/child limitations to avoid issues.

My thoughts exactly. Currently these panels are fun, but this could increase their potential use cases exponentially

Hello adrianmak! How do you handle passing values to the PayPal checkout? Maybe you'll need something like this: if($user->language->isDefault()) { $value = $page->fieldname; } else { $value = $page->getLanguageValue($user->language, 'fieldname'); }

Love these new additions too. I keep thinking the new quick tree panel should open from the left side on the Reno Theme instead of the right. The icon placement itself makes sense but I get a sense that in a left to right world, it would feel more natural on the left.

Hi, thanks for your replies. In SQL, I usually cast the integers to string first so it can be used against LIKE. But I can't find enough examples using $db->query to do it. I'd keep searching for now. Thanks again.

I assume, the Samsong mic is for singing only.

Ryan, I'm just seeing this now — doooode — super awesome! I've been head down in some major projects the past few months, so I haven't had a chance to do much more than read the weekly blog posts. I can't wait to dive into some of these new features. Thanks for keeping the Reno Amin Theme up-to-date with all this new stuff.

I have just started playing with the page tree panel and I think I'd rather see it appear beside the current view's content, rather than on top of it. That way I could leave it open and return to what I was doing - it can be a handy reference for other tasks. It would work the same way as the side menu in the Reno theme works. I'd actually like to see it remember it's open/collapsed status also. I know you are worried about the overhead of rendering a page tree on every request, but with the new page tree from 3.0.8, isn't that less of an issue now? Now it's just rendering, rather than querying? Or do I have that wrong - I actually haven't checked the source to see what's actually going on there. I am also not sure why it has to be so wide - currently to close it you have to move your pointer to the middle of the screen to either click the panel label or the main page to make it disappear. Any reason it can't be the width of the widest page title? Also, I have what I think is a bug. If you are on the Setup page: http://pw.dev/processwire/setup/ and you click the sitemap icon in the breadcrumbs, it loads the Page Tree fully, not in a panel.

@Roope: this is good news. I have only one suggestion: I would avoid the uncontrolled automated mode! (for every size() request!) Instead I would bind it to a defined suffix option (tinify). Or you do it the opposite, check for a suffix (notinify) and compress all others. This is the only way to be able to also produce intermediate images wich resulting pageimages will be passed to another image->size() request. Also, if the image is marked to get compressed, you need to check the setting for quality (if it can compress jpegs) and adjust it to 100%. If you compress images with quality settings lower than 100 and afterwards pass them to the compress service, you will get results with higher filesize! and with lower visual quality! If you have any questions to my suggestion, I'll be glad to give more info and / or point to some. https://processwire.com/talk/topic/6667-jpegoptimimage/#entry65531 (the first part) http://images.pw.nogajski.de/jpegoptim/ (compared different imagesizer quality filesizes)

As promised, here's a link to my module that RyanJ's been helping to test out.

I've PM'd my module over to Ryan for testing. Let's see what comes of it over the next couple of days. If it works out we'll post updates here.

I think situation could be better. Especially for the things like the inputfields.js that LostKobrakai mentioned. So most probably some changes coming at some point.

Hi, Here is what you can do to redirect the home page '/' to the French home page: Set page names for both languages for the home page ('en' for English, 'fr' for French) In the LanguageSupportPageNames settings, choose the option "No - Root URL performs a redirect to: /name/". When you go to the root url '/' it will redirect you to '/en/' Finally, create a module to hook into Session::redirect to force the redirection of the root url to the French translation as follows: public function init() { $this->session->addHookBefore("redirect", function($event) { if ($this->page->id == 1 && $event->arguments(0) == $this->page->localUrl('default')) { $event->arguments(0, $this->page->localUrl('fr')); } }); } The hook checks whether you are viewing the home page, and whether you are redirecting to the English url, and if so, it changes the url to the French url. This solves the problem of the home page. The problem remains if someone has saved a direct link to a page without a language prefix, e.g., '/about/', since this will still be redirected to '/en/about/'.