Michael Lenaghan

OK, here's my slightly revised `router.php` script: <?php if (PHP_SAPI !== 'cli-server') { die('Expected cli-server'); } if (file_exists($_SERVER['DOCUMENT_ROOT'] . $_SERVER['SCRIPT_NAME'])) { return false; } $_SERVER['SCRIPT_NAME'] = '/index.php'; $_SERVER['SCRIPT_FILENAME'] = $_SERVER['DOCUMENT_ROOT'] . $_SERVER['SCRIPT_NAME']; require $_SERVER['SCRIPT_FILENAME']; The main change is that `$_SERVER['SCRIPT_FILENAME']` is now an absolute path. Not critical, but more correct.

OK, got it. I'm using PHP's built-in web server for development. You can often use it directly, like this: php -S localhost:8080 But occasionally you run into situations that require a router script, like this: php -S localhost:8080 router.php I generally use something like this: <?php if (PHP_SAPI !== 'cli-server') { die('Expected cli-server'); } if (file_exists($_SERVER['DOCUMENT_ROOT'] . $_SERVER['SCRIPT_NAME'])) { return false; } $_SERVER['SCRIPT_NAME'] = '/index.php'; require __DIR__ . '/index.php'; ProcessWire required one additional line: <?php if (PHP_SAPI !== 'cli-server') { die('Expected cli-server'); } if (file_exists($_SERVER['DOCUMENT_ROOT'] . $_SERVER['SCRIPT_NAME'])) { return false; } $_SERVER['SCRIPT_FILENAME'] = 'index.php'; // <== Added! $_SERVER['SCRIPT_NAME'] = '/index.php'; require __DIR__ . '/index.php'; That's because of some assumptions in ProcessWire.php. With that added line url path hooks with extensions now work. (I'm going to hunt around a bit to see if I should make any other changes...)

OK, thank you! It helps a lot to know that it *should* work. I'll keep trying to figure out what I'm doing wrong.

This works: $wire->addHook('/hello', function($event) { return "Hello"; }); This doesn't: $wire->addHook('/hello.txt', function($event) { return "Hello"; }); (Note the `.txt` extension.) I see that in `WireHooks.php`, here, the extension will be removed, because "." will fail the `ctype_alnum` test. But the hook doesn't work even if I comment that block of code out, so that isn't the only issue. This is all rather curious because the original post that introduced url path hooks specifically called out `/sitemap.xml` as a possible use case. Am I doing something wrong? (Btw, curiously, when adding a `/hello.txt` hook, a `/hello.txt` URL doesn't work, but it doesn't produce a 404 either; it produces a blank page.)

I don't know anything about the history of `strtr` in PHP, but my guess would be that the reason it has the ability to replace strings in the first place is simply an extension of its original purpose from single-byte characters to multi-byte. It just so happens that in PHP multi-byte characters are represented as strings… I don't know if that's right, but I've seen it in other languages, so it certainly seems plausible. And when you have that in your head using it to just replace arbitrary strings feels, you know, funny. 🙂

Sorry, I should explain a bit more! `strtr` can work in two modes, and in one mode it can replace substrings. But that isn't its purpose, and I think it would be confusing to use it for that. (It would be especially confusing if, like me, you happen to know about `tr`.) Even more, though: like `str_replace`, `strtr` replaces all matching strings, not just the first. So it can't actually solve the original problem anyway.

@adrian Take a look at the description of strtr: So the purpose of `strtr` is to replace individual characters, not substrings. Take a look at Example #3 to see what I mean. (The `tr` in `strtr` comes from the Unix command `tr`, which does the same thing.)

Issue here, pull request here.

Here is Laravel's implementation of `replaceFirst`; it uses `strpos` and `substr_replace`. I think the current behaviour is unintentional; I don't know if Ryan would consider it a bug? I suppose I should report it so that he can decide.

Just reporting this to save other people some debugging time: Hanna Codes unintentionally "memoize" results. Here's a rough example of what I mean. Imagine a stateful Hanna Code. For example, imagine a Hanna Code that maintains a count, and increases the count each time it's used: [[count]] [[count]] [[count]] You'd expect this: 1 2 3 But you'll get this instead: 1 1 1 Here's where it gets very odd though: your Hanna Code will in fact be called three times, and the counter will in fact end up at "3"! It took me a bit to figure out what was going on. The problem is that all Hanna Codes are extracted up front, here. Then they're processed one by one, here. As each Hanna Code is processed, it gets replaced here. And that's the problem: the replacement is global; all matches get replaced, not just the first. So in this example all three `[[count]]`s will be extracted, and the loop will iterate three times, but the first iteration will replace all occurrences of `[[count]]`, leaving nothing for the next two iterations to replace. (I'm calling this "unintentional memoization" because typically you memoize to avoid work. In this case work isn't avoided, the result of the work simply isn't used.)

The Download page says that 229 is the current master version: Composer and GitHub say that 227 is the current master version: The difference between .227 and .229 is ~8-10 fixes of various kinds.

That is very interesting, thank you! For others: The `setting()` function is defined here. It's just a one-line wrapper around the `wireSetting()` function, which is define here. (`wireSetting()` is a small wrapper around a static var named `$settings`.) Here's the way `setting()` is described: /** * Get or set a runtime site setting * * This is a simple helper function for maintaining runtime settings in a site profile. * It simply sets and gets settings that you define. It is preferable to using ProcessWire’s * `$config` or `config()` API var/function because it is not used to store anything else for * ProcessWire. It is also preferable to using a variable (or variables) because it is always * in scope and accessible anywhere in your template files, even within existing functions. * * *Note: unlike other functions in the Functions API, this function is not related to API variables.* Perfect!

Yes, understood. I was thinking that if there was an official way to do it — like the deprecated example you just gave! — then tools like Tracy Debugger would know about it, and show it. But it looks like the answer to my question is "no!" Thanks, Bernhard.

Thanks, Bernhard. I know about "session scope". I was wondering if there was something similar for "request scope." (Something other than global variables, that is.)

I know that in PHP everything is built up and torn down on each request — so a global variable would be a reasonable place to store a value for the duration of a request. Still: is there a better ProcessWire-specific answer? For example, maybe there's a spot to put such things that debug tools know about?