51 Degrees Mobi keeps doing unwanted redirects. How to stop? - redirect

I just recently installed the 51 Degrees Mobi Nuget packages to Visual Studio 2015. I have come across an annoying feature that I am not able to figure out how to turn off. When I browse to my site with a mobile device, it automatically redirects the device to /Mobile/Default.aspx.
I don't want this. I want the device to go to the requested URL. Per the documentation found Here, it says
This element determines how mobile devices should be redirected. If it is omitted, redirection will be disabled.
This is simply not working as described. I have removed that element in the 51Degrees.config file along with its SectionGroup, yet this unwanted redirection continues. How do I actually disable this annoying feature?
Thanks

Ok, a little less frustrated now and can think a bit clearly. I read in another post about a cookie being set with a redirect value. After I cleared the cookies on the clients, this problem went away.

Related

Enforce HTTPS not available on GitHub

I was able to have HTTPS but just recently I cannot create an HTTPS website. Is there anyone familiar with Namecheap and GitHub Pages that has either overcome the issue or can help?
Namecheap
GitHub Pages
CNAME
404.html
index.html
Thanks to #VadimKovrizhkin for asking. Yes, I do remember now.
Step 1
(I did not try this, but it is definetely related to the problem)
Try disabling all extensions. If the checkbox is enabled, re-enable all extensions one-by-one to see which one it is. If you find which one it is, you may not need to permanently disable it.
The extension may have settings/preferences. For example, mine was an ad-blocker. I went to its preferences in my browser settings. Then, I disabled it on the specific site I wanted.
I have not tried this out on this problem though.
Step 2
If that did not work, here's what helped me enable the checkbox.
This step is very simple.
Go to the "Pages" section (or wherever the checkbox is)
Lay your cursor over the checkbox.
Right click, "Inspect Element", and go to the element manually if it doesn't automatically.
Find the attribute on the <input type="checkbox"> element called disabled.
Completely delete that attribute from the element.
The checkbox should be enabled again.
The reason it may not be working
It looks like this issue has not been fixed yet.
I can tell because I ran into this problem a few days ago setting my domain.
I did the inspect element trick and it works great.
The reason it may be doing this is browser support, or an extension(s) that may be breaking the site.
Other GitHub users have had browser support issues on Firefox and Chrome (maybe other browser too).

Can’t submit file for Facebook App Approval

I’ll set my outrage with the way this process works (to whom can I speak?) aside for the moment: we are attempting to provide FB with a link to our ~200 mb app for approval. We have been rejected 3 times because they are incapable of extracting our zip file (they request a zip for some unknown reason — it has minimal size impact).
Some detail: we are linking to the zip on our Dropbox. We have removed all punctuation from our app title (Pandamonium!.app becomes Pandamonium.app). We have eliminated spaces from our source folder. I thought all these could be causing a problem with iOS-sim.
I’m not sure what is left to do, but I am hoping someone can present a clear set of instructions (NOT THEIR INSTRUCTIONS, WHICH I HAVE READ) they have followed particularly if you have met similar snags or ANY ideas for resolution. All they send me is useless screenshots of their simulator unable to open the app which I have simulated and opened successfully daily with iOS-sim for the last week.
After a great deal of trial and error I found that using Facebook's command-line instructions was what was causing the issue. You should just compress your .app file in an ordinary fashion (right click and compress -- I used a Windows computer just to make sure everything was copasetic after reading about bizarre Mac .cbgz compression issues).
Regardless, in summary, I can now see why no one else has had an issue with this: it's because no one reads their instructions and rather just creates their .zip files in the ordinary way; unsurprisingly, you're better off using your common sense rather than listening to others.
Aside: ironically, after being told my use case was fine and the only issue was not being able to unzip, Facebook (India) has now told me they couldn't find my login button (which is gigantic, in multiple places, and clearly described in my instructions). This process is an absolute joke. I wish anyone going through this hell good luck.

Strange Robots.txt update problems

I have a strange robots.txt issue.
I update my robots file regularly without problem, until some days ago. Now, when I update the robots via a FTP folder it appears to update. If I view it from a browsers, I only see the old version. Even Google doesn't update it, after several days. From Google's search console I see this:
On the left you see what I see in my browser and what google sees. On the right you see the real file, like it appears in ftp. The last 5 lines are different.
If it matters, I use Google's DNS servers. When I change the DNS on my PC connection to my Internet Service Provider's DNS, I see the new robots file, but google still does not.
Had the same issue, as my robots.txt wouldn't show correctly to Google in days. It can take a while for Google to crawl your site and check your robots.txt - sometimes its done right away, sometimes it can take up to a few days. I would suggest you to wait for a while and check again. Maybe even try from a computer with a different network (or a mobile network).
I recommend that you try and upload (if you haven't already) your file to Google for faster crawling. Check out this link - https://support.google.com/webmasters/answer/6078399?hl=en
the problem was with the cloudflare cache.. Flushed it the problem was solved

Joomla 3.0 SEF URLs sending to random wrong articles

My site eighttwentydesign is running Joomla 3.0. I have SEF URLs on, and have done for sometime without issue. But today when you go to the site, and click on anything, say portfolio you get the home page under the portfolio's URL, but if you add a leading slash at the end, the right article (portfolio) shows. Additionally, if you click on say "Web Design" it sends you to the Portfolio page. I might add this menu is a menu within Joomla - not be adding internal links manually
Doesn't work: http://www.eighttwentydesign.com/portfolio
Does work: http://www.eighttwentydesign.com/portfolio/
I have checked the .htaccess, and actually reverted it to the original with no luck, I have check Global Config but I can't see anything which may cause this. It was working nicely yesterday. I haven't adapted with any PHP source or anything in the past few weeks, the only notifiable thing I have done is yesterday enabling the Cache - have others experienced problems after doing this? I have disabled it under global config, with no avail.
Exact Joomla Version is 3.0.2 with very few plugins
I do have daily backups, but would rather a solution and be able to figure out a prevention from that, rather than just putting on a band aid.
I've search for a good couple of hours, and aside from just not being able to fix it, it appears no one else is experiencing this, so I am starting to think it may be a bug.
Just as I was about to post this I discovered my solution.
If you are having your SEF URLs display the wrong content then solve it by disabling the Cache plugin. You can do this by doing the following steps
Login to Joomla backend
Navigate to Extensions > Plugins
Go to "System Cache"
Disable system cache
I hope this helps someone in the future as I really struggled to find any answers on this.

Benefits and concerns with Google Chrome Frame

Is this a technology I should spend much time evaluating?
http://code.google.com/chrome/chromeframe/
Chrome Frame is a plugin for Internet Explorer (IE6-IE8) that gives it, well, what all the other major browsers have.
Biggies for me are the Canvas tag and a fast JavaScript.
As I do a lot of JavaScript dataset visualization, IE6 is a perpetual thorn in my side, and I often have to write extra code for it, and I often have to slow down the frame rate of user-driven real-time visualizations. Using Google Chrome Frame will allow me to produce a much more responsive experience for IE6 users.
But I wonder if IE6 users may be in situations where their computers are under some kind of IT lockdown hell where they aren't even allowed to install a plugin (why else would they be using IE6?)
So I'd still be left with what to do with the last poor souls in IE6.
Still, IE8 lacks Canvas and the JavaScript is slow, so some of my users would see increased performance, maybe even up to Google Chrome and Safari levels.
So again, my real question: Is this a technology I should spend time evaluating?
Note: Google will be throwing up alerts to IE users to encourage them to download Google Chrome Frame for Google Wave. So maybe Google will get enough Google Chrome Frames out there on IE machines that I can just detect it and use it if it's there, and warn the user that experience may suffer without it. I hate to demand anything of my user. http://googlewavedev.blogspot.com/2009/09/google-wave-in-internet-explorer.html
Given the visualizations you're working on, I'd definitely evaluate it. The potential upside for you as a developer and for your users is significant. You do not have to force all Internet Explorer users to use Chrome Frame. You can simply include the meta tag and the users that choose to install the plugin will almost certainly have a better experience.
That said, in my evaluation of Chrome Frame I have encountered some pretty big caveats that might be showstoppers for your project:
Older versions Chrome Frame can't print (see bug list). Depending on what kind of visualizations you're doing, this might be a real deal killer.
Downloads work but appear to the user like nothing has happened (see bug list again).
Chrome Frame is basically the Google Chrome browser shoehorned into the IE browser chrome. As such, any interaction with the browser inside the frame is with Chrome, not IE. If you right click and select Inspect Element you will get the Chrome developer tools window with its Vista-like look and feel. You'll need to make a judgment call as to whether your users will be comfortable with that.
In my testing, it appears like Chrome Frame is only looking at the meta tag:
<meta http-equiv="X-UA-Compatible"
content="chrome=1">
I was unable to get Chrome Frame to activate by setting the X-UA-Compatible HTTP Header as you would with EmulateIE7 mode:
Header set X-UA-Compatible "chrome=1"
It is also worth noting that this meta tag will override EmulateIE7 mode if you have that setting configured and I believe the inverse is also true too. They are both setting X-UA-Compatible. The last tag to set this will take precedence.
One power testing tip that will help save you from having to go in and edit your pages, is that you don't have to do anything to your site to test it with Chrome Frame. Once you have the Chrome Frame plugin installed in IE, simply prepend gcf: to the any URL and it will load it in Chrome Frame (e.g. gcf:http://dshaw.com ).
Happy coding,
- #dshaw
Think you should really spend some time on it since i just tested it and it works very well !
It gives you ie6 with the chromium speed !
And google will surely have enough power to spread it a little. Also you can advice your users to install chrome frame for your application if you really need it.
If you can install flash on ie6, you'll be able to install chrome frame.
Some users that can't install google chrome, will be able to install chrome frame.
I agree with you when you say that you don't like to demand anything of your users. That's generally a good philosophy. I would recommend evaluating how much you need the Canvas and how slow JavaScript really is.
Considering that IE is still the most popular browser (well, the most widely used, anyway), if your web-application is going to be used, you have to take IE into account (as you already are). The real question to ask is, "How much is the user's experience going to suffer if they use IE 'as is'?" If it really will degrade performance, and it will hurt your user base, then, yes, I would check out Google Chrome Frame.
I think it is a good alternative to sites which are considering not maintaining support for IE6.
Recently some big sites stopped working in IE6, they could ask for chrome frame instead of showing you can't access that site in your browser.
Is something good also for improving performance for google chrome frame users.
I'd say no. It is a waste to spend time evaluating it.
Whoever can and want to install extensions to IE6/7/8 can and should install a modern browser (Firefox/Safari/Chrome). The benefit would be both better performance and better support of standards across the board, more than a plugin for IE can provide.