Michael Lenaghan

It does. To test I: Renamed the module directory Changed the version number in the module files to force an update Updated the module The update used the original module directory name, and didn't overwrite my changes in the renamed directory. So: renaming the module directory might work. It's slightly wonky — there were some issues — but it might work. Thanks, @adrian, for nudging me in the right direction; I knew about the mechanism, but thought it was only for forking core modules!

Yes, thanks, I knew about that. It works in one sense: but not in another: It lets you choose one version of the files or another, but it knows they're both actually `TextformatterHannaCode`. So if `TextformatterHannaCode` were ever updated, and if I or someone else clicked the "upgrade" link, maybe the update would overwrite my changes.*** That seems kind of obvious, so just to clarify: what I was hoping was that I could break the link between the name and the repository. You could imagine that might work if, for example, there was a GitHub URL stored in the module config; I'd change the URL to point to, say, a fork of the original repository. But in fact I think the name is used to look up the module in the module directory — and *that* is where the GitHub URL is; for example: https://modules.processwire.com/export-json/?apikey=pw301&class_name=TextformatterHannaCode So: I think that to *actually* fork a module you have to change its name everywhere. === ***I'll see if I can figure out if that's true. Maybe, for example, the upgrade link uses the *original* module directory name?

I've been using `FieldtypeMapMarker`. I'd like to fork it. Is there a right way to fork a module that's already in use? Is there a wrong way? ? If I just modify the files in place without doing anything else they could get overwritten by the `ProcessWireUpgrade` module if the upstream module ever changes. If there's no right way, I presume I have to: copy the directory, change some names, install the new module manually, copy all of the old module fields to the new module fields, uninstall the old module... something like that?

OK, sorry for the noise, I figured it out. But oh my goodness, it's subtle! Editors can only edit *unpublished* stories: That is, I suppose, because they don't have the "page-publish" permission. That's excellent, it's what I actually want, but as I said: oh my goodness, it's subtle!

Yet another screenshot; this is from the Settings of the story that was shown above, "Half a bed better than none?". This agrees with what the Page Tree is showing me. It just isn't what I expected given what the Template is showing me.

One other possibly relevant screenshot: That's from the "story-item" template. Authors should have the ability to edit, and that ability should be restricted by "page-edit-created". Editors have "page-edit" and not "page-edit-created", so they should have the ability to edit *any* page. But they don't. What am I misunderstanding?

I'm working on a site that's expecting lots of "authors" who create "stories". A smaller number of "editors" will then edit the stories. An even smaller number of "publishers" will then publish the story. Given that, I've created three roles: "author", "editor", "publisher". Authors can only edit their own stories. (They have the "page-edit-created" permission.) Editors should be able to edit *any* story. That's what I think I've set up: but that's not what I'm getting: The first screenshot is from the "editor" role, the second is from a test user in that role. Note that the test user can't edit that story, they can only view it. So it seems I'm not understanding something about how permissions and roles are supposed to work. Any idea what that might be? (Btw, the "publisher" role is able to edit anything on the site. That's defined in and inherited from the root, from the home page. That works! But I don't want "editor"s to be able to edit anything on the site, so I can't rely on inheritance for that role.)

I can't find an Edit for the whole post, just for my individual posts. And when I click that Edit it takes me to a page where that post is the only thing I see; there are no replies. ... I just did some searching. This Invision post says that the feature has to be enabled in each forum. This Invision post says that there was a bug causing email notifications to be sent out asking people to Mark as Solved when the feature was not enabled. (Fixed, maybe?) This is a post from here where someone asked the same question (sorry, I thought I searched!) and you asked the person to edit the title and add "[Solved]". So I think that's what I should do?

I'm getting emails from the forum that say: If there is such a button, I promise to mark the answer that tells me where it is, because I can't find it. ?

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?