I've managed to develop some code in php which would use a mobile template instead of the default one, however I'm not sure if I should redirect to a mobile URL (such as /mobile/) or if it's ok to just have the mobile template showing up instead of the default.
Any thoughts on this?
This is up to you.
Some sites put there mobile view on its own domain, e.g., m.yourdomain.com or yourdomain.mobi, and if a mobile user arrives at your non-mobile site (and are detected via agent-string) they'll be redirected to the mobile domain.
However, Tim Berner-Lee states:
It is fundamentally useful to be able
to quote the URI for some information
and then look up that URI in an
entirely different context. For
example, I may want to look up a
restaurant on my laptop, bookmark it,
and then, when I only have my phone,
check the bookmark to have a look at
the evening menu. Or, my travel agent
may send me a pointer to my itinerary
for a business trip. I may view the
itinerary from my office on a large
screen and want to see the map, or I
may view it at the airport from my
phone when all I want is the gate
number.
There's something to that. This seems to prefer a non-redirection approach but, instead, detecting the agent type and displaying the appropriate view.
Which approach is better is up for debate.
You could combine the approaches by having your main site respond with views based on agent type while also placing content in a mobile-specific domain (not duplicating it, just mapping the additional domain to it), which will allow phones that don't send a mobile user agent string to view the lighter mobile site.
Both approaches are equally valid. Just make sure, for usability sake, that you give the user that ability to switch between the two views and make it sticky. That way, someone on their iPad doesn't always get the mobile template and someone who gets a url to the mobile site can switch back on their desktop.
Related
Okay, so when you post a link on Facebook, it does a quick scan of the page to find images and text etc. to create a sort of preview on their site. I'm sure other social networks such as Twitter do much the same, too.
Anyway, I created a sort of "one time message" system, but when you create a message and send the link in a chat on Facebook, it probes the page and renders the message as "seen".
I know that the Facebook probe has a user agent of facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php), so I could just block all requests from anything with that user agent, but I was wondering if there's a more efficient way of achieving this with all sites that "probe" links for content?
No there's no fool-proof way to do this. The easiest way to achieve something like this is to manually block certain visitors from marking the content as seen.
Every entity on the web identifies itself with a user agent, although not every non-human entity identfies itself in an unique way there are online database like this one that can help achieve your goal.
In case of trying to block all bots via robots.txt, not every bot holds up to that standard. I will speculate that Facebook may try to prevent malware from being spread across their network by visiting any shared link.
you could try something like this in your robots.txt file
User-agent: *
Disallow: /
I'm building a product that involves clients adding their FB app data into my product's dashboard.
In this case each client would have to go to developers.facebook.com/apps and create an app first.
I would want to have a button which says "Create App" in my website that when clicked, would create the app instantly for the client.
So is it possible to create a FB App from my website (with script, not manually) ??
Thanks in advance,
Altin.
It was possible couple of years ago, and now it's been removed.
First of all, I’d think about the question, “does every client really need their own app?”
Maybe it’d also be possible to have all of the stuff you’re planning to do (no details on that) under one app, and have it decide on what data to show based on the fact which client’s Facebook page it gets added to (if it’ll run as page tab app), or by some additional parameter passed to it when calling it. You could f.e. example automatically redirect to a sub-folder on your webspace based on this criteria, that displays individual pages for that client.
If that’s not an option, then yes, your clients will have to set up the basic app themselves (and therefor they’ll need a verified account) – and afterwards tell app id and secret to you. Many of the “advanced” app settings can then be set by you via script – look at what properties are marked as “(Editable via API)” here: https://developers.facebook.com/docs/reference/api/application/
(Although some of the basic settings, like category, description, logo etc. will still have to be set by your client themselves. But other, more “technical” stuff, that the client maybe doesn’t know about and doesn’t even want to be bothered with, like canvas/page tab URLs etc. can be set by you. I’d say that’s as good a compromise as you can get for such a scenario.)
I had a potential client ask me if I can prevent a user navigating away from their website within an iPad app? So I would need to load the client site within a web view and somehow disable invalid links i.e. banners and promotional links.
I am wondering if there is a way to catch the link that has been touched within the view before it is loaded.
If there is no way to do this, is there away to strip a web page of invalid links before it is loaded into the web view?
Use UIWebViewDelegate method webView:shouldStartLoadWithRequest:navigationType:. It's called when user taps a link. Return NO if you don't want to handle any links or YES if you want your web view to handle the request. More info in Apple docs.
A nice thing is to filter out some requests and handle them yourself based on e.g. URL-scheme of the request or based on UIWebViewNavigationType value. Note: for a filtered requests that you handle, you still return NO.
I am a web developer and I want to design a commercial website to sell a customer's product. Sell and buy activities are important and I need to maintain user activity information to keep the site secure.
I want to write a dynamic website. I want to control all user activity and then decide whether to save user activity information in a database. Some of site's visitors are registered users and some are anonymous. I want to save online information such as ip address, username, page name, and date/time for my registered users.
I want to know:
How do I save a user's IP address?
What more do I need to save?
Saving each HTTP request details into database will work for low traffic web sites, but you will have performance issues in case of popular website, since writing to database in relatively slow operation.
Why not to use server HTTP logs instead?
All HTTP web servers create plain text log files which record remote user IP address, URL requested, etc. You can create activity report by writing your own script or using log file report tools. AWStats ( http://awstats.sourceforge.net/ ) is one of the most popular open-source tools for this.
On client side you can use Google Analytics to track user activity. It also provides means to track custom events:
_gaq.push(['_trackEvent', 'login', 'user_login', "custom data"]);
More info at: http://code.google.com/apis/analytics/docs/tracking/asyncUsageGuide.html
This option only tracks users with JavaScript enabled, so it won't show bots, crawlers or users having analytics blocking addons installed.
I'm not sure I understand all of your question...but to address at least one aspect of it, if the user is behind a proxy, then you have no way of determining what their real IP is. That's the whole point. The proxy is the one making the request and then forwarding it. Without asking the proxy yourself, you cannot determine that. With regards to what else you need to save, it depends entirely on what you want to do and you haven't done a good job of explaining why you are saving this data. If you can clarify that, perhaps we can help you a bit more in determining what data you should be saving.
Edit To address your clarification, if you wanted to be crazy, you could log everything that a person does. Every link they click, every product they view, etc. I don't necessarily advocate that as I find it a bit creepy, but there are definitely sites that do it. At the bare minimum, I would suggest logging what products people look at and then what products they buy. I would also log that information on a per-session basis. Basically, what products do people look at and then end up buying on the same trip to your store. I wouldn't worry too much about the "real" IP address. Most people won't be behind a proxy and those that are, you can't do anything about anyway.
How do I save a user's IP address?
$_SERVER['REMOTE_ADDR']
What more do I need to save?
That's quite strange question. It's your application, not someone's else. How can we guess what information you need?
However, at least one issue I can point out: a page name is not sufficient to log "all user activity". Query string and POST data usually contains important details on that activity.
For my Social Networking Site, I would like to build a facebook, or twitter similar URL rewriting naming convention.
Using Twitter as an example, they have pages labeled twitter.com/about and another page labeled twitter.com/{$username}
However, how do you differentiate between say a user who has registers on to our site as "about" then. From this we are going to have a server conflict between the user "about" and the page about.
What is the best way to handle this?
Usually, you'll see this implemented so that conflicts are not possible. For instance, you could camp all users inside a virtual /users directory, or a subdomain: mysite.com/users/msilvis, or users.mysite.com/msilvis.
I would not recommend that you make all users accessible via the root directory of your site, because this could potentially restrain you from adding pages. For instance, suppose you do not have yet an "about" page, but a user registers and calls itself "about"; you're screwed.
If you still choose to do so, before registration, try an HTTP request to your website to the page the user would have. If you don't get a 404, then something already has that name.
What our final decision came down to, was upon requesting a page on our server mysite.com/user, it first checked to see if that was a page, if it IS NOT a page, it assumes that it is a user, in which case it checks to see if that user is an object, if it is not then it gets passed to our 404 page.
So ontop of this, we are going to use the HTTP request like you mentioned earlier, and then if some how user "about" still signs up which we now have a page for, essentially sucks to be him because he is not going to see his page.
I would restrict the ability for someone to create a username that would conflict with existing urls.
If you're still in the early stages of development, you could look at the Kohana PHP framework. It's routing features solve the problem highlighted by zneak and dd, you would simply define in your routes that http://yoursite.com/about would point to a particular controller/action, i presume you're using the MVC design pattern considering you want a twitter like url structure.
Hope that helps!
EDIT: I forgot to mention that this doesn't stop people from signing up as about, it would just prevent the rest of the world from being linked to that persons page, in order to prevent them you'd need to employ some kind of validation against your core pages aka about, contact ect.