Check out the new screen-cast titled Using PHP Tags in WordPress Screencast. Here I do a brief overview of the PHP WordPress Template Tags that are used in building WordPress themes. This screencast was created for Learnable. Learnable, is SitePoint’s sister website for learning web design/web development.
OK, WordPress Designers and Developers. I finally have figured out how to use the new Dashicons. If you do not know what the Dashicons are, go to the website here. With WordPress getting a nice overhaul in the admin theme, Dashicons are used throughout the new admin theme. So I just got finished making a new plugin which required a custom post type. So I wanted to give the new post type a cool new Dashicon then the default pin. So here are the steps:
1. In the custom post type script where you normally state the menu_icon this is what your syntax will be (see highlighted line # 22):
function create_orl_books()
{
register_post_type( 'orl_books',
array(
'labels' => array(
'name' => 'ORL books',
'singular_name' => 'ORL Book',
'add_new' => 'Add New',
'add_new_item' => 'Add New ORL Book',
'edit' => 'Edit',
'edit_item' => 'Edit ORL Book',
'new_item' => 'New ORL Book',
'view' => 'View',
'view_item' => 'View ORL Book',
'search_items' => 'Search ORL Book',
'not_found' => 'No ORL Book found',
'not_found_in_trash' =>
'No ORL Book found in Trash'
),
'public' => true,
'menu_position' => 15,
'menu_icon' => 'dashicons-[book]', 'supports' => array('title', 'editor', 'thumbnail')
)
);
}2. OK. Now we know where to place the code correctly, how do we get the Dashicons? Go to the Dashicons website and find the icon that you would like to use.Click on the icon and go back to the top of the Dashicon home page and click on copy html. There you will see what the CSS class is and get that name and place it in the brackets on the menu-icon line.
3. Save your css page and then refresh your admin webpage and this is what you should see:
OK. This article ASP.NET 4.0 Website Fix for IE 11 will show you how to fix your websites that break in IE 11. This is for anyone that has discovered the new IE 11 User Agent String issue. This is for all web sites, applications. projects that are targeted at the ASP.NET 4.0 framework. The main issue is the new IE 11 User Agent and the bug in the 4.0 framework. I will describe what the issues is and then show the fix. It is easier than upgrading your web server and all of your ASP.NET applications up to the 4.5 framework. The 4.5 framework has the user agent string bug fixed. So here is the details:
First there is a bug in the ASP.NET 4.0 framework when it reads the User Agent Strings. Here is the article talking about this issue from Scott Hanselman:
http://www.hanselman.com/blog/IE10AndIE11AndWindows81AndDoPostBack.aspx.
The bug causes the Post Back functions to not work. So when trying to view our ASP.NET 4.0 website in IE 11 our site would not work. All of our Post Back functionality was gone. So I tried using the Microsoft magic line of code to fix this issue by forcing IE to emulate IE10.
Microsoft Magic Line of Code: <meta http-equiv=”X-UA-Compatible” content=”IE=EmulateIE10″/>
Well this did not work. It forced IE11 to display site in IE10 mode but it kept the User Agent String as Default which would break the site. I then opened up IE 11 Developer Tools and then switched the User Agent String to IE 10 and BOOM, Goes the Dynamite! It worked. The site Post Back functionality is working. So I knew something was wrong. It would force IE to go to whatever IE version I chose, but it kept the User Agent String at Default, thus breaking the website. Image 1 shows dev tools and the website in IE 10 with User Agent String as default breaking the website.
image 2 show dev tools and the website in IE 10 and me manually changing the User String Agent to IE 10 and the website works.
So after many hours of research, I found out that Microsoft changed the IE 11 User Agent String. This caused IE 11 to stay at Default for User Agent String because it has been confused by the change. It is what I found out about the new IE 11 User Agent String: This is from the Microsoft website:
Here is the user agent string from IE 11 on a Windows 8.1 machine: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
IE 11 on Windows 7 machine: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko
Older IE 10 Use Agent String Version: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)
IE 9 User Agent String Version:
See in the past, to identify Internet Explorer just search for the string “MSIE” in the user-agent string. If present, the browser is Internet Explorer. Now that is gone in IE 11. Also they added ‘Mozilla’ and ‘like Gecko’ in IE 11 User Agent String. This sounds like a Firefox browser.
Here is the link from Microsoft about the IE 11 changes:
http://msdn.microsoft.com/en-us/library/ie/hh869301(v=vs.85).aspx
OK. Anyway enough about the issue. How the heck do we fix this. One fix that I read was to upgrade from the ASP.NET 4.0 framework to the 4.5 framework. I figured out an easier way around this. OK, we need to create an ASP.NET folder named, App_Browsers. This ASP.NET folder is the one most unknown. Here is a link to read more about the App_Browsers folder:
http://www.shubho.net/2011/01/what-is-appbrowsers-folder-in-aspnet.html
Now we just add a file with the extension .browser in this folder. Place this code in the file and save. Restart your IIS server and it works.
<browsers>
<browser id="IE11" parentID="Mozilla">
<identification>
<useragent match="Trident\/7.0; rv:(?'version'(?'major'\d+)(\.(?'minor'\d+)?)(?'letters'\w*))(?'extra'[^)]*)"></useragent>
<useragent nonMatch="IEMobile"></useragent>
</identification>
<capture>
<useragent match="Trident/(?'layoutVersion'\d+)"></useragent>
</capture>
<capabilities>
<capability name="browser" value="IE"></capability>
<capability name="layoutEngine" value="Trident"></capability>
<capability name="layoutEngineVersion" value="${layoutVersion}"></capability>
<capability name="extra" value="${extra}"></capability>
<capability name="isColor" value="true"></capability>
<capability name="letters" value="${letters}"></capability>
<capability name="majorversion" value="${major}"></capability>
<capability name="minorversion" value="${minor}"></capability>
<capability name="screenBitDepth" value="8"></capability>
<capability name="type" value="IE${major}"></capability>
<capability name="version" value="${version}"></capability>
</capabilities>
</browser>
<!-- Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11,0) like Gecko -->
<browser id="IE110" parentID="IE11">
<identification>
<capability name="majorversion" match="11"></capability>
</identification>
<capabilities>
<capability name="ecmascriptversion" value="3.0"></capability>
<capability name="jscriptversion" value="5.6"></capability>
<capability name="javascript" value="true"></capability>
<capability name="javascriptversion" value="1.5"></capability>
<capability name="msdomversion" value="${majorversion}.${minorversion}"></capability>
<capability name="w3cdomversion" value="1.0"></capability>
<capability name="ExchangeOmaSupported" value="true"></capability>
<capability name="activexcontrols" value="true"></capability>
<capability name="backgroundsounds" value="true"></capability>
<capability name="cookies" value="true"></capability>
<capability name="frames" value="true"></capability>
<capability name="javaapplets" value="true"></capability>
<capability name="supportsCallback" value="true"></capability>
<capability name="supportsFileUpload" value="true"></capability>
<capability name="supportsMultilineTextBoxDisplay" value="true"></capability>
<capability name="supportsMaintainScrollPositionOnPostback" value="true"></capability>
<capability name="supportsVCard" value="true"></capability>
<capability name="supportsXmlHttp" value="true"></capability>
<capability name="tables" value="true"></capability>
<capability name="supportsAccessKeyAttribute" value="true"></capability>
<capability name="tagwriter" value="System.Web.UI.HtmlTextWriter"></capability>
<capability name="vbscript" value="true"></capability>
</capabilities>
</browser>
</browsers>
Here is the link where I found this nice piece of code: http://stackoverflow.com/questions/18244223/webform-dopostbackwithoptions-is-undefined-in-ie11-preview/19585664#19585664
OK, Everyone. Do not FREAK OUT yet. Yes, IE 10 Drops Conditional Comments. What is up Microsoft? What does this means to web designers and developers that have to support IE. It just means the old way of conditional commenting to target a specific IE version and then use a IE specific css stylesheet will not work. For example, the old way:
<!--- code for using different IE stylesheets --->
<!--[if IE 8]>
<link rel="stylesheet" type="text/css" href="http://library.utsouthwestern.edu/css/ie8.css" />
< ![endif]-->
<!--[if IE 9]>
<link rel="stylesheet" type="text/css" href="http://library.utsouthwestern.edu/css/ie.css" />
< ![endif]-->
So here is the new way that I found that worked great for me.
In my main stylesheet, I use a media query to set the IE specific css style as such:
/**** IE 10 sepcific styles ***/
@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none)
{
#footer {
width: 525px;
}
}
You can still use the old way if you have to support older versions of IE(7, 8, 9). But no dice for IE 10. For more information regrading this new issue check out this great article at SitePoint by Craig Butler.
So, for those new to Cold Fusion or maybe someone that have not ran across this issue before, here it is. Cold Fusion cfforms tag automatically injects javascript code into the head of your webpage. Most of the time this might not be a real issue. But if you are like some us out there that still have to deal with supporting older versions of IE, then this can be a real headache. OK, here is the problem that I ran into and would like to share this to hopefully save someone else some precious time that I spent debugging.
We are redesigning our Cold Fusion website and decided to use more modern design elements such as HTML 5 along with a responsive design for our users with more up to date browsers. Now the problem is IE 7 & 8 has this dumb thing called compatibility mode. As IE looks at the webpage and it does not recognize doctypes and other things that are not compatible then it gets pushed down and the webpage is then displayed in the lower IE versions. Of course, older versions of IE does not understand HTML5 so if a user has compatibly mode enabled, it will break our new beautiful responsive website. Another thing in IE, is that if the website is considered an intranet site, it will automatically enable compatibly view. Working in an academic setting, our website is viewed on campus gets pushed to an intranet site. Off campus, it is not an intranet site. So as you can see our dilemma. But wait, there is a fix. There is a line of code that must be placed in the head of your webpage that will disable compatibly view and force IE to render the webpage in whatever IE version you are using. EXCELLENT! Here is that magic line of code:
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
There are many articles out there explaining this line of code so I will not go into details. So our problems are solved, now whenever someone views our website using IE 7 or 8, IE will stay in IE 7 or 8.
“STOP THE CLOCK”. After placing this code in the webpage’s header, it is still not working. What the heck. After doing many hours of research, I found an article that stated that this line must be placed right after your head tag. OK, no problem. I then placed our magic code right after my head tag. OK. this has to be it. But unfortunately, no luck. Still does not fix our issue. What is going on, I then looked back at the page source view and I see that javascript code from the cfform tag being placed right above my IE magic line of code. I start to scratch my head and said maybe this is causing this issue. So I disabled my cfform tag and guess what. BOOM, THERE GOES THE DYNAMITE! It worked! So now I have figured out the cause and now I need to find a fix.
There are a couple of different ways to fix this. One, DON”T USE the cfform tag. Use, regular html form tags. So for our main searchbox on our home page, I had to convert our cfform to normal html form tag. But that only solved our header section. Since this form sits in our header file and all of the rest of our hundred of pages call that same header file, then most pages are fixed. NOT SO FAST! This solved most of our pages except our Forms section.
We have a Forms section on the website that has about 20+ online forms. Do we really want to change all of this forms from cfforms to normal html forms(We have some very detailed forms using some special cfform tag options, cfform binding and heavy javascript) . But doesn’t that kill our point of using Cold Fusion. We choose to use Cold Fusion for all of its greatness and its many tags, that save us many hours of coding time. So how could we fix our code on all of our online forms, to take advantage of the greatness of Cold Fusion and its cfform tag but fix our IE issue. What we did was just re-code our forms and actually did a bit of hacking.
We hard-coded these two lines on each form page
<!doctype html>
<meta http-equiv="X-UA-Compatible" content="IE=edge, chrome=1"/>before we call our main header file. Of course this is not very good coding in terms of semantics and validation, but we need the forms to work in all browsers and having to support older versions of IE, sometimes there is not much you can do. So now all of our Form pages use the cfform tag and all display perfectly in IE 7 &8.
To wrap this up, I am writing this post to hopefully have this land into the hands of some CF Developer and will hopefully save them many hours of debugging research. This might not be the only way to fix this issue but this is what we did to solve our issues.