Below is a transcript of the PMPro Dev Chat held today. Thanks to everyone who participated.


jasoncoleman [2:56 PM]
Chat is REALLY starting this time in 4 minutes or so.

jasoncoleman [2:56 PM]
If you are here, say hi and introduce yourself.

squarelines [2:56 PM]
Mm-hmm.

squarelines [2:56 PM]
Hi, everybody! I’m Aaron from Square Lines. We do a bunch of development work, including with WP and PMPro.

russell77 [2:58 PM]
Hi, I’m Russell from DevonWebDesigners – currently building a membership site with challenging checkout including events with staged payment plans

ghmaster [2:59 PM]
Hello everyone. I’m Harsha. I help with PMPro Support.

squarelines [3:00 PM]
@russell77: Sounds like fun!

tubiz [3:00 PM]
Hi, am Tunbosun a freelance WordPress developer

russell77 [3:00 PM]
@squarelines: Just lovin’ it

jasoncoleman [3:01 PM]
Keep introducing yourself. Agenda is light this time. If you want to follow along, theme music for this chat will be Cold War Kids Hold my Home spotify:album:6ZPoJ7DnpM3vjlKr55gwvA
Spotify
Cold War Kids – Hold My Home (Deluxe Edition)

jasoncoleman [3:01 PM]
Also note that I will be copy/pasting this chat to our public blog when we’re finished.

jasoncoleman [3:02 PM]
Don’t think anyone else is online, so I’ll get started.

jasoncoleman [3:02 PM]
I blogged it, but FYI we have a public Trello board now https://trello.com/b/9imAaI5Q/paid-memberships-pro-development

jasoncoleman [3:02 PM]
Doing our best to keep that updated with the major efforts we are working on internally on the core plugin and addons.

jasoncoleman [3:03 PM]
The blog https://www.paidmembershipspro.com/2015/10/follow-paid-memberships-pro-development-on-trello/

jasoncoleman [3:03 PM]
Feel free to post ideas for the incoming list to our contact form and they may make it to the board (we’ll kind of triage it first) and feel free to bug me personally for things you really want to champion

jasoncoleman [3:05 PM]
Other than that announcement, I wanted to get ideas for the next developer webinar for November 18th. The last one was on Register Helper

jasoncoleman [3:05 PM]
And if anyone has questions or topics for discussion, let me know.

jasoncoleman [3:05 PM]
Or just shout it out

squarelines [3:06 PM]
Curious about the roadmap for v2.0. Lots of potential features and disruptions to be had there, so wondering about your thoughts on timeline.

jasoncoleman [3:06 PM]
Where 2.0 = multiple membership levels per user?

squarelines [3:06 PM]
Yes, et al.

jasoncoleman [3:07 PM]
No active development.

jasoncoleman [3:07 PM]
I had a thought to do multiple membership levels per user as an addon first.

russell77 [3:07 PM]
BTW: I submitted a request and included the message “Development Request for Trello Board”. I got a canned response back which made me unclear whether it got routed correctly or not.

jasoncoleman [3:07 PM]
Have thought about that some.

jasoncoleman [3:07 PM]
@russell77: I’ll look for it.

squarelines [3:07 PM]
An add-on approach would be oogly from your end, but useful for third-parties, I think.

squarelines [3:08 PM]
It would ensure that the hooks and filters needed to adjust would all be identified and tied up.

russell77 [3:08 PM]
@jasoncoleman: Thanks

jasoncoleman [3:08 PM]
Having it as an addon would make it opt in for folks.

jasoncoleman [3:08 PM]
And so we can say “doesn’t work with these other add ons and gists”

squarelines [3:08 PM]
Ah – good point from a long-term migration perspective.

jasoncoleman [3:08 PM]
if we add it to core, we kind of need it to work with everything, which is tough and will take all of the time

squarelines [3:09 PM]
Yeah, there are lots of gists and plug-ins floating around out there (not to mention customizations), so a more incremental approach makes sense.

squarelines [3:09 PM]
We were just confronted by a situation recently where it would have been helpful functionality, but the multiple-membership permutations were only ~10 or so, so we went that way instead.

squarelines [3:09 PM]
But it brought up the desire once again for that functionality.

jasoncoleman [3:10 PM]
@russell77: Found your form submission RE payment plans. Got sent to me where I dropped the ball. Let’s discuss it now then

russell77 [3:10 PM]
Always good to keep the core tight. Need overwhelming benefit to justify adding more stuff in (IMHO)

sjolshagen [3:10 PM]
Sorry I’m late. :simple_smile:

jasoncoleman [3:10 PM]
I think multiple memberships per user is highly desired and really cool and would increase our user base

jasoncoleman [3:11 PM]
I really want PMPro to be the first option for membership sites and that’s a big part of it

sjolshagen [3:11 PM]
+1 on multiple memberships per user!

jasoncoleman [3:11 PM]
but focusing on that was happening at the expense of current use cases

jasoncoleman [3:11 PM]
so we’re trying to clean things up a bunch first (no new features) before tackling

jasoncoleman [3:11 PM]
it

russell77 [3:11 PM]
what is the downside risk of adding multiple membership levels?

jasoncoleman [3:11 PM]
but I’m open to working on it in add on form if someone else wants to do some of the heavy lifting

squarelines [3:11 PM]
Lots of things depend on the one-level-per-user functionality.

jasoncoleman [3:11 PM]
hi @sjolshagen! Introduce yourself.

squarelines [3:11 PM]
(Sorry, that was for @russell77 )

jasoncoleman [3:12 PM]
There are numerous places in the code where we make the assumption that users have only one level.

jasoncoleman [3:12 PM]
So all of those have to be fixed up (mostly difficult in add ons)

russell77 [3:12 PM]
@squarelines: Re: Lots of things depend on the one-level-per-user functionality. is that dependency in core, or in addins?

jasoncoleman [3:13 PM]
we have actually done a lot of behind the scenes work to support multiple membership levels per user

squarelines [3:13 PM]
@russell77: Yes. All of the above. There are also helper functions in PMPro that get levels for users, and assumptions are made about returning only one, for instance.

jasoncoleman [3:13 PM]
So for example the prorating code fires on level changes, but doesn’t have logic to account for having multiple levels.

jasoncoleman [3:14 PM]
MailChimp integration moves people from list to list based on their level and doesn’t know about multiple levels.

sjolshagen [3:14 PM]
Am using PMPro to handle payment & access for an online coaching plugin I’ve written for my coaching business. Being able to layer memberships would let me be a whole lot more flexible in terms of how I release content. (Less duplication). Also written a drip-feed plugin that uses PMPro (PMPro Sequences). It originally started as a fork of PMPro Series, but is pretty much a completely different plugin at this stage.

jasoncoleman [3:14 PM]
At the least I want to start documenting these requirements… maybe in comments in the addon and core code (there are some in core yet)

jasoncoleman [3:15 PM]
@sjolshagen: I’d still like to merge Series and Sequences. We should figure that out.

russell77 [3:17 PM]
So maybe providing a helper function that add-ons will be “required” to use – idea is to force addons to use a standard interface – maybe the helper function can operate is 2 modes (return all or single membership) – this might ease the migration path? How many add-ons would be affected by the change? How many developers are involved?

jasoncoleman [3:18 PM]
Just added a couple things to the active work core list on Trello. Fixing up JS to support minimization and combining pmpro_ options to minimize DB hits.

jasoncoleman [3:18 PM]
@russell77: That’s something we thought of as well… some kind of explicit or implicit flag to switch between 1per and +per user modes.

jasoncoleman [3:19 PM]
I haven’t audited all of the add ons involved. We should.

sjolshagen [3:19 PM]
@jasoncoleman: I just finished a rewrite that basically threw out the way Series handled posts in the series, so at this point I don’t think there’s an easy way to merge. I ​_can_​ migrate (filter based merge functionality by series ID on activation) from Series -> Sequences, but since I now support repeating posts in the sequence, etc, I had to change the entire metadata/load functionality that Series uses to something that would work for my needs.

jasoncoleman [3:19 PM]
@sjolshagen: Ah

squarelines [3:19 PM]
@jasoncoleman: What does combining pmpro_options mean to you? Would you collapse entries like pmpro_gateway, pmpro_gateway_email, etc? Or consolidate DB calls to the existing entries?

jasoncoleman [3:20 PM]
Yeah have an option pmpro_options that is an array with all of the old pmpro_ options in it

jasoncoleman [3:20 PM]
Then it’s 1 DB hit instead of 1 per option.

squarelines [3:20 PM]
Big array! That’s like ~60 options!

jasoncoleman [3:20 PM]
small KB I think

squarelines [3:20 PM]
True dat.

jasoncoleman [3:20 PM]
maybe should be a few options/arrays

jasoncoleman [3:21 PM]
?

jasoncoleman [3:21 PM]
it’s loading all of that data anyway

jasoncoleman [3:21 PM]
now

jasoncoleman [3:21 PM]
4/5 years ago, we weren’t smart about these thigns.

squarelines [3:21 PM]
Depending on how you access them in the code, might make sense to break up conceptually? But if you’re just blanket-loading ‘em all, then you’re right – one biggie seems best.

jasoncoleman [3:22 PM]
I think we have been good about using the pmpro_getOption function instead of getting the option via WP functions or DB calls. So should be good to merge any option that isn’t searched on in the DB (most of em)

jasoncoleman [3:22 PM]
Then we’d need to write a script to run when upgrading to fix things up.

jasoncoleman [3:22 PM]
Fun!

squarelines [3:23 PM]
Absolutely!

russell77 [3:23 PM]
Go for 1 option if it is pretty static; if any are a bit more transitory (recording state) then split those out

squarelines [3:23 PM]
Yeah, I’m assuming _transients would still be floating out by themselves.

jasoncoleman [3:23 PM]
Anyone interested in working on that multiple membership levels per user add on?

jasoncoleman [3:24 PM]
Maybe we should do the next dev webinar on the work arounds?

squarelines [3:24 PM]
@jasoncoleman: Definitely interested in helping, but not sure I can devote the time right away. :confused:

russell77 [3:25 PM]
The other thing I do in my plugins is encode security data such as API keys, so I have 2 options array entries; one plain text, and the other encoded/obfuscated.

jasoncoleman [3:25 PM]
Any Qs/topics unaddressed? I can bring up @russell77 ‘s payment plan idea if he’s okay with it. Want me to post the email text?

squarelines [3:25 PM]
A conversation about the workarounds would be good, though – I’ve had to lead clients down that path a couple of times, and each time had to refresh my recollection about the limitations of each option.

jasoncoleman [3:25 PM]
@russell77: RE encoding… how do you do that?

russell77 [3:25 PM]
@josoncoleman: please

jasoncoleman [3:26 PM]
That’s come up a few times. I reply (maybe to you) that it’s not really secure since the keys need to be decoded to send to the gateway and so can be decoded by an attacker.

jasoncoleman [3:26 PM]
And it doesn’t seem like standard practice. But I’m open to ideas, especially simple ones :simple_smile:

russell77 [3:27 PM]
@jasoncoleman: using base64_encode

jasoncoleman [3:27 PM]
with a salt?

jasoncoleman [3:28 PM]
or that function doesn’t support a salt.

jasoncoleman [3:28 PM]
but could use one that does and then someone with admin access, but no access to wp-config.php wouldn’t be able to decode the values…

russell77 [3:28 PM]
@jasoncoleman: it give some protection against sniffing or if the database backup gets stolen, just makes it a bit less likely that you get the blame when the users data is stolen…

jasoncoleman [3:28 PM]
but might be able to run PHP to code to get it

squarelines [3:28 PM]
That’s the path we’ve used for encryption – store the salt somewhere tricky, and use it for encrypting.

squarelines [3:29 PM]
As @russell77 pointed out, base64_encode is more about obfuscation, I think.

jasoncoleman [3:29 PM]
Yeah. The annoyance of not being able to copy passwords/keys out of the settings is a factor.

jasoncoleman [3:29 PM]
(we routinely copy them out and back them up when testing)

squarelines [3:29 PM]
Agreed.

russell77 [3:30 PM]
@squarelines: yes it just means you are not sending API keys around in free text

jasoncoleman [3:30 PM]
And I think the fact that the keys aren’t obscured helps people to understand to keep their admin secure or make sure the keys don’t have full access on the gateway side/etc.

russell77 [3:30 PM]
Hmmm

russell77 [3:32 PM]
BTW – for the “secure” data I send the the md5 of the field to the user interface and put it is a type=”password” field – so I don’t actually send the field to the browser

jasoncoleman [3:32 PM]
(checking if WP has core encrypt/decrypt functions. I don’t think so.)

squarelines [3:32 PM]
I think WP uses mcrypt internally, doesn’t it?

jasoncoleman [3:33 PM]
https://github.com/WordPress/WordPress/search?utf8=%E2%9C%93&q=mcrypt&type=Code

GitHub
WordPress/WordPress
WordPress, Git-ified. Synced via SVN every 15 minutes, including branches and tags! This repository is just a mirror of the WordPress subversion repository. Please do not send pull requests. Submit…

jasoncoleman [3:33 PM]
they have functions for hashing passwords, but I don’t think anything reversable.

squarelines [3:33 PM]
Yep – it’s a one-way funnel.

russell77 [3:34 PM]
When I have use mcrypt, I needed to add in manually

jasoncoleman [3:34 PM]
So we could add some helper functions to encrypt/decrypt and maybe something in pmpro_get/setOption to hook into that when needed.

jasoncoleman [3:34 PM]
And update the UI for the settings to be password fields vs text fields.

jasoncoleman [3:35 PM]
It would add a bit of security and some sense of security. The sense of security would stop some emails I get, but maybe encourage others “this isn’t REALLY secure” :simple_smile:

squarelines [3:35 PM]
Ha!

russell77 [3:35 PM]
@jasoncoleman I can send through my code and you can review and use it if you like it

jasoncoleman [3:35 PM]
I’m open to peer pressure on this one, especially if there was a patch.

jasoncoleman [3:36 PM]
@russell77: Yeah. Send it or post in a gist here. Would be nice for reference if we work on it.

jasoncoleman [3:36 PM]
Payment plans…

jasoncoleman [3:37 PM]
I would like payment plan support ideally built into core or possibly as an addon.

I am just about to implement payment plans for events and am using a mix of your tutorial at https://www.paidmembershipspro.com/2015/02/add-select-a-payment-plan-box-to-membership-checkout-code-demo/ and the SubscriptionDelays addon.

Event Pricing is a bit different from the usual membership pricing as the payment schedule is relative to the time of the event, not the time of purchase. Also pricing may change as time passes and necessary does for payment plans as the event approaches and time window shortens.

An Example.

Event is October 2016. Single payment ($900) and a 3 payment plan are offered. ($300 x 3)

Deposit now.
Then payment 3 months before event
Then final payment 1 month before event

This is a 3 payment plan up until 4 months before the event, then becomes a 2 payment plan up until 2 months before the event after which point only a single payment is available.

I am using the custom code to group the payment options/memberships together and the Subscription Delays addon to schedule the payments. Manual intervention will be required 4 months before the event to change the payment plan schedule to just 2 payments (2x $450) and at 2 months to remove the payment plan option.
:bulb:1

russell77 [3:37 PM]
Yes, my current challenge is Event payments; with staged payment plans that operate relative to the date of the event (as opposed to the date or the order)

jasoncoleman [3:38 PM]
forgot to quote, but that last text block is from @russell77 ‘s email. How would the addon work vs how you are doing it custom?

jasoncoleman [3:38 PM]
Or are you thinking more to make it simpler for people to setup?

jasoncoleman [3:38 PM]
It comes up some times RE paying for things in advanced… so not giving someone access until the event date. Might be related here.

jasoncoleman [3:39 PM]
There is some marketing material out there RE offering payment plans to increase conversions. So some kind of easy “[ ] Offer a payment for this?”, then “Split into [ ] payments of [ $ ]” that automatically offered the second option would be pretty cool.

jasoncoleman [3:40 PM]
FYI another piece of payment plans is to disable cancelling until the end of the plan.

jasoncoleman [3:40 PM]
Thought of a question RE whether the Trello board should be used for brand new addons or just existing ones. Not sure.

russell77 [3:40 PM]
@jasoncoleman: To be honest I have not come up with a cunning plan as how to put it together. The event “membership” was to start at the time of order, as there would be “prep” work before the event.

squarelines [3:40 PM]
(or not – you may want to allow cancellation but then revoke their membership)

jasoncoleman [3:40 PM]
^ sure

jasoncoleman [3:41 PM]
I think we can post ideas for new addons in the incoming list.

jasoncoleman [3:41 PM]
And move them if we work on them. Makes sense.

jasoncoleman [3:41 PM]
We can’t work on that one, but I can help you to scope it out sometime in a private chat.

russell77 [3:42 PM]
With PayPal the user can of course cancel before all payments are made – and the handling of this is likely to be varied

jasoncoleman [3:42 PM]
if you need it for a client, might be good to do it in a general way as an add on.

squarelines [3:42 PM]
I could see the “split into x payments” piece being useful, especially if you had some control over the scheduling of those payments, and then the system adjusted the increment dollar amounts up as the payment deadlines passed.

jasoncoleman [3:42 PM]
we can help finalize it before sharing.

jasoncoleman [3:43 PM]
I thought of another question. Anyone here using Memberlite? Feedback?

russell77 [3:43 PM]
Probably “Payment Plans for Products” and “Payment Plans for Events” are two different animals

squarelines [3:43 PM]
How would you store the timed pieces of that? Cron? ( @jasoncoleman: Not using Memberlite.)

jasoncoleman [3:43 PM]
@russell77: Might be.

squarelines [3:44 PM]
@russell77: I dunno – seems like the only difference is the calculation of the increment timing.

squarelines [3:44 PM]
(Counting back vs. counting forward.)

russell77 [3:44 PM]
@squarelines: often on events the price changes over time, and the number of payments changes as the event approaches – so it has a lot more moving parts (edited)

jasoncoleman [3:44 PM]
I think it could just store the values and “twist” them into the correct settings for a traditional recurring level wtih an end date.

squarelines [3:44 PM]
Events would be a superset of functionality, I’d think.

jasoncoleman [3:45 PM]
FYI next version of PMPro will have get_pmpro_level_meta and set_pmpro_level_meta functions

jasoncoleman [3:45 PM]
didn’t add that to the Trello

squarelines [3:45 PM]
@jasoncoleman: I see that. Just adjust the recurring membership parameters on a schedule, essentially.

jasoncoleman [3:45 PM]
Yeah, so $300 now or $100 per month for 3 months…. @russell77 also wants a delay between the initial and first recurring payment.

jasoncoleman [3:45 PM]
not sure if that last bit is typical … or only important for events.

squarelines [3:45 PM]
level_meta would be really useful – meta info like…available for registrations?

jasoncoleman [3:46 PM]
right now have a lot of addons with options like pmpromc_lists_1 for level 1 mailchimp lists/etc

jasoncoleman [3:46 PM]
We’re going to add a wp_pmpro_levelmeta table and store level meta in there.

squarelines [3:46 PM]
Ah, I see.

jasoncoleman [3:47 PM]
we’ve already coded part of it, but now that I say that I realize another idea that came up before was to still have the level table, but also have a WP post to store some of the info.. maybe redundantly

jasoncoleman [3:47 PM]
could just use post meta then

jasoncoleman [3:47 PM]
but I think we shouldn’t go down that path

jasoncoleman [3:47 PM]
I actually forget what will be the first code to use the new functions.

squarelines [3:47 PM]
Yeah – ick. Using postmeta for outside its scope seems squidgy.

jasoncoleman [3:47 PM]
But it will be handy for addons.

squarelines [3:47 PM]
For sure.

jasoncoleman [3:48 PM]
Could think of it like a level could be a post (CPT) with some extra stuff (in the level table)

jasoncoleman [3:48 PM]
so we can still do fast searches/exports/etc on the table. but would have a post to do post like things.

jasoncoleman [3:48 PM]
confusing to bolt it on at this point.

squarelines [3:48 PM]
Yeah, that’s where I went at first – but with all of the ancillary pmpro_ tables, why break up the taxonomy?

jasoncoleman [3:48 PM]
word

russell77 [3:49 PM]
+1 to using a CPT (if Woocommerce can do it, anyone can :simple_smile:

jasoncoleman [3:49 PM]
can’t find it but Pippin Williamson had a post about using CTPs for EDD or Restrict Content Pro and wishing he hadn’t.

jasoncoleman [3:50 PM]
I thought about it a lot when starting PMPro

jasoncoleman [3:50 PM]
lots of backlash for not doing it back then.

jasoncoleman [3:50 PM]
I think a hybrid method might work.

jasoncoleman [3:50 PM]
but probably not worth it now.

russell77 [3:50 PM]
I will shutup then (damned if you do, damned if you dont)

squarelines [3:50 PM]
Interesting. I can see using CPTs for something that’s relatively self-contained and content-focused (display), but membership doesn’t really have any of those characteristics.

jasoncoleman [3:51 PM]
there are some pros to it, some that we won’t be able to take full advantage of. Like could get a “free” page for each level on the frontend. But we do that in other ways, so would be confusing if they all of a sudden showed up.

jasoncoleman [3:51 PM]
I think front end pages like that are more crucial to shopping carts (woocommerce) than membership levels

jasoncoleman [3:51 PM]
Any thoughts on Memberlite?

jasoncoleman [3:52 PM]
Another question… I’m going to send out surveys to our mailing list. Any questions you would ask?

jasoncoleman [3:52 PM]
(will wrap up in 8min)

squarelines [3:52 PM]
Nothing on Memberlite here. Who’s on the mailing list? (That would determine the kind of question.)

jasoncoleman [3:52 PM]
25k free and paying PMPro members

jasoncoleman [3:52 PM]
might send a separate survey to paying members with questions like “why did you decide to pay?” :simple_smile:

russell77 [3:53 PM]
@jasoncoleman: “why did you decide to pay?” coz we get to spend time with you
:heart_eyes:1

jasoncoleman [3:53 PM]
Some questions I have are on dev vs end user, PMPro for main work or hobby/side business, addons used, gateways used, hosting used.

jasoncoleman [3:53 PM]
:simple_smile:

squarelines [3:54 PM]
Hm. For the whole group: marketing–maybe ask if they’re actively using PMPro now, if they use it for themselves vs. others (are they admins or devs, essentially). Did they migrate from other plug-ins, and if so, what? For features: what do they want that’s missing, etc.

squarelines [3:54 PM]
Most desired gateways. Host info would be interesting.

jasoncoleman [3:54 PM]
Thanks for ideas. I think I’ll have like 30 Qs and split them up so everyone only gets like 5 of them.

squarelines [3:55 PM]
You don’t collect usage info from active installs, do you?

jasoncoleman [3:55 PM]
Not really.

squarelines [3:55 PM]
(Active add-ons, active gateway, etc)

jasoncoleman [3:55 PM]
We get info when licenses are activated now.

squarelines [3:55 PM]
If there’s a non-creepy way to do that, it might provide good info.

jasoncoleman [3:55 PM]
haven’t looked at the data

jasoncoleman [3:55 PM]
I want to add information when addons are downloaded.

jasoncoleman [3:55 PM]
would be straight forward but haven’t found the time.

russell77 [3:55 PM]
Might be worth doing like Yoast SEO and asking to allow usage tracking

squarelines [3:56 PM]
An infrequent PMPro-phone-home with config info, even.

jasoncoleman [3:56 PM]
For sure. Has to be opt in from WP terms, but would be really useful.

jasoncoleman [3:56 PM]
hmmm… going to put that in the planned work core list I think

squarelines [3:56 PM]
Could save you from creating so many survey questions! :simple_smile:

jasoncoleman [3:56 PM]
but might be more of an internal thing (I have a separate non-public trello for our internal stuff)

jasoncoleman [3:57 PM]
for sure

jasoncoleman [3:57 PM]
Cool. I’ve found a way to turn a boring marketing task into a fun programming task. Perfect.

jasoncoleman [3:57 PM]
:simple_smile:

squarelines [3:57 PM]
Livin’ the dream.

russell77 [3:57 PM]
lol

jasoncoleman [3:57 PM]
Any thoughts on Multiple Membership Levels Per User Work Arounds being the webinar topic? Or others?

squarelines [3:57 PM]
Upthread, I said it’s a good plan. But that’s just me.

russell77 [3:57 PM]
+1

jasoncoleman [3:58 PM]
Cool cool.

squarelines [3:58 PM]
Thanks for having these chats, Jason. They’re helpful, even if we all wander around a bit.

jasoncoleman [3:58 PM]
Thanks. Yeah for sure.

jasoncoleman [3:58 PM]
The Cold War Kids album just finished. Nice timing. Anything else before we wrap up?

squarelines [3:59 PM]
Not from me!

jasoncoleman [3:59 PM]
I know I get a ton out of these. Hope y’all find them useful too.

russell77 [3:59 PM]
@squarelines: at least some of us wander around (guilty) but not a square line!
:no_mouth:1

squarelines [3:59 PM]
@russell77: I always know where I am that way! :simple_smile:

russell77 [3:59 PM]
thanks everybody

jasoncoleman [4:00 PM]
I’ll call this the official end of the dev chat. Thanks again. Talk to you all later.


Comments (2)

Leave a Reply

Your email address will not be published. Required fields are marked *