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?

I’m not quite sure that I understand the purpose of ‘upload_dirs’: That’s from https://ddev.readthedocs.io/en/stable/users/install/performance/#mutagen-and-user-generated-uploads. I think it isn’t really about uploads at all, but rather directories that might be better off with a slow-but-sure sync rather than a fast-but-eventual sync? If that’s right, when would you actually need something like that — especially in the context of uploading? Does anyone have a feel for this?

I logged an issue for this: https://github.com/processwire/processwire-issues/issues/1908 Take another look at the `textarea` element: <textarea ... name="body" ... required="required" ... style="display: none;"></textarea> It's marked `required`, but it's also marked `display: none`. TinyMCE fields have a complex structure, and that complex structure is preventing the `required` attribute code from working correctly. Ultimately, TinyMCE fields shouldn't let users check the "Also use HTML5 "required" attribute?" option.

OK, I think I found the problem; you can't set "Also use HTML5 "required" attribute?" on a TinyMCE-based `textarea` field. In other words, don't check this box:

That error was in Safari. I'm seeing the same error in Chrome. In Firefox, I'm seeing the same error, and it's followed by many more, e.g.: An invalid form control is not focusable. The invalid form control with name=‘whats[]’ is not focusable. The invalid form control with name=‘_whats_add_items’ is not focusable. So: not a browser-specific issue.

I'm having frequent problems saving pages in a brand-new ProcessWire site I'm creating. (I'm using ProcessWire 3.0.227.) The problem is that I fill out the page, hit either "Publish" or "Save + Keep Unpublished" — and nothing happens. Specifically: the page isn't saved. And no message is shown. Looking in the JavaScript console, I see this error: An invalid form control with name='body' is not focusable. Looking through the HTML, I do in fact see a control with that name: <textarea class="FieldtypeTextarea required uk-textarea InputfieldTinyMCEEditor InputfieldTinyMCENormal InputfieldMaxWidth InputfieldTinyMCELoaded" id="Inputfield_body" name="body" rows="15" required="required" aria-hidden="true" style="display: none;"></textarea> But the error message isn't saying that a control doesn't exist, it's saying that it's "invalid" and/or "not focusable." I'll keep trying to figure out what's happening, but if you have any ideas, please let me know!

OK, thanks for that!

I created a `Fieldset (Page)` field with two fields, a start year and an end year. Is there some way to add validation that guarantees start year <= end year? (If, that is, they're specified at all; both fields should be optional.)

Thanks. And sorry; I should have done a better job of searching. Increasing memory_limit to 256M allowed me to add the ~48MB file. Increasing it to 384MB allowed me to add the ~88MB file. For posterity: When the limit was 128M there were errors in the Apache error log. When it was 256M there were no errors, but the ~88MB file didn't quite finish uploading.

I'm converting a Drupal site that has many mp3 files. Two of those files are a bit large; one is ~48MB and the other is ~88MB. At first they wouldn't upload at all; ProcessWire said that they were larger than the 40MB upload limit. I changed two entries in php.ini: post_max_size = 100M upload_max_filesize = 100M After that ProcessWire seemed to upload the files--but after uploading they always disappear. In other words, I drag the files, I see the upload progress bar, the upload completes (i.e., hits 100%), I hit Save--and the files disappear from the list. What am I missing?

If anyone else is looking for a quick fix pending a final fix, this is also an issue: /** * Initialize the date/time inputfield * */ public function init() { ... $this->set('dateInputFormat', self::defaultDateInputFormat); $this->set('timeInputFormat', ''); ... If both instances of self::defaultDateInputFormat are replaced with '', or if the value of the const self::defaultDateInputFormat is replaced with '', time-only fields work as expected (and date-only and datetime fields are unaffected).