teppo

$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.)

Quick search for this particular error from the forum returns one thread: https://processwire.com/talk/topic/5361-apache-recursion-problem/. I'd start from there.

@Stefan: error message itself is a sign of CSRF check failing. Are you seeing this error before or after login attempt, i.e. can you still type in your login credentials and this just appears after or are you unable to see the login form in the first place? It's possible to skip CSRF checks entirely by adding "$config->protectCSRF = false" to your site/config.php, but I wouldn't recommend it in the long term -- this is a security feature after all. There are also some things you could try here, such as checking that you've got necessary directories, as discussed here. Please let us know if the issue persists. Providing any additional info (such as is there anything that could've caused this, any apparent change to your site lately, have you switched servers etc.) could also help diagnosing the issue.

Why aren't you just adding template file to each track and in there rendering the lyrics? Your modal link could point to the URL of the track page itself and then you'd just need some simple JS to open that as a modal window (or popup, whichever it is that you want). .. and if you need to stick with current structure, you'll have to append track ID or some other method of identification to each modal divs id attribute (such as id="lyricPopup1234" where 1234 is ID of track page) and matching ID to each modal link (data-reveal-id="lyricPopup1234"). Based on your attributes there I'm assuming that you're using this plugin. They've got pretty good instructions for using the plugin, so please take a closer look at those first. Edit: just saw what Soma posted in your other thread about this. Makes sense. Just stick with what you've got here

Wait, there are other editors besides Emacs?

I've been thinking about something along these lines too, though more like "custom module paths", i.e. an option for adding multiple module locations. Either way this would be nice

@Pete: not saying that it would be a bad idea, but there are benefits to separate site too. First thing that comes to mind is that external sites with PW focus may actually make us look bigger (not that size would really matter, you know), but this could also promote healthier ecosystem; if there are existing sites that focus on PW topics, it's much easier to setup one of your own, which IMHO benefits the project itself in the long run. All in all I'd love to see more diverse ecosystem and don't think that we should attempt to gather everything in one place.. apart from the things it makes a lot of sense for, such as the modules directory, of course

Awesome idea -- there's definitely demand for this. Please keep us posted on your progress! Seems like you've already got some great ideas there too. Might want to cover various caching settings and modules too, and of course classic tasks like "how do I create tags in ProcessWire", just to add something

I'm assuming that this is a front-end form and submitted values are somehow converted to pages and/or page data. If that's really the case, those values really need to be sanitised when submitted, but including HTML Entity Encoder textformatter is still a good idea as an additional precaution -- unless, of course, your field has to be able to contain HTML. For sanitising user input $sanitizer->textarea() is one option, other one being $sanitizer->entities(). First one strips tags but leaves entities intact while latter encodes all entities, including "<" and ">": $foo = "<b>bar</b>"; echo strip_tags($foo); // outputs bar echo htmlentities($foo) // outputs <b>bar</b> This pattern you've mentioned is probably a front-end thing? In that case it can be used as a way to signal to users what kind of values are valid, but you should never really trust it; it's very easy to circumvent things like these. Note: you could probably just add a space in your pattern, like [a-zA-Z ], to make it support those. I'm not sure if this makes sense, though; user still wouldn't be able to type in dots, commas, lines, underscores, non-ASCII characters etc. etc. This method seems complicated and prone to errors, so I'd probably skip it altogether, relying on the server side sanitation instead.

To be honest I'm not really sure what you're trying to achieve here, but what I'd probably consider (without fully understanding your situation, so this might be completely off!) would be serving the page user is asking for without current "render home page if this isn't an AJAX request" trick. This way there shouldn't be any caching issues and as an added "bonus" all sorts of crawlers, users with JS disabled, screen reader users etc. could still use your site. Assuming that pages requested via AJAX (using this clientside routing you mentioned) can be directly mapped to "real pages" by their URLs (and are, in fact, identical to those) I can't see what the problem with that approach would be. Unless there's something on your home page that is required for the rest of the site to work properly, i.e. other pages actually only contain part of what the user should end up seeing, in which case I'd consider fixing current template structure to take care of that by including common header/footer files etc. if the request isn't AJAX. Anyway, I'm sure we could come up with various tricks to enable caching here (been there, done that) but first I'd really like to understand why this is even necessary in the first place. There's probably a reason, I'm just not seeing it right now

You'll probably want to make this module (if it's not already) a Process module. ProcessHello is an example of this module type; they're essentially modules that add a page of their own, usually under admin, and use that to handle incoming requests, whether GET or POST (and respond to those accordingly). Depending on your use case it might make sense to bundle "regular" hooking module and Process module together, so that the module attaching hooks doesn't need a page of it's own and the Process module isn't loaded unnecessarily before it's really needed. Not a huge difference, but just wanted to mention this option. In some cases this can also make the module "architecture" more sensible, separating different types of features. As a concept this is very close to controller actions, really; in Zend Framework I'd have IndexController with methods indexAction and actionNameAction, in ProcessWire I've got ProcessMyModuleName.module with methods execute (requests to the initial URL of that page, same as indexAction in Zend Framework) and executeActionName