LostKobrakai

Or without all those parenthesis: $page->set('siteviews', $page->siteviews ? $page->siteviews + 1 : 1); Edit: Scratch that. null + 1 does work without error notice: $page->set('siteviews', $page->siteviews + 1);

That's the issue. You cannot bootstrap pw, when it's already running. Also starting the pw instance again would be a waist of computation anyways. <?php namespace Site; $config = \ProcessWire\wire('config'); [your defines]

And the file is called via the cli or other external way? I mean $config should get defined in the index.php, as long as it's not run as part of a direct webrequest. I've just tried this on a local installation and there's no problem: <?php namespace Site; require_once "index.php"; echo $config->urls->templates; Also as long as we're talking about variables and not class/function calls the namespace can't be the issue, as it's not affecting any variables.

Are you sure the require is correct? Bootstrapping pw does make all api variables available as local variables and that behavior hasn't changed in pw3.

Could you supply the relevant parts of the whole file, e.g. the head part with namespace and use declarations and the part which is failing?

The error is about a missing SITE_DIR constant, so not sure, why you think this is related to the wire() function.

Caches are simply not meant to be used in development environments (other than testing if they work) and anything else I'd consider mis-usage. I think a sane solution could be a CLI script which watches the template/pw folder for file changes and, on such an event, does trigger the cache to be cleared.

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.

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. 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.

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.

I think i'd probably go with this in the regex (if it's not for historical data) (1|2)\d{3}-(1|2)\d{3} For something like a blog there's hardly need for years before 1000 and beyond 2999

The processwire admin is using jquery all over the place, so why not use it if it's already there.

You probably did not replace the whole wire folder, but only replace existing files, because JqueryFancybox is no longer part of ProcessWire.

I'd really like to see that in the core fieldtype.

Part 2 is probably because visibility settings are evaluated in js only, which ultimately doesn't know anything about the setting of the field.

$options = <<< _END value|Title value2|Title2 _END; $newField->type->manager->setOptionsString($newField, $options, true);

Sure, there are just no database backed constraints. The benefit of building a custom frontend is also the biggest drawback: It's custom. In the backend you can harness a lot of already existing functionality, which works if that's how you need to handle things, but might get messy if you need to work against it almost everywhere.

ProcessWire plainly doesn't use database constraints at all (Foreign key constraints are not available for MyISAM). Those need to be handled in you application logic / by processwire's logic.

The reason for this is explained in the "code internationlisation" docs page. Small hint: It's because of the parser and the ability to have comments for translation on the same line.

That's not possible with the processwire selector engine, as datefields are stored as timestamps and there's no abstraction around the mysql date functions which would allow comparing only day and month.

You could try to add your current hook from a hook to ProcessPageEdit. This way it'll only get added for the page you want the button to be hidden.

$event->object is the object the hooked function lives on, in this case: A InputfieldPageTable object. $event->arguments does also have nothing, which garantees you to return a page object. This does hold the parameters, which are passed into the hooked function. Can be a page, but can be all sorts of other things. In your case there aren't any parameters to the render function. @tpr Mentioned another incorrect option, because getPage() is just a convenience function to retrieve the page if you're hooking ProcessPageEdit. Other hooked objects most often do not implement such a function. In the case of InputfieldPageTable you might be out of luck, because it's best practice, that inputfields do not need to know anything about the page they live on. They just need to know the value to work with. Only the fieldtype does need to be aware of the page itself.

I think short-term mostly the module development will benefit from the composer addition. No need to pull in symfony/console for multiple modules with cli interface, when once would be enough. The new jumplinks module will be built by using the popular nikic/fast-route package. There are lot's of popular packages to support filetypes like excel or pdf (Pages2PDF uses mpdf), which can simply be pulled in by using composer. Version constrains allow each of those dependencies to be independently updated (e.g. security fixes) without the module author necessarily being involved.

What i posted is essentially the same as downloading processwire manually. There's not much more to it. It would automatically install any dependencies, but there aren't ones for processwire.

I'm not sure, but isn't this more what people might be looking for when creating a new project: composer create-project processwire/processwire Otherwise processwire will be pulled inside the vendor folder, where it's from questionable use besides for being bootstrapped into other applications.