Mike Rockett

Not sure what's going on here, by CKEditor keeps refreshing and resetting the cursor to the beginning of the first line. As a try to select text or type anywhere, it just takes me to the top and my input goes there instead. I'm using PW 2.8.35. Any ideas?

@Zeka - Surely that will still add html to the page name? I've never tried it, so just making an assumption...

Such a pity to see that a developer chose to procrastinate for eight months developing something with PW. I mean, really? If you're building anything that's even half-interesting, you're bound to have some fun doing it or, at the very least, look forward to building it, right?

Hi Hummer, I don't think that's actually possible using the current way that you're adding the html extension (via page name). I'm not sure if there is another way to do it, but I'm sure that it would involve some htacess trickery and a method to re-rewrite URIs on the frontend. Haven't checked this, but there may even be a hook for this kind of thing... but not sure.

Fascinating how that file works. Given the scale of attackers these days, I'd have expected that file to be somewhat bigger. Also curious to see archive.org in the bad_bot list...

The original setup (still in tact) has Tracy installed, but the new one doesn't. I have it working now on the new setup with my PR code active, but I fear it may not actually work at install-time - I need to test that again. I have also asked Ryan in the PR itself if he caan have a look at this - perhaps he may see something I have missed.

Surely that will automatically send anything that does not have -_.a-zA-Z0-9/~ to http404?

Or perhaps not, If I dump $moduleName from that method, ProcessJumplinks repeats. So I must have a problem with the module - otherwise it wouldn't be doing this.

I think that my PR is actually the problem. Disabling that block of code seems to reduce the amount of memory used and allows everything to continue as normal. I had assumed that the method in question (compile) doesn't get called for every single file, but rather for every module. Is this correct? If not, is there a better way to do what I'm trying with that PR? Also, it seems really odd, because this was working before. No clue why it's all of a sudden giving problems after a few namespace changes (adding \ProcessWire\ to wire() calls).

I have already tried that, it just continues doing the same thing with the upgrade module. For the purposes of not bending my brain too far today, I'm going to move the module to a separate, fresh install and develop on that. As I'm sure someone may have an answer for this, I'll keep the current environment in tact and just won't use it.

Well, I disabled MarkupSitemapXML manually (as that was the module WireFileTools was working with) and then it did the same thing for ProcessWireUpgrade. As such, I doubt that will solve the problem (WireFileTools hasn't touched Jumplinks). Edit: Confirmed - behaviour/error persists.

Right, so I've gone ahead and checked the path that is being worked with by WireFileTools (by means of var_dump($file) at L670), and it keeps repeating this, over and over: ".../site/modules/MarkupSitemapXML/MarkupSitemapXML.module" It does this until it runs out of memory.

Hi guys, I've stumbled into a little problem I'm not sure how to diagnose. Recently, I switched Jumplinks development from a 2.8 env to a 3.0 env, and I missed out on some namespace changes (specifically to wire() and __()). Without realising this, I uninstalled the module to test some changes to the installer, but it threw errors for lines that contained non-namespaced calls. I fixed these and then refreshed (via F5), and now I get this: Not sure what's causing this, or how to check. I have checked that the module is uninstalled, and it does appear to be. Related tables were removed; page was deleted. Any ideas what I can do to solve this? Plus, I picked up on this several times when working on this PR, specifically when there was a small problem with the code that could throw an exception.

Thanks Adrian

Hi Adrian, I upgraded to 3.3.3 this morning, and noticed that the debug bar is no longer adding rows for AJAX requests, which I need to measure. Any idea what may have broken this? Using PW3. Thanks

Ah! Found the exclusions array! $config->fileCompilerOptions('exclusions', [ str_replace('\\', '/', __DIR__ . '/modules/ProcessJumplinks/vendor/illuminate/support/helpers.php'), ]);

Looking at this again, I still prefer to bundle the vendor directory with the module itself. For the most part, I agree, but I can see that it may get confusing for some, and some may not be able to follow the installation steps, for whatever reason. It seems the issue with this is that some files in the vendor directory are not namespaced, and PW appears to be compiling them, and making strange conversions at that. Solving this should solve the problems being faced. For example, one of my dependencies is illuminate/support/helpers.php, which is not namespaced. As such, PW has compiled the file, and made the following conversion: // From foreach (array_merge([$class => $class], class_parents($class)) as $class) // To foreach (array_merge([$class => $class], \ProcessWire\wireClassParents($class)) as $class) This now throws an "unsupported operand types" fatal error at line 369 of the file in question (below), and so I can't proceed: $results += trait_uses_recursive($class); I see that the method makes class_parents PW-aware, but it doesn't need to be, in this case. Is there any way I can prevent the FileCompiler from compiling anything in the vendor directory? I'd like to bundle this directory with the module for now, until such time as Composer is more integrated and can reduce the installation steps back down to the one we all know and love.

Thanks, I'll work with that then.

Of course, you are right - wasn't thinking there. So then your recommendation is to keep dependencies declared in the global composer file (which would mean the only module installation method would be through composer require)? Would have been awesome to have Composer to recursively look through any existing module composer.json files to install their dependencies in the root vendor for inclusion. That way, the module could be installed via any method. If installed by the common method, it would simply mean an additional step of going to the root and running the install/update command. If installled by composer require, then those dependencies would automatically be pulled in through a single step.

Hi Benjamin - thanks for clarifying. I figured that was the case. I'd noticed that some files that were not namespaced don't appear to get compiled. My bootstrapper was one of them. However, I've since removed this file in favor of loading the packages from root vendor and simply using the addNamespace method at the top of the module and config files. I think this is where my problem lies. For me, the normal installation method is preferred, because that is what everyone knows. I think I'm going to pull the vendor directory back in to the module directory and see how to tackle any issues that come up (if they come up again) - I'll open up a new general support post for these. This is also somewhat beneficial as the package dependencies are tied to specific versions, and so I don't want to create potential conflicts for other modules that may wish to use newer versions. I'm thinking the same thing. However, JL2 has many enhancements and speed improvements and, as such, I intend for it to fully replace v1. I also don't want to go down the path of maintaining a master and legacy module, the same way PW is maintained by Ryan. It's possible, of course, but then it means different repos and different module directory listings. That aside, and as mentioned in my post, Ryan has named 2.8 a legacy version of ProcessWire. I do find this somewhat confusing as it has all the goodies PW3 has, and so I wouldn't classify it as legacy. 2.7 should be legacy, and 2.8 should perhaps be called 2.8-compat. Having said that, and given the current state, would it be safe to assume that most people will jump onto the PW3 bandwagon and that I can just say, "If you want Jumplinks, you'll need PW3"?

As you know, I've been hard at work on Jumplinks 2, a complete rewrite of the module. This morning, I decided to develop in PW3 instead of 2.8, and bumped into a whole bunch of namespace-related errors. To fix them, I'm now specifically importing the ProcessWire namespace for things like InputfieldWrapper and wire(). Additionally, the module no longer stores its vendor directory in the module directory as the FileCompiler was converting these as well. Essentially, the module now simply loads the Jumplinks namespace (models, traits, utilities) and relies on the ProcessWire vendor directory, which is created after a composer install, which pulls in the dependencies of Jumplinks. All of these brings up some important questions: The changes made evidently mean that the module will no longer work on 2.8-legacy. Is this a good thing? How many folks will be using 2.8? I know this one is hard to answer, but it is called legacy for a reason, I am sure, and so perhaps there is no harm in not supporting it... Which brings me to: Is it right to only allow compatibility with PW3? From what I've read, am I right in saying that if I declare the module dependencies in its own composer.json file, Composer will install those dependencies in the ProcessWire vendor directory? Having done this my side, it appears to work (that is, the dependencies are pulled in as expected) - but my main question is this: will the module still work via the normal backend installler, or will it only work through composer require <vendor>/<project>? I really like that namespace support has been added to PW, but I think it's caused a bit of confusion for me. My ultimate goal was to ensure compatibility with 2.8 and 3.0. Perhaps I'm going about all of this incorrectly, but I think it is right. The module file itself resides in tht root or ProcessWire namespace and imports the Jumplinks namespace from src/Jumplinks/*. It then has dependencies stored in the root vendor directory. Does this look like a good picture? Is there a better way to do it? Perhaps I was wrong to develop in 2.8 first, not realising what could go wrong with 3.0... Advice on this would be most-appreciated - hoping there's a way to ensure compatibility and allow installation via any method.

Then I'm afraid I'm not sure what the problem is. I use the same hook and rul 16b for Jumplinks 2, and it works. Is your specific problem that your hook404Page method doesn't get triggered at all?

Just to confirm did you uncomment this rule? RewriteCond %{REQUEST_URI} "^/~?[-_./a-zA-Z0-9æåäßöüđжхцчшщюяàáâèéëêěìíïîõòóôøùúûůñçčćďĺľńňŕřšťýžабвгдеёзийклмнопрстуфыэęąśłżź]*$" Also, you don't need to restart Apache when changing htaccess files; you only need to restart if you have changed a configuration file, such as httpd.conf or a virtual host file.

You need to enable UTF8 URIs in your htaccess file. I assume you are using ProcessWire 2.8 or 3.0, and so you can simply comment out rule 16a and uncomment rule 16b (if I'm not mistaken). This should enable the URIs you would like to use.

Indeed. I think the big thing for me is to let the table show that something is being loaded as well - a feedback mechanism is always good.