Scenario:
I have a variable within the front matter of every blog post which looks like the following:
---
icon: ☕
---
When I display a list of blog posts I reference this UTF-8 character
{% for post in site.posts %}
<span class="icon">{{ post.icon }}</span>
{% endfor %}
I build the site locally, check localhost:4000 to make sure everything is fine, and then push to GitHub. My site is hosted by GitHub Pages and GitHub will build the site every time I push to master.
Problem:
The site looks fine when I build it locally. I can see the UTF-8 character displayed and when I check the source of the page it shows a span tag with the UTF-8 character.
<span class="icon">☕</span>
However, the UTF-8 character is not visible on the website built by GitHub and the UTF-8 character is not within the span tag
<span class="icon"></span>
I have double checked and made sure that I have pushed everything to origin. Why is my UTF-8 character missing?
EDIT: I have solved my problem but I still do not know why it was happening. I think knowing why GitHub is failing to properly parse the front-matter is worth knowing and I will keep this question open until someone is able to find out
It would seem I needed to surround my front-matter UTF-8 characters in quotes:
---
icon: "☕"
---
I also had to enclose every other front-matter variable in quotes, despite not needing to before adding the icon variable.
---
layout: "default"
icon: "☕"
---
I am still not certain why the unquoted UTF-8 character will work locally but not for GutHub.
Related
I have been using Jekyll and a Jekyll theme for my blog hosted on GitHub Pages. I haven't blogged in a few months, and today, before pushing to GitHub, I ran jekyll serve and received multiple errors, including:
Deprecation: The 'include' configuration option must now be specified as an array, but you specified a string. For now, we've treated the string you provided as a list of comma-separated values.
I also received another error:
Error: could not read file /Users/JakeWengroff/blog/pages/_posts/2016-07-28-blog-title.md: (<unknown>): mapping values are not allowed in this context at line 5 column 71
And when viewing my blog with localhost:4000, the newest post does not appear but all past posts do.
Despite these errors, I pushed the new post to GitHub, visited my blog's URL, and the same situation occurred: my most recent post does not appear, although all previous posts do.
I do know that Jekyll recently upgraded to v.3.2.0, though after reviewing the documentation, I could not seem to find any changes that address my error today. I also checked the Jekyll troubleshooting pages and again, I could not find anything that would address this issue.
The upgrading from Jekyll 2 to 3 page suggested adding future: true to the _config.yml page. I did that, and still, nothing.
Any help would be greatly appreciated. Thank you!
For your first error:
In your config file, change
include: _portfolio
to:
include:
- _portfolio
And for your second error, change this line, from:
summary: Data scientists do not usually create their own algorithms: what a relief.
to:
summary: "Data scientists do not usually create their own algorithms: what a relief."
Note that I just put the line in quotes because you've got a colon in the value, which Jekyll uses to differentiate between keys and values in front matter.
I'm debugging a XUL-based Firefox extension which has been broken by Firefox 46 release.
When I run the extension, the Browser console shows:
Invalid chrome URI: /
with neither line numbers nor stack trace.
On Web forums, I've read that ChromeBug could be used for that. Then, I've tried the latest stable version of ChromeBug (1.7.2) but it hasn't been updated since oct. 2014, and seems to be incompatible with recent Firefox versions.
Because the extension is an "old-style" one, I cannot use the Add-on debugger, therefore I used the Browser toolbox, but it doesn't display the exception.
Considering the number of lines of the extension, wandering around in the code is not an option. Any idea how I could get a stack trace?
When getting this type of error in the Browser Console where you are given very little information as to what is causing the error it is likely that the error is not in JavaScript, and probably not even inside your code. In such cases, it is impossible to obtain a JavaScript stack trace because it just doesn't exist.
Such a thing is usually caused by issues in XUL or HTML used in a popup or tab that is opened. Your add-on opens a tab with the contents of chrome://restclient/content/restclient.html. Substituting for that file an HTML document with no content makes the error go away.
Using a binary search of the contents of that file (comment-out/delete progressive half portions of the file at a time and test to see if the errors still exist) to A) confirm that the error is there and B) what is causing the error, results in determining that the following line is causing the error to show up in the Browser Console (line 197):
<input class="span5" style="width:-moz-calc(100% - 1em) !important;" type="password" name="password" autocomplete="on" placeholder="Password">
A little more testing shows that the problem goes away when type is not password. Copying the original HTML document to a place where I can access it easily with a file: URL, results in no such error in the browser console when the document is opened.
Thus, the conclusion is that it is a bug in Mozilla's code for <input type="password"> when loaded from a chrome: URI.
Finding an invalid chrome: URI in code without a stack trace:
If the problem was not found in the HTML or XUL files, it would be necessary to look through the chrome: URIs which are used in your add-on to find what might be the cause.
chrome: URIs have some properties we can take advantage of in tracking down such an issue:
chrome: URIs are usually static.
chrome: URIs usually come in the format chrome:\\packageName\{content,skin,locale}
Your chrome.manifest file defines what chrome: URIs can be valid for your add-on/package.
Other chrome.manifest files define what chrome: URIs can be valid outside of your add-on/package.
So first look at your chrome.manifest file:
content restclient content/
resource restclient ./
overlay chrome://browser/content/browser.xul chrome://restclient/content/overlay.xul
overlay chrome://navigator/content/navigator.xul chrome://restclient/content/overlay.xul
style chrome://global/content/customizeToolbar.xul chrome://restclient/content/css/overlay.css
This tells us that in your package, the only valid internal chrome: URIs will be in the format chrome://restclient/content/ and will refer to the content directory within the root directory of your add-on.
So, we now look for all the chrome: URIs used in your add-on. To do that, the command line of grep -nri chrome: * is an easy way to do so. grep is available as a standard utility program under multiple operating systems. In Windows, I usually get it from Cygwin. From that command we get:
chrome.manifest:4:overlay chrome://browser/content/browser.xul chrome://restclient/content/overlay.xul
chrome.manifest:5:overlay chrome://navigator/content/navigator.xul chrome://restclient/content/overlay.xul
chrome.manifest:6:style chrome://global/content/customizeToolbar.xul chrome://restclient/content/css/overlay.css
content/css/overlay.css:30: list-style-image: url("chrome://restclient/content/images/icon16.png") !important;
content/css/overlay.css:33: list-style-image: url("chrome://restclient/content/images/icon16.png") !important;
content/js/restclient.js:51: i18nStrings = new restclient.StringBundle("chrome://restclient/locale/restclient.properties");
content/js/restclient.main.js:1040: xslDocument.load("chrome://restclient/content/xsl/XMLPrettyPrint.xsl");
content/js/restclient.main.js:1053: xslDoc.load("chrome://restclient/content/xsl/XMLIndent.xsl");*/
content/js/restclient.overlay.js:68: browser.selectedTab = browser.addTab("chrome://restclient/content/restclient.html");
content/overlay.xul:2:<?xml-stylesheet href="chrome://restclient/content/css/overlay.css" type="text/css"?>
content/overlay.xul:7: <script type="application/x-javascript" src="chrome://restclient/content/js/restclient.js" />
content/overlay.xul:8: <script type="application/x-javascript" src="chrome://restclient/content/js/restclient.overlay.js" />
content/overlay.xul:23: image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:35: image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:46: image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:58: image="chrome://restclient/content/images/icon16.png"/>
modules/StringBundle.js:59: * new StringBundle("chrome://example/locale/strings.properties");
Now, we could, and probably should, look through that manually for problems, but we can shorten the list quickly to find obvious problems with the command: grep -nri chrome: * | grep -v chrome://restclient/content/. This will give us any chrome: URIs which are not in the format for references to your add-on's content. The list obtained could easily contain valid chrome: URIs that reference files outside of your add-on. So, we might need to do more checking. From the above command we get:
content/js/restclient.js:51: i18nStrings = new restclient.StringBundle("chrome://restclient/locale/restclient.properties");
modules/StringBundle.js:59: * new StringBundle("chrome://example/locale/strings.properties");
The first is a locale chrome: URI. You do not specify a locale in your chrome.manifest. It is, therefore, certainly invalid. Looking at line 51 of content/js/restclient.js it is in active code. When it actually gets used, it will be invalid.
The second possibility is a typical example chrome: URI. The line begins with a * hinting that it might be a comment. Checking line 59 of modules/StringBundle.js shows that it is a comment.
The next step, if the problem had not already been found, would be to resolve the known invalid chrome: URI(s) and test to see if that solved the problem. In this instance, we already know what the problem is, so there is no need to check.
However, given that the chrome://restclient/locale/restclient.properties is invalid and A) there is no such file in your add-on and B) no locale defined in your chrome.manifest it means that if that code was executed it would fail. Basically it appears that function, restclient.i18n, is dead/bad code and should be removed. Given that function is the only use of the modules/StringBundle.js file, it could be removed also. Obviously, if this is something you are actively working on then that is a different story.
In working on this, I also noted a couple of other errors in the Browser Console which you should probably take a look at:
21:26:37.975 SyntaxError: test for equality (==) mistyped as assignment (=)?1 chrome://restclient/content/js/bootstrap.js:1557:33
21:26:37.989 TypeError: variable url redeclares argument1 chrome://restclient/content/js/restclient.main.js:376:8
While these are not inherently errors, it is generally desirable to not have anything show up in the Browser Console during the normal operation of your add-on. Although, given the various errors reported in jquery.js what are a couple more?
I am using this script from Bit Repository.
<IMG SRC="resize_image.php?image=sunset.jpg&new_width=32&new_height=32">
My problem is that, it is not showing any image on my hosted server.
http://www.belowyellow.dx.am/resize_image/demo.html
but it works on my localhost, hope somebody can help me with this. Thank you.
Source: http://www.bitrepository.com/resize-an-image-keeping-its-aspect-ratio-using-php-and-gd.html
If you take a look at what your PHP script returns before trying to embed it in an img tag, you'll see there are some warning before your image data.
Since PHP output text before your image output, it can't change the HTTP header anymore, so your image is output as text.
set_time_limit(10000);
error_reporting(E_ALL ^ E_NOTICE);
You should remove these two lines from resize_image.php. set_time_limit is obviously disabled on your production server so the first line is useless and generates a warning. The error_reporting in the second line is the real source of the problem here, it tells PHP to display all kind of warnings and notice. This kind of error reporting should only be used in a local debugging environment and not on a production server. If you remove this line, you'll get the default error reporting that shouldn't show any warning and your image should be correctly output.
Alright, I'm dealing with a really odd problem.
I've built a Jekyll-based site with several test posts. Locally, it compiles perfectly. Now I've begun testing it on Heroku (its eventual home). I'm using a custom buildpack to build the site once it is pushed to Heroku so I don't have to commit compiled content into my repo.
The Jekyll site is building without error, and yet, the results are bizarre. My index page is built to list all of my posts in site.posts:
{% for post in site.posts %}
<li>
{{ post.title }}
</li>
{% endfor %}
It starts with the test post I've made, and then lists 28 other "posts" that I've never created. They look to me like internal Jekyll functions somehow getting caught up in the compiler. Here are some of their names:
Md Extension
Text Extension
Timezone Override
Time Override
Override Data
Date Override
Foo --- Bar
No Yaml
...
These "posts" are only showing up when compiling on Heroku.
Does anybody have any idea what is going on here?
I had the same problem then it occurred to me heroku run at / and gems are installed in /vendor. Once Jekyll runs it scans all the files and folders in the directory to build _site.
Edit your _config.yml and tell Jekyll exclude 'vendor'. I also have mine configured to exclude 'Procfile', 'unicorn.rb' and 'config.ru'.
I am seeing strange redirect behavior with URLs that have encoded characters. For example, the following two URLs differ ONLY by the case of the "e/E" in the first encoded character (i.e. "%e2" versus "%E2").
URL 1: http://youlookfab.com/welookfab/topic/your-favourite-80%e2%80%99s-music-bands
"200 OK" HTTP status, page loads fine
URL 2: http://youlookfab.com/welookfab/topic/your-favourite-80%E2%80%99s-music-bands
causes a "302 Found" redirect
in a browser, the page redirects to the correct URL above (lowercase "e")
using web-sniffer.net, the content length is zero
I originally started looking into this because Google Webmaster Tools was showing crawl errors ("Redirect error", to be specific) on a bunch of pages that had URL encoded characters. Although my sitemap file specifies these characters in lowercase, GWT is showing them in uppercase.
I can't see any reason in .htaccess for lowercase URL encoded characters to redirect to uppercase. The site is based on bbPress, and I don't see any reason in the bbPress code for this to happen either.
Could mod_rewrite be doing something strange? I know there was a bug in the past where URL encoded characters were handled incorrectly.
Any insight you have would be much appreciated.
[This is an integrated bbPress/WPMU installation running LAMP, hosted on a MediaTemple (dv) server]
After digging deeper I found that the redirect was actually happening inside bbPress, which detects the uppercase hex in the incoming URL and sees that as a discrepancy with the "correct" permalink (which has lowercase hex).
I have written this up in a little more detail, along with a simple bbPress plugin to address the issue, at http://theblogeasy.com/2009/12/26/bbpress-and-encoded-urls-with-uppercase-hex/
Regarding the Google crawl error... my theory is that this is caused when the crawler (which converts encoded URLs to uppercase hex) and bbPress (which redirects them to lowercase hex) get into an infinite loop. The crawler probably detects this condition when it gets the same URL back repeatedly and throws an error.