PW 3.0.35: ProcessWire 3 master and changelog

[ryan]

Last week we called it a soft launch, but this week we'll say ProcessWire 3 is now released and considered our new master, version 3.0.35. This post is a changelog of sorts, where we will cover all that's new in ProcessWire 3!

https://processwire.com/blog/posts/pw3-changelog/

[arjen]

Superb work and so great many improvements. While I read all the blog posts I can't even remember them all, like the multi language improvements. Thanks Ryan (and the rest of the team) for the great work.

[elabx]

True happiness!! And today Vue 2.0 was released too, Destiny are you trying to tell me something?!

Thanks everyone for the amazing work, I keep enjoying developing with PW like in no other system.

[Robin S]

When you see all the new features listed together and consider the short amount of time this has happened in it's really impressive. Thank you Ryan, and thanks also to the other contributors to the PW core.

[Mike Rockett]

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:

1. The changes made evidently mean that the module will no longer work on 2.8-legacy.
   1. Is this a good thing?
   2. 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:
   3. Is it right to only allow compatibility with PW3?
2. 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.

Edited October 1, 2016 by Mike Rockett
Composer dependencies are pulled in

[LostKobrakai]

The file compiler is ultimately only meant for handling legacy modules/templates in pw3. If you're using custom namespaces and you want to be compatible with 2.8 and 3.0 you need to do a bit of manual work to differ between namespace and non-namespace processwire functions/classes. The file compiler will skip any file with a custom namespace and will only work on non namespaced files. So if you're referencing processwire classes only in a non namespaced jumplinks.module your fine, but if your custom classes (Jumplinks namespace) do also reference those, then the file compiler won't do anything for these files and you need to handle the namespace differences on your own.

The composer dependencies will most likely only be installed by composer require some/module, because processwire has no knowledge of a eventually installed composer package. If you choose composer to handle dependencies it should probably be done completely by composer. But maybe someone can make a GUI for composer (via exec/system). I've a npm package which does temp. install composer to pull in a package, so it should be possible with enough access rights.

I think you're in the nice spot of having a working module. I'd simply go for 3.0 support with jumplinks 2 and leave the first version for anyone else.

[Mike Rockett]

Hi Benjamin - thanks for clarifying.

1 hour ago, LostKobrakai said:

The file compiler is ultimately only meant for handling legacy modules/templates in pw3. If you're using custom namespaces and you want to be compatible with 2.8 and 3.0 you need to do a bit of manual work to differ between namespace and non-namespace processwire functions/classes. The file compiler will skip any file with a custom namespace and will only work on non namespaced files. So if you're referencing processwire classes only in a non namespaced jumplinks.module your fine, but if your custom classes (Jumplinks namespace) do also reference those, then the file compiler won't do anything for these files and you need to handle the namespace differences on your own.

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.

1 hour ago, LostKobrakai said:

The composer dependencies will most likely only be installed by composer require some/module, because processwire has no knowledge of a eventually installed composer package. If you choose composer to handle dependencies it should probably be done completely by composer.

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.

1 hour ago, LostKobrakai said:

I think you're in the nice spot of having a working module. I'd simply go for 3.0 support with jumplinks 2 and leave the first version for anyone else.

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"?

[LostKobrakai]

41 minutes ago, Mike Rockett said:

I do find this somewhat confusing as it has all the goodies PW3 has, and so I wouldn't classify it as legacy.

It's legacy, not because it would be "old code", but because it's not supposed to be used for any new projects. It's there, so that people can use new features even for existing projects without the need for a big code rewrite.

47 minutes ago, Mike Rockett said:

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.

It's not how it works. You cannot have multiple versions of a library running in parallel. There's just no "sandbox this just to be used by my module" in php other than packaging everything in your own namespace. FastRoute\Dispatcher will always collide with another FastRoute\Dispatcher class, no matter where those are stored. Having the dependency installed by the "global" composer.json, instead of packaging it inside your module, at least gives the user of your module the ability to try to resolve issues without hacking your module / breaking the update path.

[Mike Rockett]

36 minutes ago, LostKobrakai said:

FastRoute\Dispatcher will always collide with another FastRoute\Dispatcher class, no matter where those are stored.

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.

[LostKobrakai]

Yeah I think that's the most clean approach currently, even though I'm still not sure about the consequences, like your concerns above. In the end it comes down to the fact, that people are more often supposed to work with composer, which might not be a bad thing, but still a barrier to entry.

[Mike Rockett]

1 minute ago, LostKobrakai said:

Yeah I think that's the most clean approach currently, even though I'm still not sure about the consequences, like your concerns above. In the end it comes down to the fact, that people are more often need to work with composer, which might not be a bad thing, but still a barrier to entry.

Thanks, I'll work with that then.

[Mike Rockett]

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.

[Mike Rockett]

Ah! Found the exclusions array!

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

[Jonathan Lahijani]

Given that the ProcessWire Upgrade module has been updated as well, shouldn't it be able to upgrade an installation that's on 3.0.33 (for example) to 3.0.35?  It seems to not detecting the latest version.

[adrian]

7 minutes ago, Jonathan Lahijani said:

Given that the ProcessWire Upgrade module has been updated as well, shouldn't it be able to upgrade an installation that's on 3.0.33 (for example) to 3.0.35?  It seems to not detecting the latest version.

You'll probably need to log out - that module only checks for new PW versions when logging in: https://github.com/ryancramerdesign/ProcessWireUpgrade/issues/10

[Macrura]

7 hours ago, Jonathan Lahijani said:

Given that the ProcessWire Upgrade module has been updated as well, shouldn't it be able to upgrade an installation that's on 3.0.33 (for example) to 3.0.35?  It seems to not detecting the latest version.

i was able to get it to work, but i had to change all of the file locations that are hard coded into the module; i changed them to the new repo and then it worked.

If there is some way to upgrade from .33 to .35 using the upgrades module, i'm interested in knowing; otherwise i was assuming that ryan had not yet gotten around to updating those locations in the module code.

[adrian]

 

16 minutes ago, Macrura said:

i was able to get it to work, but i had to change all of the file locations that are hard coded into the module; i changed them to the new repo and then it worked.

If there is some way to upgrade from .33 to .35 using the upgrades module, i'm interested in knowing; otherwise i was assuming that ryan had not yet gotten around to updating those locations in the module code.

Did you upgrade the upgrades module first? It's working here!

[szabesz]

3 hours ago, adrian said:

It's working here!

+1

[matjazp]

11 hours ago, adrian said:

You'll probably need to log out

That's the key! And of course Upgrades module has to be updated first to version 0.0.7 where Ryan modified the sources.

[Tom.]

Great work everyone! PW3 looks great!

[AndZyk]

Thank you for this amazing release. 

I follow this project since 2.4.0 and the amount of features added since then is just terrific.

Hopefully PW3 will attract many more people. Maybe a new shiny website will help, but I already know, that this is on the list.