I am trying to construct a Web site with blogdown, Hugo, and the xmin theme. I would like to store some Markdown files in a subdirectory, say content/misc/, such that they are not going to be treated as blog entries (e.g., they will be pointed to specifically on some _index.md pages).
How can I do this for single files or for all files in a subdirectory of content/? I know I can kind of hide them directly in the content/ directory, however this makes structuring the project clumsy and difficult.
I suspect this will be possible with specific templates, but is there an easier, much simpler way to handle this requirement? Or are there more appropriate themes to make it possible?
If there are some pages that you want to show with a common format, but you do not want them to be listed in your blog articles list
Simple solution: use the default template
To use the default template, you just need to add this "misc" folder in "content" with all your Rmd inside. Then, there will be a page listing all the articles of this type at "myblog.com/misc/".
Advanced solution: use a specific template
If you want to have a specific template for these pages.
If it does not exists, create a "layouts" folder at the root of your project.
Inside "layouts", create a "misc" folder
Inside "misc", create a "list.html" file if you want that your page "myblog.com/misc/" shows a list of your pages with this category
You also need to create a "single.html" if you want a specific way of showing these single articles.
To have ideas what to put inside these two files, you can directly start with the template of your own theme (https://github.com/yihui/hugo-xmin/tree/master/layouts/_default). As I said, you can also look at the "itemized" type of "hugo-future-imperfect" (https://github.com/statnmap/hugo-future-imperfect/tree/master/layouts/itemized), or what I propose for sticky pages on "hugo-statnmap-theme" (https://github.com/statnmap/hugo-statnmap-theme/tree/master/layouts/sticky_pages)
I've been having trouble implementing templates bought in themeforest in a meteor app.
I'm wondering, what would the best way to implement a template into a meteor app.
Two ways that I think of right now are:
(Tedious way)
Place javascript in Compatibility folder and try to name them in specific alphabetic order in order to get them to work properly.
Place css in client/lib folder and try to name them in specific alphabetic order in order to get them to work properly.
Place fonts and images in the public folder.
The second way (I haven't tested it yet) is to place the template files in the public folder and just link them manually (the old/non-meteor way) in the index.html file.
Now I'm not sure if these are the correct ways to do this and I would like some information regarding this issue.
Thanks!
I've done this myself with a themeforest theme.
Put the theme's css file under /client - it doesn't need to be in /public
Use the class names your theme uses in your templates. Typically a theme will have 3x what you really need so this ends up being much less work than it might seem. If your theme is built on bootstrap then it's even easier.
My theme used fontello a lot for icons, I had to recreate the folder hierarchy under client/fonts and then make sure the cross-references were correct.
Typically themeforest themes don't use js that much, I completely ignored all the js that came with my theme and created what I really needed in Meteor.
I am modifying someone else´s theme. The way I am doing it is looking for the source code to find where it is located and modify it. I am using grep to find the html ids and classes on the theme folder. It takes sometime and I am not sure if there is a better way.
Is it there any other way on locating/modifying code in wordpress?
ps: I am using a child theme for the changes.
I just started using Wordpress 3.0 to get a simple blog up and going. For now I am working with the default theme "Twenty Ten".
I want to make a simple change:
I'd like to modify the layout of the bloginfo( 'name' ), bloginfo( 'description' ), and php header_image() that appears at the top of the blog.
So, under Appearance, Editor, I select Header.php and I can see how this is being rendered.
It appears I can just modify this to my liking and I am good to go. (Correct?)
If so, my question is: is it considered proper practice to modify the html in header.php?
It seems to me that this is a bit dangerous, for example when it comes time to upgrade that same theme. How do I know which php files I have applied customizations to? Say I modify 6 php files, then an upgrade of the theme comes along...how does one handle re-applying these changes to the upgraded theme?
Is it a total "do over"?
Is there a better way to handle this scenario?
Maybe some themes are more powerful than others and can handle this type of customization more flexibly, and I should be searching for such a theme? Or, is there a reasonably proper and safe way to do this by directly editing the php files?
Child theme, child theme, child theme. Create a new folder in themes (name it whatever you want. Go crazy. As long as you don't name it twentyten). Create a style.css file in that directory and copy the whole style.css file from twentyten into it. Then, change the theme name in the css headers and add this line after the tags:
Template: twentyten
Then copy the header.php file over to another file in your directory, and edit to your heart's content. If twentyten ever gets updated, you'll get the benefit of those updates (unless they're in css or the header) without losing your changes.
Yes, you can edit the theme to your liking. I think it's common practice (however, I've always just created my own themes from scratch). Just give credit where it's due and don't pass it off as your own original work.
To avoid over-writing your customized theme when an upgrade comes out, you could save the customized one to a different folder in the themes directory with a different name, like Twenty Ten Customized. You can then copy or re-do the changes in the upgraded theme if you think the upgrades are worth the trouble. There's no rule that says you have to have the latest version of the theme, after all.
There might be other themes that allow a high degree of customization without editing the php, but most of the time you'd have to edit the php I'd think. (but I'm no pro theme developer.)
I would do as Benny suggested and rename the theme so that it isn't overwritten when you upgrade Wordpress.
I would not worry about updates to the actual theme because I don't think those ever really happen. The last Wordpress default theme was Kubrick and, to my knowledge, it rarely was updated and most updates were minor and went unnoticed by most users. If you go about customizing your theme, I don't think Wordpress is going to update the Twenty Ten theme to the point where you would ever wish that you hadn't edited the source because you wanted to upgrade to the new default theme.
If you don't want to actually edit any of the theme files, check out something like Thesis that allows you to customize most things from the admin.
Note: I'm not aware of a free theme that offers a lot of customization options through the admin panel, but there might be something if you check around for a while.
If I really had to stop automatic updates on my Wordpress theme, I'd do exactly what Kris + Chris Schmitz suggested (i.e. rename the theme differently). Modify header information in the style.css file in your theme's root to do this.
Personally, however, if the theme already works for me out of the box, I think I'd most probably already be fine with that. My website's running, the theme's working, and updating my theme may just break my site in ways I don't know.
I'd probably update it only for major security updates, but I'd probably be reading a changelog for that. But if I was doing that, I'd know what files exactly were modified, and I can just manually do it myself. Sounds like a lot of work, but better than my site buckling on me by some unknown cause.
If you do as Benny suggests and create a renamed copy of the default theme, you can use a free diff tool to compare the directories when an upgrade comes out. I'd use Meld ( http://meld.sourceforge.net/ ) to do a three-way directory comparison (Original theme, upgraded theme, modified copy) to determine if any changes have been made that impact the parts you changed, as well as to merge the upgrade changes into your modified files.
I am currently working on a project where a programmer who fancied themselves a graphic designer attempted their hand at ASP.Net themes. The CSS is pretty bad, but that is another question altogether.
What I really need help with is the best way to organize ASP.Net Themes and the CSS that lies within them. Imagine that there is a directory structure that looks something like this:
Themes
Theme A
StyleA.css
Common.css
Theme B
StyleB.css
Common.css
Theme C
StyleC.css
Common.css
Each theme has a common stylesheet in it. Unfortunately the author of those style sheets managed to change only a few things here and there in each copy of Common.css. Eventually I will evaluate whether or not those changes are even necessary, but some major cleanup needs to happen first. For now just assume that the changes, ever so small, are necessary for things to look right with each theme.
I would like to know what the best practices are for using themes while also needing some common styles across your application. I want to minimize the number of AppTurns in the page load, but I really want to consolidate common styles into one place in a way that maintains the ease of themes.
You should just include the standard/common css in the website and include it in the head of the masterpage instead of placing it in themes.
I have written a small article about that:
http://www.sambeauvois.be/blog/2010/01/dont-repeat-your-common-css-between-your-different-themes/
I'll complete it with more information later
Yes, just reference the common CSS file directly instead of putting it in the theme folders.
But what if you have a webpage in a sub folder that uses the masterpage? Won't the page to the css file be wrong then?