adrian

Awesome - glad you got it working and thanks for sharing the solution!

Hi @psy - no time for a detailed answer, but I expect the solution is similar to repeaters and so this should help: https://processwire.com/talk/topic/5397-assigning-fields-to-repeaters-with-the-api/?do=findComment&comment=52123 Probably worth reading through the whole thread.

Lots of solutions for this from a simple API foreach, to the Batch Child Editor module or even this http://modules.processwire.com/modules/admin-actions-unordered-list-to-pages/ Everyone baulks at the everything is a page at first, but the benefits become apparent and it's actually very elegant and more importantly very flexible if you need to change things down the road. Not saying there isn't a place for what you have built - just say that there are multiple way to skin a cat ?

Glad you have it working, but maybe rather than changing the permissions, you should change the owner of the files to match the apache user ? https://processwire.com/docs/security/file-permissions/

I couldn't agree more - this was also my reaction with this latest version. I was thinking of mentioning this idea myself, but I love the fact that so far we've never really had any breaking changes in the evolution of PW. But unfortunately I agree that in v4 it's time to strip out lots of the experimental ideas that just haven't taken off. Think back to: $pages("template=basic-page") Has anyone here ever used that "variable as a method" approach for finding pages? I'd much rather spell it out with a get() or find() method. I know early on I was given some grief over all the shortcut methods in Tracy, but I think that's a different situation - those are temporary bits of code that don't stick around. For production stuff I like self documenting code over shortcuts that save a few keystrokes. I have no idea how it would be determined would would stay and what should be trimmed, but I think it's needed.

@DV-JF - take a read through: https://github.com/ryancramerdesign/LoginRegister/issues/2 I ended up going with a solution somewhat like this: https://github.com/ryancramerdesign/LoginRegister/issues/2#issuecomment-348031491 which is basically how I have handled this situation when I've built a register and login script previously. Unfortunately I wouldn't use this module again until it's had a lot of love - it's basically unusable at the moment.

Hey Peter, I think this isn't specifically an issue with this module but rather PW core login security settings. I just some googling on the Data Saver setting - I think the problem is that it affects the IP address of the user. I think perhaps if you disable PW's session fingerprinting the problem will also be solved.

Hope it's nothing too serious and you're on the mend.

Afraid I also agree with everyone here - too many options which I'll never remember - I'll be sticking with the traditional approach - verbosity FTW ? I feel like we are on a very slippery slope here and once you go down, you can't climb back out because you might break someone's code. I have always trusted Ryan's instincts about this stuff in the past (or he has at least convinced me in the end), but this time I am not so sure. I hate to come across as critical or unappreciative because I know that even in my own relatively simple modules I sometimes get caught up in going with too many options, so I do realize it's a tricky balance. I think this is a super important point!!!

Probably a permissions issue with the site/assets/files folder - check that the owner and perms match what you had in the staging setup.

Hey @tiefenbacher_bluetomato - unfortunately I can't help with that - I think we need @Pete's permissions to sort that out.

Well given that I am not a coffee drinker, I actually think this is cooler ? I am actually thinking of making this available to site editors, not just Tracy users - it's so nice knowing which version of a site each tab is!

Not sure I really recommend it, but you could take a look at: http://modules.processwire.com/modules/process404-search/ It parses the URL from $_SERVER['REQUEST_URI'] and returns search results that match the url segment. Keep in mind that if anything, it is recommended to have a static 404 page, rather than one that does even more db queries: https://processwire.com/blog/posts/optimizing-404s-in-processwire/

Something I've been wanting to add for a long time. Favicon server indicator badges. These show the first two letters from the subdomain / tld settings you have configured in the Tracy settings along with the configured colors. This is a new option available from the Server Type Indicator settings section: Just another attempt to help you from accidentally working on the wrong version of a site. Please let me know if you guys find any problems with it.

I used to be all about sending via SMTP, but it seems to be getting harder and harder to find a service that doesn't end up screwing you with limits at some point, or they decide you're spamming, or the deliverability is compromised. I have become a big fan of MailGun - should be free for your needs and the PW MailGun module works great - it's also faster than sending via SMTP. Be sure to grab @Macrura's new fork of the module from: http://github.com/outflux3/WireMailMailgun/

Just a follow up in case anyone is interested. On a separate project I needed to get into grouped OR selectors and I decided the easiest way is to create a standard array and simply do an implode on it, eg: $selector = []; $selector[] = 'user_types='.$u->user_type; $selector[] = 'ages=(ages.count='.$pages->count('template=age').'), ages=(ages='.$u->age).')'; $selector[] = 'sexes=(sexes.count='.$pages->count('template=sex').'), sexes=(sexes='.$u->sex.')'; $selector = implode(', ', $selector); This is back to how I used to do things and I feel like this is almost as clean as the selector array approach and so much more flexible.

Sorry, that was my fault - fixed now!

Yeah, this is a little painful. I use the same approach in Tracy. I think it might be better if Ryan replaces that json detection code with the following which seems to be the most common approach to problem. /** * is the provided string a valid json string? * * @param string $string * @return boolean */ public function isJson($string) { json_decode($string); return (json_last_error() == JSON_ERROR_NONE); } PS - actually maybe this isn't useful at all with this issue, but in general I think he should be using a function like this for determining if a string is JSON.

Maybe something useful in this thread? https://answers.microsoft.com/en-us/msoffice/forum/all/mailprotectionoutlookcom-is-rejecting-my-mails/5a6bb9e0-062c-44e0-8a60-d79959bc003e

For an outlook.com email address, I use this successfully. Do these work for you?

PS - when you have found the field in question, check out the Field settings in the RequestInfo panel to see if there are any textformatters showing there that are null or empty or something.

Have you tried: bd($textformatter, $field->name); so you can see which one at the end there is returning null? If you know the field affected, you might be able to check which textformatters are assigned to the field and find the problem that way.

Probably not enough ? Glad you're finding the API Explorer and Adminer useful. I use them both all the time. Sorry about that issue with the File Editor panel - just a stupid typo! It should be fixed in the latest version. Please let me know if it works for you now.

Someone else once mentioned that he didn't get the console errors in the response tab - turns out he didn't have "Disable Cache" checked on the Network tab and apparently that made a difference. I always have it checked because Chrome caching drives me crazy but this might be a helpful hint for others.

It looks like there is a PHP error message breaking the JSON - in your dev console click on the image upload ajax call (Network tab) and go to the response tab.