Jump to content



  • Posts

  • Joined

  • Last visited

About Summit360

Recent Profile Visitors

6,276 profile views

Summit360's Achievements

  1. Hi great work, looking forward to v3 for IPB4.5. I'm currently warming some members up to it on the v2.4.7. Just learning all the new options and making a few minor tweaks. One thing I can't quite seem to get right is the @mentions. That is I can make it right for light, but then dark looks out and vice versa. I'd almost say no colour at all would be better. I did look at the demo which seems to be making use of css vars 🙂 although they are not, or don't seem to be in 2.4.7. Any thoughts on this one?
    As @bluto says, using a transactional processor and getting a failure was a chore to unset preferences and alike. Then the user might just opt back into emails anyway. Note it does not solve the unsubscribing from things, but does suppress sending notifications. Wish I'd found it 2years ago 😄
  2. When this feature was initially released I was excited to use it. As soon as I saw the registration flow for a free subscription I turned it off, it's terrible. As a developer myself, I know you have to release things and get feedback. IT won't always be right and the perfect release is never released. I'd really like to hope to see this feature be useable soon. The most obvious pattern from our perspective as community owners, seems to have completely slipped past the user stories phase. Fingers crossed 🙂
  3. Was following this topic for very similar issues last month and now again. I didn't raise a specific ticket on this, did raise one on curl timeouts. Now had to raise one... Just been told that ES and update of view counters are not related :S with mysql search working, turn ES on, they stop working.... Well gosh darn. Sadly it's still not working, so I've gone back to MySQL search. If I had a setting to turn view counts off I would ... css to the rescue to cover up a bug. Except then the updates table grows and grows like an unseen worm, waiting for you to be in the air over Africa to strike...
  4. This would be good to know too. We cant' place subscriptions on the signup or anywhere with a free one forcing you through a checkout process. Which is the wrong journey for a 'free' option. Why offer a free one? I was asked. To create a differentiation, and to inform, essentially, by free you accept promotions/ads etc. By a paid one you get xGb storage, no Ads and so on.
  5. @The Old Man I raised this and offered a fix, it wasn't taken up. It might be something you can do with s3 perms out of the box now.
  6. Just to add to this as I'm sure we're not alone... I've reached the end of the economic line for a single VPS. I count myself lucky the provider is excellent and very few SPOF incidents. I don't wish to move to a single commodity dedicated server, I'm going horizontal. Using any of the leading VPS providers there is a 'private' network which isn't actually 'private'. A couple do offer it. A VPN would be the only solution that works at any host, based on your feedback @Lindywhich is more complex to setup and manage than certificates. I don't think it's unreasonable for us to have a way of securely connecting to our database servers out of the box, others manage it. Issuing certs and distributing them isn't really a challenge. With the rise of tools like RDS and other 'remote' cloud services, we're increasingly connected beyond the idilic single server setup. As @Johno2518 says, transport security is the key. Because even in a private world, it's not if, but when! I'm probably going to solve this with either editing the core files, or following plan A with running Maria in a cluster and still having a 'localhost' connection. Its far better now than it used to be ? i.e. it works without needing a full-time dba to keep it running ?
  7. Ben, If you've not already done so, check the cost of serving from S3. Ideally you want to put a cloudfront 'CDN' in front of your S3 assets. You'll need a new IAM user with the right auth to your bucket, then set a policy for access as a logged in user only. Afterwards if you try to access the S3 bucket image, from a unauthenticated session, you should get the error document instead. You'll also need to specify the cloudfront url in the files section of IPB admin. Checkout this post:
  8. This is a problem for me, only on an annual basis. Only this morning I had to go and unlock an expired invoice for a guy who'd been away for 2 years. Ok so you can't keep invoices open for ever, but the only allow one should count 'intelligently' and not include expired purchases. I'd say for every one who gets in touch, three others don't or give up trying. I actually think letting them purchase more and handle the refunds might be better than looking at failed renewal stats The old subscriptions; pre commerce, pre nexus, worked as it does on most other board software like this... better. Nexus/commerce is not that great for subscription renewals. It needs to be looked at by a dev with a user hat on.
  9. I hit this trying to convert to git deployments / docker. Bit of mare with the install codes and testing. Also as I code in the cloud, localhost just does not work! Well it can, but who's got time for that. You can only change/reset your urls so often. IIRC it's once every 6 months... hehe deploy a vps, run up docker, update your loadbalancer, that's a new url every 6 minutes. I don't therefore do this with ipb. So I did two things. 1. Converted ( brought ) an old lic which gives me a public testable site. Seems expensive, but < 2hours dev time and you'll get that back later on demo/test site. 2. Use a domain I own, but create a dev subdomain, so dev.mydomain.tld and so on... then I map locally dev.subdomain to the ip wherever I'm testing, even Localhost is the one that has a 'happy' exclusion though, by doing this mapping, you tie yourself to it's name for 6 months, or the $15 fee. Ultimately, though it's not as smooth and happy path as other opensource projects, that's just a fact of the license. I've stopped worrying and gone with it. HTH.
  10. I'm not sure why this is such a lengthy delay though. In development though. One does simply not remove a huge feature without a plan, well ok... Was it really a pain leaving the option in place for those of us with a few million posts or more? Search was never been that good anyway so I'm not upset When we moved to IPB in 200# from vb, most of the early complaints were about search and that continued till recently*. Search maybe isn't that important in social media, maybe that's the influence, error. I've removed the emphasis in guidelines on searching before asking again *I've been pushing people to a google search page and I'm still on 3.4; the last of the ipb sites I own. I've been putting off migrating, dropping *search service* news was a moment. Now the sands of time are nearly out. I'm replacing my public search links to my hosted google search page, actually quite handy. You can set up watches and for key phrases, put suggestions in. e.g. tyres for winter, I can prompt you to view the tyres for winter topic, before the results. Zero cost inc the hosting via github pages for a static html page, plus income from the ads . Going to do a duckduck one too. One has to have options, in case google decide to drop their search engine. HTH.
  11. What was present in IPB3 on login handlers which does not appear in 4, so far as I can see is the ability to specify form html and the bank of urls for maintenance, register, log in and out. IF they were there it should work like it does in 3
  12. I was looking at this too, the SSO is red herring, it's SSO for other IPB apps, not a true single sign on multi-platform solution. The outline is to have the forum be a part of a larger eco system of applications. Applications not made in PHP nor even related to forums. Lets say a finance check, or insurance quote; motoring related site, either way, applications or services that are not plugins to the forum code base. So: www.example.com forums.example.com accounts.example.com rubyApp1... nodeApp2... phpApp3... So we wrote a quick ruby 'accounts' app to handle all user registration and login/out, it's a dirty hack using plain text to get us moving. Connect some oauth for a separate news app, sign in to news app using oauth[1] provided by accounts. Next we configure IPB to use external database. Create a user in the accounts db and I can login to the forums just fine, looking good! Now, lets handle registration. If I disable registration in forums, I can't register. I can create the user over in the accounts app, when they hit the forums they cannot complete the 'registration' as registration is disabled. Ok, sort of makes sense. Enable registration and the users are sent to the forum registration bypassing our account app. The flip is to give the forum code what it wants. Simply for it to be the central golden repository of users and connect our other services to that... This is going back a few months before IPB4 was released, but it was enough to leave me scratching my head how this can be done. Without: Rewriting registration link to accounts - tempting Altering/overwriting core forum code, forum code needs to be up-datable and standard as much as possible. Not using plain text or md5 ( Needs new PHP login handler : ok |> works ) Avoids PlanZ of creating a 'services' domain [ exampleservices.com ], that is different and is a wholly separate registration, but this is 2 registrations hell! I don't think the 3rd party db login support has been thought through from a perspective that the forum isn't the canonical owner of user data. Unless and I sincerly hope this is the case, I've missed something stupidly obvious. [1] Of course this is not a golden path. Sign in on oauth, crucially sign out does not signout out of the other app. That is you sign into forumx using facebook auth, you're logged into facebook when you logout of forumx. The trick is to cancel the sign in token after signing in on the auto provider. When you sign out of the forum, you're already signed out of accounts. The con is you head to portal app and you need to sign in.
  13. Interesting test results. I was just setting up a redis container and enabled caching. Less scientific, but it felt slower, maybe I'm getting old. It's only me using it between a couple of incognito sessions... I've also got a memcache container waiting. Once I've sorted another issue, I'll probably get to throw some load testing on and see. I suspect, the non-cache response time & load will rocket as we head up the RPS chart.
  14. Hi, Exploring external Db Authentication options in IPB4. My goal to have an external Db, a members suite of apps which handles registration and non forum features. The external Db is managed by non php code, so the "SSO" as IPB think of it via connect, is not suitable. To prove the concept I have a super simple external Db, which IPB is correctly talking to and allowing users to log in via when they exist. In IPB3 there was a external registration url, where to send the user to register etc. That is to say I want the users to register via my other 'members' application, which populates the external Db, then the forums hook into that. Exploring and checking out the code and the admin panel, it looks like this has gone? Things I've tried: Disable registration on forum site, results in a error when external user signs into the forums for the first time.Enable registration on forum site, results in members appearing in the forums db, not external, which is half good.Various states of registration validation, again the key is the user is being created in the forum db, not externally first.I'm not really looking to hack the templates to remove or replace registration links on a brand new platform. Can anyone suggest something I may of overlooked? Cheers, Colin. Plan B To write a OAUTH handler like the facebook one and to make my external app an oauth provider. It gets a bit tricky around logout though, just as logging out of forum x, does not log you out of facebook.
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy