Forum Replies Created
Just wanted to update this topic to mention that the issue is solved. The root cause was due to our recent server migration, the entry in our new /etc/hosts file referred to a local address which was not a public URL. I needed to map a valid public URL in my /etc/hosts file so the email was registered as being originated by an authentic source.
I also changed the hostname to public valid path in /etc/sysconfig/network.
I doubt this issue will affect anyone else, but in case it does that’s the issue!
Hey @hnla, thanks for the advice. I’ll look into RDNS. I do already have a SPF record set up, though.
It’s not a blacklist problem, because it’s not every email address at a particular domain. As I said, the problem is extremely intermittent. More emails succeed than fail, but the small number of failures is causing a problem.
The emails are sent but not received. It is a live site. I am self-hosted. I’m only using 3 plugins, BuddyPress, bbPress, and Members.
Hey @chmielopas, thanks for your thoughts. These activation emails are just sent using wp_mail, I don’t think they are actually routed through google apps, but I’m not certain. I’m not using any plugin to deliver email to google apps, just the normal DNS settings.
I apologize for bumping, but this issue is really continuing to be a big headache. If anyone has insight into why these mails might be failing please share!
Hey @jimmmy, I had forgotten about this issue. My new theme design only uses the has_members query once per page, as I had moved the “who’s online widget” on my site to a sidebar that is not displayed on other directories with members loops.
I’m not certain if this is still an issue or not, but one thing I suppose you could try is saving the contents of $members_template to a temporary placeholder variable before issuing your custom has_members query. Once you’ve run the loop on your secondary query you could restore the original contents of $members_template.
Thank you for the update, excited to try out the new group meta loops and better group members queries.
Just thought I’d update this to share the changes to TF lately. I’m running the latest versions of BuddyPress (1.7) and bbPress(2.3). Everything is running super smooth. Check out the site, and I hope it can give you some ideas or inspiration for your own communities
I wanted to update this thread to show off the brand new WP/bbPress/BuddyPress parent theme that I created to serve as the new platform for Tamriel Foundry moving forward.
After a month and a half of development, I’ve shipped it to the live site, and am using my extensive community as unwilling lab rats chasing after cheese and bugs through my Elder Scrolls themed social maze.
I’m particularly happy with the theme functionality and performance so far, and I think it definitely has room to grow and improve further. Be sure to check it out and let me know what you think about my implementation of the BP environment!
Thanks for looking into this so quickly @djpaul. Appreciate your hard work
Would you presume I can safely delete the 25,000+ akismet activity meta entries which are in my bp_activity_meta table without it causing any adverse effects?
OK, I looked into the code, and this is something I’ll need to go bring up on the bbPress forums as it’s an issue with the extend buddypress component of the bbPress plugin.
I opened a ticket here: https://bbpress.trac.wordpress.org/ticket/2140. Hopefully this helps!
I had built some functionality into my widget which the stock BP who’s online didn’t incorporate. My code is actually pretty similar to the stock widgets in bp-core-widget, but yet I run into this issue where any other has_members query contaminates the contents of my widget. There must be some trick that I’m missing to initiate a has_members query that resets any pre-existing query…
@johnjamesjacoby great to hear. Looking forward to the update, thanks!
Having the same issue. I can confirm that as per the trac ticket, enqueue jcrop styles resolves the issue.
Thank you @djpaul, I had a similar issue, and the user_id parameter saved my bacon!
I would still be interested in knowing how to filter user registrations though, in addition to whatever Captcha method I use I wouldn’t mind adding a honeypot as a redundant safeguard.
Hey @candeed, thanks for the compliment! I’ve worked hard to integrate BP into my theme as naturally as possible and to keep pages lightweight. However, I would definitely benefit from the advice and collaboration of someone who has more development experience. I hide it pretty well through constant research and lots of hard work, but I’m actually still a huge noob when it comes to this stuff. If you have any friends who are experienced developers and interested in ESO I would definitely like to get a chance to talk to them.
Hmm thanks @aces, I looked that over and it doesn’t seem to quite address my problem. The issue isn’t restricting usernames at signup in any way, I just want my login form to pass a username field which has spaces str_replaced to hyphens since my users keep forgetting to log in with their “login name” rather than their “display name”.
The answer might be to just write my own login widget, and do the replacement in PHP before calling the authentication. I was hoping for an easy filter that I could plug into though.
Exact same problem as @GordonRe, users successfully activate by following the emailed activation link, however this prompts them to enter a key even though their activation was successful.
From the activation template, the problem seems to be with:
This conditional must not be returning TRUE, otherwise the form would display the activation successful message. Not sure how best to approach this, but the autologin on successful activation plugin sounds like a potential alternative…
Thanks @djpaul, you guys really have built a fantastic platform. I’m still a novice when it comes to BP development, but the framework has slotted really nicely into the site, and all the social features (especially groups, which are mostly guilds for us) have been very popular!
Unfortunately this is still giving me issues, currently I’m just hiding the button with CSS.
It’s also worth noting that original is saved even if the avatar upload process is abandoned partway through.
Also, repeating the avatar generation process with the same base image saves duplicates of the file as filename-instance.extension.
Ultimately as the plugin designers, this is the type of feature that you guys have complete discretion over, of course, but perhaps the inclusion of an optional function to tidy out old source files would be a nice addition.
I know my avatar upload directory is comprised of approximately 75% original files, and 25% user avatars. I imagine for communities where users change avatars frequently this would be even worse.