Leaderboard

This week I've got to keep the blog post a little brief because I've been so caught up in this weeks' updates that I've run out of time to write much in the post! The updates this week are not actually to the core code, but rather to the API reference documentation for ProcessWire 3.x. There's lots more work to do still, but I definitely have a good start, so going to introduce it here in this post. https://processwire.com/blog/posts/processwire-3.x-api-reference/

#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

Hi! Let me give you a hint: (I am about to leave the house now, so I wont set up a testthingy now, but just stumbled about the error ) One of your double </li>s is just misplaced - there is one </li> missing after the "Rezepte" item. If you recap your code and look what it does I think you will find the solution! Otherwise let me know and I can try to fix it the weekend. Hope that helps! lg Steffen

I think there was a discussion on this, and it was on a (lengthy) todo list. I also think that the default repeaters should be avoided, and I wouldn't mind removing them entirely.

I decided to update the Tracy core now anyway - please let me know if the latest version fixes it for you.

Thanks @Mats! The map tiles are designed in Mapbox, the map itself is built on Leaflet.js, using the great Ember Leaflet addon. Once you get the hang of Ember.js (quite a steep learning curve) and it all starts making sense, it becomes really logical and fast to build upon. Because it is so strict, you can predict how components and external addons will work, and how to separate your functions. All using the same philosophy. As a result, it's peanuts to toggle markers and other layers on the map that relate to other items in the application. Let me illustrate how easy it is. The polylines are added by adding a Polyline-layer, which is part of the Ember Leaflet addon. It requires 'locations': an array of lat/lng points. The stripped down version of it works like this: 1. From the API we get, for instance, this JSON for the Hoofdroute (main route) -> http://www.intonature.net/api/routes/hoofdroute 2. Through the default Ember Data Rest adapter this JSON gets loaded into the route* model: // models/route.js import DS from 'ember-data'; export default DS.Model.extend({ title: DS.attr("string"), points: DS.attr("array"), color: DS.attr("string"), }); 3. After the model promise is fulfilled, it renders the Template belonging to the Route*, often with help from an Controller to 'decorate' the data. If that made no sense, you can also read that previous sentence like this: Through the magic of Ember this ends up at the Map Component which is inserted into the Explore template. The stripped down version of the Explore template: {{!-- templates/explore.hbs --}} {{map-component locations=locations currentItem=currentItem currentPreviewItem=currentPreviewItem routes=routes }} 4.And then inside the map component we get the following: {{!-- components/map-component.hbs --}} {{#leaflet-map id='explore-map'}} {{tile-layer url=tileLayer}} {{#each routes as |route|}} {{#if route.points}} {{#polyline-layer locations=route.points color=route.color }} <span class="route-label">{{route.title}}</span> {{/polyline-layer}} {{/if}} {{/each}} {{/leaflet-map}} And that is essentially it. We load the /explore route*, which loads data from the server and puts it into a model, then renders its template. This template contains a component which draws polylines on top of a tile layer. My previous large map-oriented / PW- & RequireJS powered project took overall about 300 hours to develop. In large because I had to invent the wheel, discover fire, and then deal with burning wheels everywhere. In short: I was missing a strict, well defined idea of which part is responsible for which function, something that happens to a lot of developers I have noticed. That, combined with the incredible shitty documentation of the non-standard Google Maps stuff and some other setbacks made it quite a tedious project. (The resulting site is still quite nice though: http://www.vangoghroute.nl ) Developing Into Nature took me around 90 hours, of which maybe half map-related. I still had to figure out a lot, yet I don't think I'll quickly return to the old world of "Php-generated html with bits of Javascript here and there and oh let's throw some more Ajax at it shall we?" * Let me clarify: We are dealing with 2 kinds of routes here. First of all the "Into Nature art routes", and then there are the 'Ember Routes'. Ember Routes are the urls of the app, and responsible for getting data and injecting that data into models.

Thanks for the hint, it's fixed. I thought I tested the link! Considering this module and future development of PW. Yeah, I was playing around with that yesterday, but couldn't see a solution. Unfortunately I knew this would one day lead to complications. :/ After little experimenting I think we need to rethink $page->url rewrites Multisite does in the admin and consequently in the front-end. I always feared it was maybe dangerous/adventurous and would lead to problems sooner or later. There's so many things to consider it's crazy. So, after long thinking and testing, I'm heading towards letting the $page->url alone, to not get in the way as much as possible. Then we just have to make sure 2 things: 1. when an url is viewed containing a "domain" in its path that is recognized, to redirect the correct domain/url. So a view link will just work. 2. to have correct url on the front-end output, we can parse the $page->render() output and replace/fix those urls output from templates and RTE's. This way such new features like the "View" options work out of the box. Also cross Domain linking in RTE would work also. I got a test version working so far but not sure about what to further consider with this new approach.

It is a core module, but you have to install it. It's in Modules > Core > FieldType > Profields: Page Table, and you click on Install.

That's why your excluded workflow (flexible downloads) is called flexible.... First solution ("your no-way please not" one) switch to a one file approach in combination with a PageTable Field to add more than one file....and use the flexible downloads solution. It could be done just with some thinking - setup some fields - setup templates for the single document and the overview - some code - finished Second solution adapt the core modul itself and change it - this is not the easy part if your a not familiar with creating or changing PW (core) modules. Some impression how the first/easy solution could end (even easy to use for the client): Regards mr-fan

For some methods you might want to just return parent::nameOfMethod()

An iframe is for a webpage in a webpage that's why the youtube is working and your local mp4 isn't. For a local mp4 (or webm and ogg) you have to use the html5 video format: <video id="yourmovie" src="yourmovie.mp4" controls></video> You have to check what video format is supported across all browsers. I think mp4 is now supported by all modern browsers. <video width="320" height="240" autoplay> <source src="movie.mp4" type="video/mp4"> <source src="movie.ogg" type="video/ogg"> Your browser does not support the video tag. </video> A problem with the html5 video format is that the html5 player does not look the same across all browsers and the autoplay attribute does not work in mobile devices like iPad and iPhone. To make the player look the same across all browsers and also escape the autoplay attribute problem you have to use a wrapper like this one: http://mediaelementjs.com/ To make things even more easy you also could make use of Adriaan's video field type: https://processwire.com/talk/topic/4580-video-fieldtype/ echo $page->video_field->play;

proud to share the release of a little handy sorting module for image and file fields (edit: some bugs in the screencast that are already solved) the autosort option can be set in the field-admin: Caution there is some work planned on the images field, so this may break the functionality of this module. have this in mind. github: https://github.com/BernhardBaumrock/InputfieldFileSort module directory: http://modules.processwire.com/modules/inputfield-file-sort/ changelog 1.0.0 initial release

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.

Do all your fields match up on your form to what the module has generated? Check your template field names against what is in the module settings. Make sure you save the module if you have updated or changed any fields. Also check the antiSpamCountAdditonalInputs in the module settings and make sure those fields exist in your template.

For that number of data nodes I'd suggest using neither repeaters nor ProFields Table but a PageTable. Even for a small repeated fieldset of 3 fields this would result in 180 to 240 Inputfields just for the repeater. This can really draw browser rendering performance even if the server does respond correctly. If the number of repeater fields would be near 12-15 you're also close to hitting max_input_vars limits. With PageTables both issues do not apply.

I had this happen to me where a client used the repeater field out of it's planned scoped. (It was only suppose to have only 4 but it now has like 60 and the back end takes very long to load or eventually times out) You'll probably need to rebuild your records as a custom template page instead of using a repeater. You can write a script to move your data from the repeater field into your new custom template page.

If there's nothing in the errors.txt the error does happen before pw's error handling kicks in. So probably some error either in config.php (simply checked by adding die() in various places and see if the error persists) or with any autoloading modules or in init.php. Also check your php/mysql/apache versions for any obvious mismatches.

Ok, thanks. Seems that 1.2.6: fail (f8d4ca6c1f8afe31331bdaa94a89b50874371586) 1.2.5: works (TracyDebugger-3f7e1081446ba2d65c8ab2f093f5cb88bfd3bda3)

I'm having the same issue Guy Verville had. Downloaded a website from production to local, imported the database, changed mysql authentication on config.php (checked it thrice) and the same error occurs. Nothing on errors.txt, and changing debug to true adds nothing to the message. I also changed permissions of everything to 775. Nothing seems to work. I'm clueless. *EDIT* : Also tried invalid DB login info to see if something would change. Nothing. *EDIT 2* : Placing echos all over index.php I eventually narrowed it down and discovered the previous coder messed with the file. Problem fixed.

@tpr - sorry to hear that - definitely weird as it's working fine here. Obviously hard for me to debug without any errors. It would be awesome if you could figure out the exact commit that breaks it for you. You can download the zip from Github for each commit quite easily. That will take you to a link like this: https://github.com/adrianbj/TracyDebugger/tree/0b9696921bcd33ac18460b5501f13c8784b4188b From each of these you can use the normal "Download Zip" button. Sorry this could be quite time consuming for you. You probably do this already, but in this situation I always grab the middle commit between the one I know is working and the one that isn't. If that works then split the difference to the latest and if it doesn't split the difference to the oldest and so on - that should reduce the effort significantly. Thanks for taking this on!

I assume you 're using PW 2.7.x and the latest stable version of the module (master branch / ProcessWire module directory). If the second form contains different fields than the first one, you need to pass a lot more params as only the 'allFields' key. (at least requiredFields, emailFields, templateName). As I said before the module for PW3 changed a lot and also got an improved Readme. If you still run into trouble, please provide an example which I can reproduce and document (Module settings for the first form and the difference to the second one).

ESRCH beat me to it.

The "remember me" functionality is rather a increase in session timeout instead of a toggle for using sessions or not. $config->sessionExpireSeconds = 86400;

@Nick There's just no way to track a download count without additional fields. And as soon as you need additional fields related to files you either resort to using PageTables or ImageExtra, with the first one being the more flexible solution.

Not sure what you mean; $tagless_images are your images without tags, for images with tags you use: $mytag_images = $page->images->findTag('mytag'); Count does not belong in your if expression: ->has() returns true or false so it doesn't make sense to count it.

Not sure of the cause of that error but if your PW version is >= 2.6.9 you could try the setAndSave method and see if that works.

If you're using that module of mine, you currently need ffmpeg and php-ffmpeg installed to generate poster/thumbnail images. I am planning on adding the option to manually add an image at some point, but it will be much easier if your host has ffmpeg available. As for autoplay, just edit the the play code in the module's config setting. Although I should probably add the ability to pass various options like autoplay via play() If you want to go back to the plain html video tag, it shouldn't be hard to get the path correct. I am not sure this makes sense yet because as far as I know, you need to provide mp4 and webm versions for all modern browser support, whereas with my module and its use of mediaelementjs you can just supply an mp4. On further reading, I am actually not sure of the support for mp4 anymore. It seems contradictory between http://caniuse.com/#feat=mpeg4 and http://mediaelementjs.com/ Are the videos being uploaded via a files field? or manually uploaded to site/templates/video/ ? <?php echo $config->urls->templates; ?>video/voorstelling_orgelpijpjes_2016.mp4 If so, then it should work fine. What is the URL that is shown when you view source?

$tagless_images = new WireArray(); foreach ($page->images as $image) { if(empty($image->tags)) { $tagless_images->add($image); } } Now $tagless_images is a WireArray of images on the page that have no tag. Edit: this is better... $tagless_images = $page->images->filter("tags=''");

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.

Hi ngrmm You probably tried to upload an image that has too many pixels, so your allocated memory to PHP is not enough to process your image. I advise you to get that line back in... Your images will look strange without it at some point. You have two options if my assumption is correct: 1. Increase the PHP memory to the maximum 2. if that doesn't help, shrink your images before uploading them. Hope this still helps

Fantastic looking site, as always!

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.

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 ... }

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

Nice website.

Please don't forget to share the URL once you got this sorted

Welcome to the forum. You should read some tutorials, like this one. http://processwire.com/docs/tutorials/simple-website-tutorials/ In ProcessWire nearly everything is a $page (even users, roles, permissions) If you want to assign more fields to the user template. Create the fields, you need Go to templates. Select Filters, Show system templates Select template 'user' and add any field you have in your system If you want to see the fields in the user profile, you have to add them in the settings of Module ProcessProfile.