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.