List of quick qustions A – R

[Eyal Fitoussi]

Wow,
That is a “bit” of information. But seriously , thank you for all the input but it is after 1:00 am here and my brain cannot process anymore. I’ll leave that for tomorrow and see how i am going to fix all the issues.
Thanks again.

[intervik]

After a good night sleep here, we goona get started to implement this plug. Please wave to us about the upcoming changes you decide to approach so we can plan the core changes.  / testzips. We are happy all the support you are providing here at your forum. I understand that a development come’s in Waves…

The thing is that once we go, the whola search master engine will work from this plugin instead of the BP profile search plugin.

And if the xprofile fields are released, and only need to provide our objectives with just City + Country, we can grab the meta coords without the ip stuff and use that as current location sitewide base. Then , whenever user will fine tune or totally be NEAR by another lat long, we create a new widget and feed the IP stuff away.

Everyone is very happy with this plug and your release, and as mentioned, it might be a very wide usage and build a wide client base for you.

[Eyal Fitoussi]

Hello again,
Reading trough everything again with a fresh morning coffee Made me understand it better. There is very good input that I am going to take and use to improve/fix some thing on the plugin. I started it as a small project that I guess getting bigger and more users. Concentrating more in adding new features than improving its base an functionality was not a great idea. But also didn’t have that many bugs reports so I was assuming that the plugin works good. Now need to start fixing the issues you are having that will target most of the outside of the US users. Things like encoding, states and zipcode you were right about. It works differently and causes errors when they are not found.
I am still thinking for the best way to reconstruct the “location” tab. I know it is confusing and might cause problem with the average users. That is way I added the feature that can turn it off. I am not going to remove it. And the slug for it is wppl-location.

The only thing I don’t think should change is the integration between profile fields and the location tab. Basically they are the same. At the end of the functions they are both saving the info into the database and when pulling it from there as well. Having one address in location tab and other in the profile fields will cause a mess and confusion.
You are having error with the integration between the two above because of the address fields. State and zipcode that are different in you country. So when the function looking for those variable and cannot find it it give errors and the data is not being transferred correctly.

I will need to reconstruct some elements in the plugin to make it work best worldwide and not just in the US.

I’ll keep you posted and probably will user your help.

Thank you

[Eyal Fitoussi]

One more thing. Made few changes in the locate function in my demo site. Would you give it a try and see if see any deference ?

[intervik]

Hi,

Gonna check your site.

The critical fix rigt now from above might be to be able to only feed filled in id values/ sync in admin. As long as City and Country are synced, I think we survive a portion of the road – whatever country. Still The profiledata is Location, and Your plugin deals with Public location. The userfield should not be a switcher for current locations. (Se part of below, the blockouted)

Im gonna email part of an article I wrote when projecting a Look-me-APP . Its bus-reading or coffe break, but It clear out a little – decide what to build – and marketing the plugin (APP).

This part is what I think is important when it comes to SAVING profile data FROM another TAB:

In community projects, like Facebook, datingsites or shools, there is always a Location : Address / Home / Official value. Mostly Country – City and thats a good start for account register process. It accepted as privacy level. Any locate system should start to work from here – and scale down the proximity step by step from the user actions. No autosuggest with street levels in the beginning or in this form.

The Official location value works as a Fallback, base for any location functionality. No Ip or cookie should override this. This is the first keyhole for any MAP API functions. It’s static and probably saved only one time by the user. Dont use this field be a location switcher – it makes the owner uncomfortable in her membership

 

 

A pice of the article, in case someone else working with the same thing :

The problem or the architecture of Location services.

The basic, always 2 locations: Home or Gone.

A) Where the user lives
– stationed (office, datingsite, shool) = residence / Home = Official location = or just “Location”, typically stored as profile data.

B) Where the user is right now
– visiting (services, dating, friends, consert areas, camping) = Places = Check ins = Current location

The problem, the Wife – I am official home or public Gone?

– Location (Official)
– Current location
– Public location
– Hidden location
– No location

To work with this scenario, you need at least 3 values, stored in : Location, Current location and Public location

Location and Current location can be either “my Public location” or ACT like / become Hidden location – Its just a temporary statement of any of both values. But Only One can be set as Public location. Both can be hidden and get the status of No Location. Then you cover all 5 locations.

All 3 cases will be active in THE SAME TIME in a typical Buddypress community website

The value in the Public location is what API should work with, when
– another User look at a member NEAR BY widget or proximity search a member.

The Current location value is what API should work with when
– the Owner look at a NEAR BY widget or proximity search a member.

The Official location value is what API should work with when
– all users including yourself are looking at your profile home, CV or contact me pages.

[intervik]

Checked the site, no changes.

Mailed a picture from FF, but I using a XP version for debugging FF so not shure it this bad. The Chrome just pushes the padder container and the opera seems fine BUT I can see that the space is missing above id container / below header navi

/ We hate when this stuff appears

[Eyal Fitoussi]

This is interesting. And sure you can email the article.
The things is and this is if I understand your points above that the plugin right now have only one type of location which is te official. Which I guess also makes it as the public location. and The location tab as well as the profile fields representing that same location. So the widget actually shows you people that live or work near your current location but not their current location. Thier current location is not saved anywhere in database but only in cookies.
I believe that you are looking for the checkin feature. So people actually check in their current location which this data is being saved in the database and the near widget will display the members based on that checked in location.
So if I assuming that this is the case you are looking for so I was thinking about adding the feature. But:
1) I found the checkins plugin which I find very good and usefull. So I was thinking to dig and try to integrate them both.
2) if I do add the feature. Where I will save the checked in data? Databse probably. But for how long? How do I know when the user leave the checked in place? How will I remove it from the database.
All of that will make the nearby widget display members that maybe not there anymore.

I hope understood you and the above gives you better look. But please feel free to suggest further.

[intervik]

Yea, above is little out of context. But it shows the complexibility for both of us – me as the user / site dev and you as the producer / function dev.

I already using checkins, and imath is using

– meta table (id, lat,long) storage for Current (latest) location
– activity stream for check in history / older / streamed
– leaving xprofile alone

Means (I think) using 3 field in the user meta table instead of cookie

We got directions and gonna feed your plugin with location data – in later step. Imath’s BP checkins is only dealing with Current Locations, no proximity search – or Near By. OR Official Locations

Example

my Public location = my Current location
my Public location = my Official location
my Public location = my Hidden

When Official location set to Public :

– Your plug shows xprofile data – for others –
– – on reults map => where I live
– – Near by widget calculated from => where i live
– Your plug shows YOUR data – for me –
– – on reults map => where I am
– – Near by widget calculated from => where I am
– My profile home CV or Location => xprofile data ALWAYS

When Current location set to Public :

– Your plug shows YOUR data – for others –
– – on reults map => where I am
– – Near by widget calculated from => where I am
– Your plug shows YOUR data – for me –
– – on reults map => where I am
– – Near by widget calculated from => where I am
– My profile home CV or Location => xprofile data ALWAYS

When Public location set to Hidden :

– Your plug shows YOUR data – for others –
– – on reults map => nothing
– – Near by widget calculated from => nothing
– Your plug shows YOUR data – for me –
– – on reults map => where I am
– – Near by widget calculated from => where I am
– My profile home CV or Location => Nothing

The ACTIVITY stream Shows BP CHECK-INS history, and so on – if activity stream is in use. If not, There is not a solution to use that plugin. Yours are, as a base. We cant toggle plugin on or off – we loose recordings. We need a MASTER.

When BP checkin is active we can :
Retrive the meta Latest check in pairs and feed your plugin if / when :
– Current location is public instead of your data (optional)

BUT HERE IS THE TRICKY / SOLUTION

The members Home / CV or Xprofile City is HOMETOWN – New York, But the member works in Rio, Brazil for 4 month, and will be found there. Your data is used as Current location “City” = “Rio”. While this member is in Rio he will CHECK IN to a fotball game, a carneval area or the apartment. USING BP CHECKIN DATA = Shown in the activity stream.

The People back in New York and connections will still find this member as a living New York citizen, local and US services and so on. In search and near by – The missmatch between Public set and Current set and Official set location decide / calculate this. THATS WHY XPROFILE LOCATION MUST STAY INTACT.

I mean, The near by widget can be feeded with the checkin data or Your data – depending on YOUR PAIR missmatch with CHECK IN PAIR, and can AUTOLOCATE SUGGEST the member / services / datings / reminders etc etc

AT THE SAME TIME, Our Sponsors or advertise Rio-widget can choose from YOUR Current location or Check in location WHATEVER or not A PUBLIC Location is set.

Ieeeeep!
Thats why your plug is important, and BP chekins do the stream

[Author]

Posts