Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any chance of seeing the raw markup for sample pages? #309

Closed
rwillett opened this issue May 7, 2016 · 6 comments
Closed

Any chance of seeing the raw markup for sample pages? #309

rwillett opened this issue May 7, 2016 · 6 comments

Comments

@rwillett
Copy link

rwillett commented May 7, 2016

Hi,

Thanks very much for the theme. We have most of it working but are struggling with a constant problem of actually seeing the raw markup you use to get some of the pages,

e.g. the page
https://mmistakes.github.io/minimal-mistakes/markup/markup-image-alignment/

is great but it would be even better to see the actual markup you use to get it looking like it is. We keep trying various formatting markup to see if we can get things right but its quite difficult to get right. Seeing the 'raw code' so to speak would make life a lot easier as we can see the input rather than just the output.

Perhaps we have missed the raw markdown for the above page, if we have, we apologise as we looked for it in lots of places.

Any guidance here much appreciated,

Rob

@mmistakes
Copy link
Owner

Check the gh-pages branch. The raw Markdown files for all posts, pages, and collections are there along with the rest of the source for the demo site.

@rwillett
Copy link
Author

rwillett commented May 7, 2016

Thanks for this, we weren't aware of this branch and where to look for it.

We've looked at that specific page and can see the format we want to use and how to use it

![image-right]({{ site.url }}{{ site.baseurl }}/images/image-alignment-300x200.jpg){: .align-right}

And now...

Thats clear now and we were using it the right way, the issue now is we can't get this format to work.

We can see the site.url and site.baseurl being expanded to the right URL, so the HTTP URL call is correct, but what we see in the HTML page is

![image-right](http://127.0.0.1:4000/images/congestion_zone_300x300.png){: .align-right}

We can go directly to the PNG image referenced in a web browser using that URL so we know the image is there.

It appears that something is not converting the

![image-right](http://127.0.0.1:4000/images/congestion_zone_300x300.png){: .align-right}

to whatever it needs to be.

We will be hosting this ourselves and its currently running on a Mac under El Capitan, so we changed gem "github-pages" to gem "jekyll" in our Gemfile and rebuilt and then rebuilt it again as we worked through the dependencies as in #305, so we worked through those issues.

Searching through the issues archives doesn't show anything similar to the problem that we have, we are assuming (famous last words) that we are missing a fundamental gem (is that the right phrase) for converting

![image-right](http://127.0.0.1:4000/images/congestion_zone_300x300.png){: .align-right}

to the right html code.

We thought that Kramdown was the missing 'filter', but after doing

sudo gem install kramdown
bundle exec jekyll build
bundle exec jekyll serve

We get the same result.

We've now run out of ideas, we're sure we're missing something, we looked at

https://mmistakes.github.io/minimal-mistakes/docs/installation/

and tried to see what was installed using the little video (or gif or whatever) but we simply couldn't work out what was happening with the bundle install. It would be useful to have the simple text output on that page, so people could see what you have installed and verify that against their own install.

Any suggestions to what the issue may be are greatly appreciated.

Thanks again,

Rob

@mmistakes
Copy link
Owner

mmistakes commented May 7, 2016

Silly question but what sort of file are you trying to insert an image in this way? If it's a .html it's not going to work as Jekyll won't parse any Markdown in that file.

This is Markdown specific syntax and will only work with .md or .markdown files. Unless you do something like capture the string as a variable, output the variable using the Markdown filter to convert it.

{% capture image-1 %}![image-right](http://127.0.0.1:4000/images/congestion_zone_300x300.png){: .align-right}{% endcapture %}

{{ image-1 | markdown }}

I would just write it as HTML if this is the case since it's a lot more work to use Liquid captures.

<img src="http://127.0.0.1:4000/images/congestion_zone_300x300.png" alt="" class="align-right">

The {: .align-right} stuff is Kramdown specific and allows you to add classes and other inline attributes.

@rwillett
Copy link
Author

rwillett commented May 7, 2016

Ah!

It is in an html file. Its the index.html file.

This is our first time using jekyll and we have around 10 other pages as .md films, we wanted to put some images on the index.html page. So we actually wrote the images as

<img src="http://127.0.0.1:4000/images/congestion_zone_300x300.png" alt="" class="align-right">

and thought "no", we should do with Jekyll way and pulled them out and put in

![image-right](http://127.0.0.1:4000/images/congestion_zone_300x300.png){: .align-right}

If the way to do it for the html page is use img src, then we'll do that.

That's rather embarrassing, but this is our first time with Jekyll and your templates. What gave us hope was the fact that the site.url and the site.baseurl variables were being inserted so we thought it was being parsed, so we carried on trying to use the markdown elements. If the img src with the class is the same output, we're happy with that.

We've just put the img src= back in and it works fine.

Sorry to bother you with a stupid mistake and misunderstanding on our part.

Rob

@rwillett rwillett closed this as completed May 7, 2016
@mmistakes
Copy link
Owner

No worries. I've done the same exact thing, which is why I had a hunch it was your problem.

There really is no right or wrong way to do it. Doing it the Markdown way has the advantage of being more readable but sometimes you're doing more work just to get it to ultimately convert into HTML. In those cases it's probably best to just stick with HTML instead of jumping through hoops.

@rwillett
Copy link
Author

rwillett commented May 7, 2016

Agreed, we'll leave it as html for the moment and get something working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants