adrian

Same method to update existing values - it will just overwrite the cell that matches the row/column values.

I haven't used the API with Matrix in a while, but if you read a few posts above yours, there is some discussion about the makeBlankItem() method being a new PW core requirement. @kongondo said he would implement it, but it doesn't look like it made it into the master or dev branch. I think if you add it yourself (as per the discussion), it should work as expected. As for using the Table module to automatically create columns, I think that will be a lot more work than you might initially think - lots of things to handle if things need to change.

Is it a namespace issue? Try: $matrix = new \Matrix(); Otherwise, what's error?

We should end our OT ishness ? but there are other similar shortcuts in that panel as well - worth keeping open and seeing what it offers up in various parts of the PW admin. Let me know if you have any other suggestions for features for it.

I generate and populate the matrix field via the API without any problems. Something like this: $matrix = new Matrix(); $page->of(false); $data = array(); foreach ($xs as $k => $v) { $data[$col->id][$row->id] = $v; } $matrix->addMatrixData($page, $matrixFieldName, $data); $page->save($matrixFieldName);

Or in this case you could just use Tracy's Admin Tools panel which has a one-click "delete field" button when viewing a field's setting in the admin ? PS - not meaning to be a downer on your module in general, it's just not necessary for this use case.

I think that should work, but your if statements are missing the closing ")" You have: if($user->hasRole('competition-secretary') || $user->hasRole('membership-secretary') { return "/members/"; } else if($user->hasRole('member') { return "/members/" . ($user->name); } else { return "/" } instead of: if($user->hasRole('competition-secretary') || $user->hasRole('membership-secretary')) { return "/members/"; } else if($user->hasRole('member')) { return "/members/" . ($user->name); } else { return "/" } The error should go away if you fix the syntax. I think you might also need a closing slash after $user->name to complete the path.

Maybe you can find some useful code from the downloadAndInstall() method in my ModuleToolkit module: https://github.com/adrianbj/ProcessModuleToolkit/blob/09b437d888c270ffe01f3a80fc5dccab3136e42e/ProcessModuleToolkit.module#L1278

@Ben Sayers - maybe direct your attention and efforts to help @bernhard with his new module:

I have found this library quite useful in the past. If you are going to support recurring dates, please take a look at the inputfield interface for recurme (it works quite nicely), but please make sure if you implement momentjs for any part of that process be sure to use the timezone version of it. I also think the ability to output recurring dates using RRULE (https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html) please be sure not to follow the broken format used by Recurme. I would recommend a full read of the recurme support thread as it raises lots of issues which should help you to avoid them in this module ?

Hey @bernhard - those are now the defaults (as per the Tracy core defaults). They are also configurable in the module settings: and you can also override them for a specific dump with: d($obj, 'title', ['collapse' => 1, 'collapse_count' => 1]); which might be handy if you are dumping lots of the same object/array in a loop and you don't want them all open which not only takes up more physical space, but also more reources.

Weird - definitely keep us up to date if you find out why.

Is this on all pages or just pages of certain templates?

Is this speed affected by Tracy at all? Keep in mind that PW's core debug mode kicks in (if it's enabled) when logged in as superuser so there will be some impact from that. I honestly have no idea at this point - I can't see why/how those panels could improve the page tree loading speed - for me the page tree ajax call is definitely noticeably slower with Tracy running - obviously it's a trade-off that I think is worth it though.

Remember that if you are a superuser and you have "force su into dev mode" checked, then switching modes won't affect the mode you actually see. How is the performance when you are logged out? Tracy adds content to the DOM, so it should slow things down if anything. Is Tracy logging any errors (even Notices / Warnings)? Do you have any ajax calls - just wondering if Tracy is catching an error early that would otherwise slow things down for some reason? Are you talking about the backend or the frontend of the site being slow? Are they both slow with Tracy disabled? Does Tracy still speed things up with all panels disabled? If not, which particular panel is increasing the speed?

When you say "off", do you mean production mode, disabled "by unchecking the "Enable Tracy Debugger" checkbox, or is Tracy uninstalled? If in production mode, do you have emailing of logged errors enabled? I am wondering if you have a slow connection to your email service (SMTP or API).

Ben - I think the inputfield interface of this module is really nice so it does still have potential. This is obviously just my opinion, but I think the way the data is stored and searched needs an overhaul - it's got some real performance and flexibility problems. I think if someone was to update the way it stores the data and to properly incorporate the timezone enabled version of momentjs, it could be a really great tool, but as it is, I do think it's more trouble than it's worth.

You're dragging up some traumatic memories here ? I'll PM my version of the module that mostly works, but still has some limitations because the module uses the non-timezone enabled version of moment.js and it's using a really old version so when you go to update to a recent version and use the timezone enabled version, lots of other things break, etc, etc.

Sorry @ceberlin and @dragan - I probably need to add pagination to the "edit" mode, but don't have the time at the moment - if anyone want to tackle it, PRs greatly accepted ?

Hey @bernhard - these are the two settings that control this: https://github.com/adrianbj/TracyDebugger/blob/11582e03c22db697972a08dac0e01630b0dbcb79/includes/TD.php#L156-L157 I have hardcoded them to "1" so dumps are always collapsed, but I can certainly open them up for being modified. The normal way to do these sorts of tweaks with the Tracy core is to include those as part of the options array when calling the dump, but it's usually just too much typing and not worth the hassle, so need to come up with an easier way. No time to look into this today I'm afraid, but will do sometime soon. In the meantime, you can obviously change those for your current needs.

@MarkE - thanks for taking up the torch and trying to get some things fixed. Perhaps you could could get in touch with @Pete and get access to push changes to the main repo, or perhaps have the modules directory point to your forked version? Again, sorry I can't keep working on it, but I've never actually used it, so that makes it hard to justify the time, not to mention that I really don't know what is and isn't needed because I don't see the problems as they arise.

No, it's not in the directory. You should really take a look at @netcarver's awesome: https://pwgeeks.com/ - just type "cache" in there and you'll find some other cache related tools. Thanks for the rundown of differences - that will be really helpful.

Hi @MoritzLost - this looks great. I wonder if you could provide a quick summary of the differences with https://github.com/somatonic/ClearCacheAdmin Thanks again!

I'd install Tracy so you get a full debug trace so you can see what module is causing the issue with the setModuleConfigData() method. You could probably also just make sure all modules are up to date because I expect you're running an old version of a module where this has already been fixed.

@xportde - hi Thomas. Unfortunately with the way this module is built, it can only ever work for one branch. There are other ways to achieve what you are looking for - this thread (https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/) contains lots of useful info, but keep in mind there are lots of hooks you'll need to implement to ensure everything is locked down - it's one thing to hide part of the page tree, but you also need to hide the pages from the top-level nav under Pages > Tree. You also need to prevent direct edit access to pages outside the allowed branches. You may also want to consider modifying the breadcrumbs (like this module allows). Honestly I think it's a shame that the core doesn't support this natively.