adrian

Has anyone figured out a reliable way to add a namespace to a module without resulting in a very stubborn error like: Class "WireData" not found Seems like the only reliable way is to uninstall and then install again, but this is kinda of impossible to do once you've already updated the files, so you need to know to uninstall beforehand. I have had requests to namespace my modules, but I don't want to break people's admin interfaces (and mine for that matter). Thanks!

You'll need to do more than that to make it reliable - have a read through some of the issues - these two are key. One is simple to fix, but the other requires a fair bit of work. https://github.com/ryancramerdesign/LoginRegister/issues/2 https://github.com/ryancramerdesign/LoginRegister/issues/9

@Tyssen - unfortunately, that module is pretty broken. Either buy LoginRegisterPro, or use LoginRegister as a base (fixing the key Issues yourself), or as inspiration for how to implement your own login form and logic.

@vmo - even though PW uses pages and "repeater_" templates to house the content of repeater fields, I believe that the noLang setting of the page that contains the repeater field should handle this because you're not typically meant to adjust settings of those "repeater_" templates directly. I doubt @ryan will get to this thread so it might be worth posting a Github issue and see what he says there.

Hi @vmo - thanks for looking into this and coming up with a fix, but if I understand correctly, I feel like this is something that the PW core should handle because it's about fields within a template that has noLang = '1' not respecting that setting, whereas this module is all about specific pages/branches having this setting while others of the same template don't. Does that make sense?

Beautifully done as always Robin!

Thanks @zoeck - seems like the documentation for all this is spread all over the place which I don't think is helping Ryan get renewals. Honesty I would probably have renewed more often if I'd known about the cheaper price.

Thanks @zoeck - that page does show: Renewal Terms $39/year But then (presumably because it's expired), when I click on "Upgrade", it says "ProDevTools (Agency) $170 upgrade charge (the difference in price). Optional $89/year yearly renewal of support and upgrades after first year." I don't think upgrade is the right option, but there are no other buttons/links on that first page that actually work - the others are links to the forum thread which I no longer have access to. I can get to a page that says: "1 x Renew: ProDevTools" but this invoice has expired so I can't pay. I guess if you don't renew before your original subscription expires, you can't get it for the renewal price. I don't know if that's intentional or a limit of the forum store?

@ErikMH - I don't think I have ever seen a discounted renewal option. How do you renew a module for those reduced prices?

I don't get a notice from LRP either. For the backend, I tried both a dash and now an underscore and neither work. I did manage to login via the backend after a few attempts.

Thanks @Robin S - I tried logging in via the backend login form. I couldn't, but I managed to use the password reset which worked, but then I still couldn't login with that new password via the backend or frontend forms still.

@ryan - I can no longer log into the modules directory. I don't get any notification as to why either, but I do see this JS error (which might be unrelated). Uncaught ReferenceError: Inputfields is not defined <anonymous> https://d1juguve2xwkcy.cloudfront.net/modules/WireRequestBlocker/ProcessRequestBlocker.js?v=4-3.0.251:43 fire https://d1juguve2xwkcy.cloudfront.net/assets/pwpc/pwpc-e1739702c839f9ff94bc214b49a3df07d7cbaa03.js:1 fireWith https://d1juguve2xwkcy.cloudfront.net/assets/pwpc/pwpc-e1739702c839f9ff94bc214b49a3df07d7cbaa03.js:1 ready https://d1juguve2xwkcy.cloudfront.net/assets/pwpc/pwpc-e1739702c839f9ff94bc214b49a3df07d7cbaa03.js:1 completed https://d1juguve2xwkcy.cloudfront.net/assets/pwpc/pwpc-e1739702c839f9ff94bc214b49a3df07d7cbaa03.js:1 ProcessRequestBlocker.js:43:2

@Mike-it - sorry, it's not possible at all with the way the module works. A workaround is @teppo's https://processwire.com/modules/admin-restrict-branch-select/ which extends this module. Not quite what you are looking for, but maybe it will suffice.

Worth a read! "The lesson here is to never mix manually constructed SQL fragments and bindings when using PDO emulation. You are opening yourself up to a huge risk by doing so as a single misparse results in SQL injection. If you are a developer: Disable PDO::ATTR_EMULATE_PREPARES if possible; If not, ensure you are on the latest version (PHP 8.4) and you do not allow null bytes in your queries." https://slcyber.io/assetnote-security-research-center/a-novel-technique-for-sql-injection-in-pdos-prepared-statements/

Just a quick note that most of Ryan's pro modules don't appear under paid either.

@Mike-it - the latest version supports the Options field type but note that you need to use the numeric key for the option rather than the label, so 1 or 2 rather than Yes or No, for example.

@Jonathan Lahijani - not sure if this is what you are looking for, but all Tracy's settings can be overridden in config.php like: $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, ]; Not sure if those are the exact options you want, but hopefully that approach works for you.

And a JS error is preventing anyone from showing on the map.

Honestly I would find another host - having chmod disabled is likely to continue to cause problems.

@AndZyk @ryan @diogo - also reported here: https://github.com/processwire/processwire-issues/issues/2110

Are you also hosting with lautre.net ? Looks to me like they have disabled chmod() in php.ini

@Kiwi Chris - would it work to use the hook you showed above, but limit it so it's only applied on the frontend so it doesn't break things in the admin? Maybe I am still not understanding full though?

Hi @Kiwi Chris - this module is all about restricting branch access in the admin (so basically viewing and editing in the admin). It does not attempt to prevent viewing on the frontend at all. I honestly find the page-view permission in PW very confusing in certain situations and it has some bugs associated with it - the latest I found is: https://github.com/processwire/processwire-issues/issues/2107 I assume you are attempting to lock things down after the recent security issue that was eluded to (although the implications not really explained as well as they should have been) here: https://processwire.com/talk/topic/31385-pw-30251-–-core-updates/#comment-249810 ?

@Pete - I've just pushed a lot of critical fixes, so just in case you have already started testing, please grab the latest version. I knew there was a good reason I hadn't looked into doing this before :)

Hey @Pete - if you want to try it out: https://github.com/adrianbj/TracyDebugger/tree/namespaced I am not ready to commit to the master branch yet because there were a lot of changes required and I have a feeling I still might have missed some things - most likely core PHP things like DirectoryIterator etc that need to be prepended by \ to get them called from the global namespace.