I would like to make comments section for Jekyll that would use GitHub API and HTML forms and if possible little to none Javascript. And right now I'm wondering if anyone has achieved it.
No.
What you're talking about is not possible, for good reasons.
You could put together a server (not using GitHub Pages) that accepts form data and creates a commit using the GitHub API, but this is not exactly trivial.
You might be better off using something like Disqus for your comments.
Related
I was thinking it'd be really cool to have a slideshow on the README.md page of my github repository to show progress of the program (GUI-based) since early development.
One way to do this would be to generate a GIF of the "slide-show" with various images. Is there a better way to do this?
Update: Found that you can create a github webpage with pages.github. Maybe I can add logic to this website rather than a ReadMe file.
Case closed:
As JB Nizet said above, I can do this easily in markdown.
My current solution, however, is to use github pages.
This answer to a similar question mentions a recent feature addition that enables soft-wrapping for "prose". It seems that "prose" means markdown files. Anyone know how to enable wrapping for HTML documentation diffs?
While GitHub has soft-wrapping on prose diffs, there is no current support for auto-wrapping of HTML. GitHub support responded:
This is not possible currently, but we might add it in the future. Thanks for the suggestion, I'll add it to the Feature Request List™ so the team can see it.
Looking forward to seeing this feature. I don't know if they have community voting set up for features.
Can we include an HTML file / snippet from another HTML file?
My use case is related to how a website is built; in a simple form, a site typically has the same header and footer across the board. It is pretty straightforward if the site is equipped with e.g. PHP so you can do something like the include statement; we can contain the header and footer in separate files and include them later. But, what if the site is purely static i.e. no "back-end" support?
One thing that I had done in the past is to utilize templates in Dreamweaver. This worked but I'd prefer something that is more product-independent.
Thanks.
What you're looking for is Server Side Includes. It used to be available on most hostings, no idea what the situation is today.
Actually, a simple system based on a makefile and, why not, php's command line version, might also be helpful: a simple makefile that visits all php files in a directory, feeds it to php (eg, processes page decoration and stuff) and redirects the output to a corresponding html file should be enough to generate a set of uploadable, 100% static html files.
SSI is a great option if it is available to you as already suggested, I have always used PHP personally but as PHP is not available and if SSI isn't available then there is a JavaScript option as well.
The great thing with the JS option is the server doesn't need to have support for it due to the include scripts being client side. The bad thing is if the client doesn't have JS enabled in the browser the includes won't work. In saying that the vast majority of website users have JS enabled and this is displayed by most websites in the world who employ JS in 1 way or another.
Examples, the first one I found with a 2 second Google uses jQuery, have a look at the info here
There are also some AJAX plugins that could potentially be used for this at the jQuery website if it is a path you're interested in going down.
I hope this helps you :-)
I know that with a large site you would want to separate footers, menus, etc so that updating that file would push the update out to every page that contains the item.
Is the same recommended for a small site made purely in HTML/CSS, or is it simpler/easier/standard to code out the menu in each page and update each page when a change is needed?
I don't necessarily want to bring in PHP or etc onto this website, but the ease of updating menus would be nice. Any other suggestions? I've heard Server Side Includes might be one option... is that considered "pure html" or is more required to be set up on the server?
Thanks!
Unless you've got a site consisting of one page, do yourself a favor and have some separate files with your header/footer/other repeated elements.
That way you only have to make one change and its done. No matter how meticulous you think you are, you will inevitably forget a page somewhere on an update any other way. Its a human thing.
If its "just" HTML, and you're not using a server-side language, then you are correct in that you'll want to use server side includes. Check with your host to see if it will process SSI on regular *.htm/*.html files or if you need to use the *.shtm/*.shtml extension.
Server side includes isn't html, but it's not really coding either. It's probably your best option if you don't want to get PHP or some other coding solution involved.
It's mainly just a function of the webserver that you are using, and whether it's enabled for the site.
Here's a tutorial on them for Apache.
Here's documentation for IIS.
There are tons of different ways to approach this problem, but ultimately if you want to make changes on your side and have them reflected in lots of pages you're going to have to have either some kind of server side processing, which means PHP or JSP or something along those lines, or you're going to have to have some sort of process that generates your site statically updating lots of repeated items wherever they occur, but ultimately that would just be a compile time solution that's equivalent to some other server side approach.
If you're comfortable working in Java / JSP, then simple JSP includes might do everything you need. If they don't, then you could go for a full blown Portlets API application. I'm sure other languages have equally valid approaches, so ultimately its decideding what you're most comfortable with.
Server side includes would be "pure HTML" from the browser's standpoint, but then so would PHP.
If you didn't want to Server Side Includes, you could dynamically build them using JavaScript or a library such as jQuery, and just include a .js file in each of your pages.
If it's really small / mostly text-based content, you could just have one page with hidden DIVs that are switched in. Then it'll also be very snappy and self-contained if someone wants to view it offline.
It is very easy to do this with php. This is some sample index.php page i've built:
http://pastebay.com/51887
And for example in "includes/navigation.php" i have this:
http://pastebay.com/51888
So in everypage you have just put that from first link and when you want to edit navigation, just edit "includes/navigation.php". :)
[This question is somewhat related to this question, but the answers are not...]
I have always used relative paths in HTML and scripting languages (PHP/ASP/JSP) to refer to EVERYTHING. I think the justification had to do with 'what if the website gets hosted in some weird subdirectory.' But my coworker has started throwing absolute paths into a PHP site we're working on. At first I was appalled, but then I thought, "why not? We'll never be hosted in a subdirectory." Nowadays, getting hosted in the root is not an uncommon necessity. Is it still necessary to "code" (markup, really) with relative paths? I think it's probably an antiquated practice by now.
Definitely. You never know where your code is going to end up, or for what purpose.
Suppose you build a new version of a site, but to help your users transition, you move the old version to a "/classic" subdirectory. The same often happens the other way around where sites will host a beta version of the new redesign in a "/new" directory.
Building it properly the first time shouldn't be a hassle, and you'll thank yourself for it one day.
Well, it's probably not the end of the world but it's building in a dependency that you don't need.
If for example you ever want to put a number of versions in subdirectories in a test harness, or subdirectories help to work around some other issue (such as combining this with some other app that insists on being in the root), you may find it harder.
Sure, you can probably always work around it in some other way - but the problem is you now have to.
Edit: Killed my opening paragraph as it was based on a miss-interpretation of the referenced article.
I always use an absolute path for the following reasons:
Includes:
1. When you use a templating system, you never know the directory structure that a document is going to have when it's calling the include.
2. If documents are going to be moved around, you can be pretty sure it's going to be the documents themselves rather than the includes. If it is the includes, then they're being moved my someone who knows what going on. Added to this, if it is someone not familiar with absolute/relative path, they'll understand absolute a lot better than relative.
css: (as well as the items above)
1. When editing with Web Developer, relative backgrounds disappear when your style sheet isn't in the same directory as the doc.
2. By spec, when you put something on the 'Net, it should be there for the duration. When I'm building something new, I build it in a new folder, or with a new file name and leave all the old docs alone.
If you're using dynamically-generated pages, dynamically generate your URLs. For example, with JSTL use <c:url>. Not only does this allow you to move your pages in the future, it also ensures that your URLs will be properly escaped (tell the truth: how often do you build query strings with &? if you want the W3C validator to accept them, you need to).
For my personal website, which uses PHP to build pages, I've created several methods: insertPageRef(), insertCodeRef(), and so on, that create valid HREFs. As a result, I don't hesitate to re-arrange my site structure as it evolves.
The case of being moved to a subdirectory is fairly unusual, I'd say. Far more usual is being hosted on different servers: you create your site for testing on "dev.yourcompany.com" then go live by moving it to "www.yourcompany.com". In that case, you need to use relative links for obvious reasons.