adrian

Hey @kongondo - note the Page within each Matrix item. Each one of these contains a full reference to the current page. This comes from dumping $page->matrix_field Here is the dump of $rows and $columns from the export function. You can see that each row is a full PW page object. Is this expected?

This should work: wire()->addHookBefore("ProcessLogin::executeLogout", null, "setRedirect"); function setRedirect(HookEvent $event) { $event->object->setLogoutURL(wire('pages')->get('/')->httpUrl); }

In repeaters: and if you need it for PageTable, @Robin created this: http://modules.processwire.com/modules/limit-page-table/

Some more thoughts on this - I wonder if maybe it's just best to turn on output formatting - that should handle getting the language for the current user. On an unrelated note, I noticed that each entry in the matrix is a full PageArray - is this necessary? I haven't looked into/thought through this, but it seems like a lot of info to have in memory when all we need is a single value with its relevant row and column page ids. Maybe the full PageArray is needed, or maybe it doesn't matter - just thought I'd ask

That's an entry from the "caches" DB table so you can either empty that table, or ignore if the error didn't prevent the other tables from importing.

Ok, I figured it out and have a quick fix in place. It was a multi-language issue. This is my quick fix - to get the default row and column titles, rather than returning a title object. //prepare export values foreach($rows as $row) { $rowTitle = $row->title->getLanguageValue("default"); //only export selected rows if(!in_array($row->id, $rowsChecked)) continue; foreach($columns as $column) { $columnTitle = $column->title->getLanguageValue("default"); //get each matrix value at given coordinates (WireArray) $v = $values->get("rowLabel=$rowTitle, columnLabel=$columnTitle"); $value = $v ? $v->value : '';//force blank values export $exportMatrix[$row->id][$this->_('Row Label')] = $rowTitle; $exportMatrix[$row->id][$columnTitle] = $value; } } Not sure if you want to implement just like this, or whether you think it's worth adding a more complete ML solution. PS - what about changing "Row Label" to the title of the parent page of the first column. In my case I have a page branch of Years to control this column. It would be much nicer if this read "Years" or "Year". Would that work, or are there more things to consider?

Hey @kongondo - I just went to export for the first time and noticed that all I get is the first column entitled "Row Label". Is there something I am missing, or is this a bug? I need this pretty urgently (actually immediately), so I am going to take a look and see what I can figure out, but in case you happy to be online and have an idea for a solution, or something I am missing, that would be great

It should work if you do this: $buildings = $pages->find("template=building-entry"); $allTowns = $buildings->explode('addressBuildingTown'); $uniqueSortedTowns = sort(array_unique($allTowns)); IIRC this notice is new to PHP 7. Google it and you will get some explanations as to what's going on. EDIT: Oops - not sure when you made your edit to show what works, but somehow I didn't see it

Thanks for the explanation and for the "Grant Field Access" config option. I definitely see your logic behind treating access the other way around. I guess I was just considering the situation where you have a regular web site where you want to be able to use the PW API as well as GraphQL. In this situation I would have no problem with all fields being accessible, so great that option is available!

Fantastic video @Nurguly Ashyrov - really well put together and great English - I don't know how you come across so clearly given that you haven't spoken it in 6 years! I am really excited to start using this module. The one thing I noticed which seemed a little weird to me was that by default the skyscraper-editor (or guest) user didn't have access to fields until you enabled field level access control and explicitly gave them view access (~35:10 min mark in video). By default in ProcessWire, anyone can view a field if field level access control is turned off. Only once it is turned on are any restrictions applied. Does that make sense, or did I misinterpret something? Thanks again - this is going to be so very useful!

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