teppo

@Macrura: thanks for reporting this. A bit busy right now, but I'll take a closer look at that as soon as I can!

I'm pretty sure that I've mentioned this somewhere around here earlier, but I tend to refer to usage statistics when discussing supported browsers. Define a minimum usage percentage ("at least 4%" for an example) and if a browser is below that limit, it shouldn't be too hard to convince the client that it's simply not worth it spending a lot of your time and their money fixing things for browser barely anyone uses anymore.. or, if you prefer to be sure, discuss that with the client beforehand and make sure that it's mentioned in your contract. StatCounter is my current favourite when it comes to things like browser usage statistics; their data seems relatively trustworthy and they offer very good tools for filtering and displaying it (and even allow saving it as an image, exporting a CSV etc. for archiving or whatever other reasons). That's what the statistics from last 3 months look around here. Based on that alone I'd say that it's really not worth it to support IE8 (or 10, which people seem to have pretty much skipped). IE9 is a borderline case, so I'd only offer support for it if it's very important to the client (they're a large organisation using IE9 or have such organisations as clients etc.) .. oh, and did I mention that I just love statistics?

Good to hear that it makes sense (at least after a while). Seriously speaking, should probably start doing screencasts for all the modules.. these things are so much easier to show than explain

Antti: this is intended purely for backend use.. and provides a way for superusers to edit field data. Inputfield seems just about right

Textarea Markup inputfield Loosely based on core module InputfieldMarkup, InputfieldTextareaMarkup works with textareas (FieldtypeTextarea) and outputs plain text, markup and optionally values from other fields in Page Edit (backend). That output can be configured via field settings (Input tab) and then modified on a per-page basis, though only by superusers. For an example this: Hello World, I'm a {{template}}, my ID is {{id}} and my name is {{name}}! Would result in a non-editable (except by superusers) "markup field" with content along these lines: Hello World, I'm a basic-page, my ID is 1001 and my name is About! Content pulled from other fields is sanitised using $sanitizer->text() with default options, so no markup should get through, max length for individual field value is 255 etc. The module is available from GitHub. For more details check out README and/or modules directory page.

This is also discussed in GitHub issues #305 and #421. I've just added another notify to #305, hoping that Ryan will pick it up and re-open the issue.

What version of PW are you using on this site? I tried setting up a matching scenario locally (PW 2.4.2) and couldn't reproduce this issue. It's always a bit of guesswork trying to test something like that without knowing exactly what your code does, how the pages are organised etc. but at least the most basic scenario seems to work for me.

Somehow this sounds like a repeater issue, though I can't quite wrap my head around it -- probably too tired at the moment. I'd still start by making sure that those repeaters really are fine, perhaps re-creating the repeater field itself, and/or making sure that the actual repeater pages under admin (/processwire/repeaters/repeater-field-name/page-name/repeater-item/) are published etc. Wouldn't be the first time that something goes wrong there.

You might want to check out Login Persistent, perhaps that could be of help here? I've no experience of iOS Web Applications and no idea how they work, so this might be completely unrelated too

If you want to know what "Reiska" often means here in Finland, Google Remontti-Reiska and you're getting close. Finnish TV star, media personality, self-taught handyman / construction worker, ex-hockey player, ex-bodybuilder, motorist and a huge person (in more than one way), Remontti-Reiska ("Reiska the Handyman") symbolises all that is good and fair in Finland. I'm not 100% sure about this one, but I believe that the term "remontti-reiska", which is often used to describe handymen and like in general, originated from this guys TV show. (There's also a whole series of YouTube videos of his shows, mostly slowed down to make him and the guy helping him seem drunk -- don't worry about those, that's just Finnish Internet humour at it's finest.) Of course there are other interpretations too, but this is the one I prefer. I think @apeisa mentioned something about this at our last ProcessWire meetup, so he'll probably know better

Thanks for the explanation, Adrian! I'm still seeing this as the complicated route, especially compared to tools like Google Maps or Bing Maps, but if I'll ever have to build a large, commercial service heavily relying on maps I'll be sure to check out other options more closely Regarding the part about caching, take a look at following StackOverflow question: "is it allowed to cache static google maps?" (short answer is "only for a limited time and specific purposes"). It's definitely doable, but if you want to abide by the license, you can't simply save the images and leave it at that ad infinitum.

$pages->count() is used to count pages matching given selector string, such as $pages->count("template=basic-page"). $page->children returns children of given page (PageArray object), not a selector string. You can also use built-in property "numChildren": <?php echo $page->numChildren; ?>

Sorry for taking this somewhat off-topic, but does this service host the actual maps (or map tiles, whatever is the correct terminology here) too, or do you take care of that somehow yourself? Their docs pointed to Mapbox, which seems to provide hosted maps.. probably The reason I'm asking is that last time I checked, I got the impression that there are multiple JS libraries that make dealing with map tiles easy, but I'd still have to get/find/make and host those myself, and apparently each tile needs to be in multiple sizes to support zooming (which seemed kind of weird, since I'd imagine maps being vector images these days, but apparently not). Anyway, the sheer amount of disk space and traffic quota required to host that kind of data seemed downright scary and for someone used to working with Google Maps the whole concept appeared to be very complicated..

@zyON: at that point the original name, one without "pageid_" prefix, is nowhere to be found. Hence you actually need to strip the prefix to get the original name. Take a look at how ProcessWire itself does this when restoring pages from trash: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Pages.php#L1006.

Even if it's unlikely to become a problem here, judging from your use case, I'd like to point out that in addition to this general limit for displaying maps via maps API there are separate limits for things like using the geocoding API - in this case it's 2500 requests each day. MapMarker module, by default, sends new requests to geocoding API each time you move a pin on a map or type in a new address and convert that to coordinates. If your site has a lot of content managers, this limit is surprisingly easy to hit (For one site with a few hundred content managers managing a bunch of maps each I'm running a modified version of the module with an extra option for shutting all these requests down from field settings.. there are still quite a few benefits for the field type itself.)