adrian

Variables declared in _init.php are available in all templates, but php scoping rules still apply when trying to access a variable inside a function. Remember, even if you tried to access $body (defined in _init.php) in a function elsewhere in _init.php, you still wouldn't be able to.

Does this work? $p = $this->storagePage; $p->of(false); $p->pdfStorage_files->add($path); $p->save('pdfStorage_files'); return $p->pdfStorage_files; Not sure if your problem is the missing $p->of(false) or trying to save the $files pagefile object instead of the "pdfStorage_files" field name. PS - what @Robin S said

I think it's just about PHP variable scope. When you use PHP's built in "include" it is including the contents of the file directly, but when you call a custom function to do the include (eg wireIncludeFile(), or your own custom function), then the $body variable doesn't make it through, which is why wireIncludeFile() and wireRenderFile() have the ability to pass variables in an array.

Well, it's been a long time coming, and not sure if it's exactly what you had in mind, but I just added a new "Git Info" panel that displays Git branch, latest commit message, etc for your site (assuming you have it under Git version control). This is just the first version. My goal is to add color coding of the icon (like many other panels) to get your attention. I am looking for feedback on this though. I could either make it possible to configure different colors for different branches, or else I could try to match the branch name against the subdomain / extension, eg. dev.mysite.com, staging.mysite.com or mysite.dev, mysite.staging, etc and color green if they match and red as a warning if they don't. Anyone have any thoughts on the best approach? On another note, I just had to do quite a bit of work fixing the "Versions List" feature on the ProcessWire Info panel - two recent Tracy core updates broke this functionality and I just noticed. Also, it looks like Github changed the way they handle line breaks inside <details> tags, so also had to tweak that, but I think everything is working again now!

What @LostKobrakai said, but if you really want to do it, you can make use of these in the module info: 'permission' => 'page-view', 'permissionMethod' => 'permissionCheck', permisssionCheck() may look something like this: public static function permissionCheck(array $data) { $user = $data['user']; $wire = $data['wire']; // if in admin/backend, then require "my-custom-permission" permission if(strpos($wire->input->url, $wire->config->urls->admin) === 0 && !$user->hasPermission('my-custom-permission')) { return false; } // else in frontend, so allow full access to call actions via the API else { return true; } }

Yes, adding the namespace is the "correct" way to do things with PW 3 when starting new projects. The file compiler was built primarily as a way to facilitate easy upgrades from PW 2.x without needing to change any files, and also to support non-namespaced modules in PW 3.

So what is happening there is that the file compiler is kicking in when you haven't manually declared the namespace. The file compiler turns: include($config->paths->templates . "views/{$page->template->name}"); into: include(\ProcessWire\wire('files')->compile($config->paths->templates . "views/{$page->template->name}",array('includes'=>true,'namespace'=>true,'modules'=>true,'skipIfNamespace'=>true))); The PW compile method is converting that path and adding the .php extension. You can test it yourself: Anyway, I don't think you should rely on the file compiler to do that - either add the extension, or use wireIncludeFile()

"include" is pure PHP - it knows nothing about ProcessWire templates and presumed extensions, so you must point it to a valid filename with its extension. Maybe you are thinking of "wireIncludeFile" - https://processwire.com/blog/posts/processwire-2.5.2/#new-wirerenderfile-and-wireincludefile-functions

If you like one liners and it fits with the style/logic of code you are using, this will work: $out .= "<figcaption>" . $page->image->get("description".($user->language->isDefaultLanguage ? '' : $user->language->id)) . "</figcaption>";

Had you changed the rewrite base in the old .htaccess ? Do you have debug mode on to see possible errors?

Hey @Robin S - I just wanted to remind everyone how awesome this is It can reduce the number of required templates (and template files) substantially in some cases where you have a standard setup, but with some minor differences to the fields in each template. Of course you could take it to extremes and have just one template per site, so you need to be careful to find the right balance, but it's a really powerful addition to PW IMO. Thanks again!

When Migrator and MigratorWordpress were written, there was no system "published" field in Processwire. There is now, so I just pushed updates to both modules to support writing to that system field. Unfortunately untested at the moment (no time today), but hopefully will work as expected. With that in place, you should be able to delete that "date" field if you wish and use the "published" field to get the same information. Cheers, Adrian

I am running PHP 7, so don't worry about that. I am running the latest PW dev 3.0.57, but I doubt there'd be an issue in 3.0.42, but maybe worth checking. Did you go with standard MyISAM and UTF8 in your MySQL database? I don't think this should be an issue either, but just something to check.

That pages find works here. Not sure why it's not working at your end. What version of PW are you running? Anything unusual with your server setup that you can think of?

Good tip @Can For those interested, here is the blog post about sanitizing directly with $input: https://processwire.com/blog/posts/processwire-2.6.14-brings-major-enhancements-to-sanitizer-and-input-api-variables/#sanitizer-and-input-are-now-a-couple

Just do: $user = $users->get("email=".$input->post-email);

@depone - I am still not the most experienced at multi-language stuff, but this will work: $page->images->first()->get("description".$user->language->id); This way you are explicitly stating that you want the description in the user's language with no fallback. Maybe someone else has another solution?

You can use this to check if it's not the default language and only display description in this case. if(!$user->language->isDefaultLanguage) { // display description }

Just added a new "Clear Session & Cookies" button in the ProcessWire Info panel: It's the new reset/reload looking icon. This will log you out and back in again, clear all cookies for the domain, and return you to the same URL you were on (along with the full query string). I have been finding this very handy with module development when it is manipulating parts of the admin that are cached (like menus etc), but it can also be handy for example when you change an Images field's "Default image grid mode" setting because you need to clear cookies to see these changes. I am sure you'll find other uses as well.

Hi @godmok - thanks for the report. Unfortunately I am having a trouble understanding exactly what the steps are to reproduce this. Is there any chance you could share a screencast of the problem in action? Also, might I have access to the server (if it's online) so I can test - although I think the screencast first still might be important. I don't think I have ever come across anything like this. Anyone else ? Hopefully we can get to the bottom of it though and get it fixed.

Hi @MilenKo - sorry for the silence of late - too much going on here. I just pushed some changes I made earlier in the week that should fix the comment datetime issues. When I get some more this week I'll take another look at the tags issue. Thanks for your patience!

There is no Users::added hook. Since users are pages, what you are doing looks to be the correct option.

Files should only be recompiled if their contents have been changed.

Looks and works great now - thanks!

I think the key thing is that when there is no position stored in LocalStorage, it should use the field's width setting (default or template context override) as it did before. Yeah, something like that sounds good.