adrian

https://github.com/processwire/processwire-requests/issues/198

Hey Robin - thanks for thoughts - makes sense. I am heading on vacation this morning for a couple of weeks, but I'll add this to my list for when I'm back.

Cue the superman music ..... "Sounds like a job for RockFinder" what do you think @bernhard ?

Thanks Ryan - this truncate method looks awesome - way to over-deliver

Oh right - sorry I missed your note about the 500 error - too busy to really read properly

Hi @tpr - I'll have to have a think about the password only option at the month when I will have a little time. There are some other options I would also like to add, so might be time for a bit of a revamp. Yes, SLT will always get involved because this module uses the regular PW login process. Not sure a way around that (or whether you should really want a way around it) without changing how access is granted.

Not sure if it's all servers, but I am finding the downloading a package from Setup > Duplicator is resulting in partial downloads. I don't have time to investigate at the moment, but just a heads up in case someone is trusting the download to be complete.

Not at all - lots of need to do FB debugging these days. It's on my list, but don't hold your breath - I am panic stations till the end of the week, then away for 2 weeks - maybe sometime late May or early June!

If you just want a link to that page with the site's URL passed, have you tried the Custom PHP panel? That said, I am curious about a more complete integration and a dedicated panel - I'll add it to my list for when I have a spare 5 minutes - it's busy here ATM :)

Check out my fork linked to above - I think this is one of the many things I fixed. If it's still an issue, feel free to submit a PR to my fork.

Sorry I missed this - not getting emails on @ pings anymore. If you upgrade from an old install of this module, you will need to manually change the field type.

Doing something similar right now and using this excellent module: http://modules.processwire.com/modules/fieldtype-fields/

Yeah, I think so. Honestly I am not too up on the current state of this autocomplete stuff, but I think my suggestions will work. Let me know how it goes when you test on Tuesday.

Hi @szabesz - it can probably be solved quite easily with some autocomplete attributes. Can you please try adding: autocomplete="pw-phone-country" autocomplete="pw-phone-area-code" autocomplete="pw-phone-number" autocomplete="pw-phone-extension" to the respective subfields. Here is the chunk of code that these need inserting into: https://github.com/adrianbj/FieldtypePhone/blob/ab02ad1a6aafc1b1abce60317cd97ce5a2c35374/InputfieldPhone.module#L98-L116 Let me know if that works as expected and feel free to submit a PR.

Hi Joshua, Any further news on this - sorry to bug you, but deadlines are looming and I need to know if I'll need to start parsing the the UNTIL value to get the end date or if you'll manage to provide a simpler option for getting a correct end date. Thanks for your time!

Hey @bernhard - I get your issue with empty vs bloated for sure. When I get some time I'll look into the possibility of a check for an empty object, although I do think that maybe that's something the PW wire __debugInfo method might be the best way to handle this. Just an FYI - Ryan just added a detailed PageFiles __debugInfo() method, so now we get this in the Request Info panel, which is pretty nice!

@Robin S, @Torsten Baldes and everyone else. Ryan has just implemented my suggestion for that snippet of JS which means that I can now remove the autocomplete removal hack from this module. Please update your PW core and this module and let me know if you find any further issues. Thanks!

@digitex - I am using it with no problems on 3.0.99 Can you make sure PW debug mode is on to see if there is any further info about the internal server error and maybe check your error logs. I also just tested the option to force all users with a particular role to have to change their password and it worked fine - set it for that role, but no impact on my superuser account. Maybe there is some interaction with Ryan's module that I haven't tested. I don't have time to look into it at the moment, but if you wouldn't mind investigating and letting me know more details of the issue, I'll make any required changes.

Hey Bernhard - not sure on this yet - I think for the average new Tracy user using __debugInfo() is a more useful experience - a full PW object can be quite overwhelming for the uninitiated. Of course once you're comfortable with them they're fine, but they also often require the use of bdb() or bd($page, [8]) type calls to get to all the info you need and a new user may not know about those options yet and just think that those [...] mean that the info isn't available. For those reasons I am tempted to leave as is for the moment. Note that Ryan just implemented __debugInfo() for WireInput: https://github.com/processwire/processwire/commit/105ba2b8ebbdf4e65f2300bf79b233850107c4d6 so that issue is solved at least.

Yeah, I am not actually sure which I prefer at the moment - I think it depends on the complexity and also how well Ryan implemented __debugInfo() for the object type in question.

@Robin S - I'll have to get back to you on that when I get a minute to look into it. Totally OT, I just wanted to mention this issue to you guys because it cost me some time today. Now that Tracy by default uses __debugInfo() for d() an bd() calls, I was getting empty responses for d($input->get), post, cookies etc. I have posted an issue for Ryan: https://github.com/processwire/processwire-issues/issues/575 - please feel free to +1 it! but in the meantime, you will need to set debugInfo to false or turn of __debugInfo() completely in the config settings.

Hi @Robin S - sorry for the slow response on this. Honestly I didn't really get very far attempting to load Tracy early. I thought it was ok initially, but as that thread showed, there were lots of issues I didn't initially see. I think it needs some significant investigation. I just don't have the time for that at the moment, but if you find a solution, I am very happy to implement any conditionals in Tracy to make it possible.

Thanks for pointing this out - I'd forgotten about that issue. Unfortunately I have a lot of code and a lot of Page Reference fields that rely on single page / null so I am hesitant to change at this point in the project. I am testing your other solution though and so far so good

Hi all - I have started a new 3.0 branch which has some more breaking changes. This new version moves the country code into it's own "data_country" database field and stores a raw version of the number in the default "data" field. The reason for this is to make it possible to do a: $pages->find("phone=13727654876") Before you could only find by component parts, like: $pages->find("phone.country=1, phone.are_code=372, phone.number=7654876") My need for this was to find a user by their full raw/unformatted phone number as returned by the Twilio sms service's POST response. I'll keep the changes in this branch for a while, but I would encourage new installs to try this version. Let me know how it goes.

Thanks - I have referenced your idea in the Github issue - will see what Ryan says. Cheers for the help!