Ive been using wordpress for awhile now and wanted to try something different. Enter in my discovery of the world of static website generates. Now I have my eyes on Octopress which I know to be built on jekyll. Before I start getting dirty in ruby I want to know if its relatively possible to translate my current wordpress theme to a static site.
That's exactly what I did recently:
http://eduncan911.com/blog
I copied a friend's Wordpress theme (with permission) of almost the same design:
http://forgetfoo.com
"I want to know if its relatively possible"
To answer your first concern, the answer is a big ol' YES. That's what make Jekyll so good for these kind of things: it's just raw HTML and css and js in a few directories. Place them anywhere you like, and start cutting away at chunks in includes, wrap some plugins, etc and before you know it, you are rake generate and rake deploy.
Octopress makes it even sweeter by having a large number of plugins, a blog-like template system already structured*** (see below), and bunch of defaults all setup for blogging.
The issue with Octopress' theme is as I said above, it is purely setup as a blogging platform. You'd need to highly modify, or in my case just completely ignore, the template they have and just piggy back on the nice Github Pages, SCSS, and plugins it comes with and roll your own html templates. It's really really really easy.
Where do you start?
/source/index.html
You start here with this YAML file. At the top is a definition of layout, which is used to pick what "wrapper" or layout you want to surround this index.html content with. To make a new template, one like yours, I'd call it layout: fuse_homepage. Then go into source/_layouts/ and create a new `fuse_homepage.html'.
Start with your own theme and format as you want
But see, you don't even have to do that. Hell, just paste your entire homepage HTML right
into that source/index.html to start with (make sure to keep the --- YAML markers at the top, but get rid of the layout). Start there and break things out later when you get tired of coping and pasting the header/footers. Heck, just start there - make a fuse_header.html and fuse_footer.html and just share those for now.
Ignore Octopress' theme layout - it's just for hackers that don't do UX and just want to tweak things. Designers or people that like to control their code will want to roll your own.
It really is that flexible. However you want to break it up, you can. Want a new page, just call rake new_page["title"], which all this does is create either an /title.html, or /title/index.html, depending on your settings in the config file. But see, you don't even have to do that. Just create the file yourself - BAM, it is copied on deployment.
Regrets with Octopress
Trying to force the themes to do my bidding, chasing rabbits
I only regret trying to follow the Octopress' author's format - wasted so much time and got so turned off at Octopress. In the end, I just ignored it and did my own. Much easier, and I know where everything is. I also wanted nice and cleanly formatted HTML - a show that I care about my code. The default Octorpess theme and structure invites so many mis-placed tabs and spaces that it's just ugly. Doing your own, you are in full control, space by little space insert.
Importing posts
There's a huge amount of Google links to help you export your WRX from Wordpress, and to generate a the post files automagically. Be prepared to try several different ones as they aren't all perfect.
import comments into Disqus
Unless you are already using Disqus on Wordpress, you are going to have a horrible time with this one.
I can now claim myself to be an WRX/BlogML expert after my nearly 100 tries of importing and exporting and fixing and so on. There is no documentation on either importer (Disqus nor Wordpress) to tell you of the individual required fields. For example, Wordpress requires wp:comment_id to be set, and unique for each and every post you import whereas Disqus requires an wp:comment_email field, even though say it is optional (it's BS, argh).
Be prepared to hack code. It is a hacker's framework after all
Do note though: it is a lot of work to hack around the static site. Doing your own template will save you so much time. You'll also may want to write your own custom plugins, which I did, to get around the bugs in peoples github repos - it's pretty easy, but does require coding.
I spent about a month off and on until I got my new blog/static site to where I liked it for launch. A lot more than I wanted, but it was "fun" learning new languages (Ruby, Python, installed Debian linux in a VM cause Windows just sucks at that stuff).
If you aren't prepared to write that much, there are a couple more static site generators out there as I blogged about (hey, got to show off my Octopress and custom theme!):
http://eduncan911.com/software/the-static-blog-boom.html
Btw, nice site...
Related
I'm managing a PHP-built site that uses a multi-tier Smarty templating system, with a main template including sub-templates, etc. The site itself has dynamic features of its own, including user profile displayed in the header, footer sitemap and menu dropdowns dependent on user access levels, etc.
I now need to put a vBulletin forum in the middle of it all.
One of my options is, of course, making vBulletin "look like" the site, with a plugin for a header and footer - but that is pretty much out of the question, as some of the site's features should override forum access entirely (maintenance periods, user access restrictions, occasional "splash page" redirections), we have JavaScripts and header bits, and then there's the part about whole-site templates I mentioned. Large bits of page code would need to be duplicated and that's something I'd really rather avoid.
So I went the other way and started including the forum's files through a "wrapper" PHP script, hoping to capture its output entirely in an output buffer, and put it into my template proper. I even simulated REQUEST_URIs and other $_SERVER fields, to make the forum think it's being run standalone. It fought me back fiercely, breaking out of ob_start()s and die()ing instead of returning at certain points, so much that I went back to the drawing board.
My other option is to hack my own site in a gruesome way, to provide a severed header and footer the forum would use - but then there'd be the bits and scripts to combine. Also I'd lose the ability to produce one page in one run, and having one-time generated content synchronized between the header and footer would become a nightmare.
What other options do I have? Do all the sites using vBulletin stick to simple headers and footers, or is there something obvious I'm missing?
Update: What would completely solve my problem would be if vB supported a "template wrapper" plugin, called with all of the forum's generated HTML buffered as a parameter; "here's the output, go ahead and do whatever the hell you want with it". But is there support for that? Or is it feasible to hack it in?
After some searching, I found that vBulletin 5 happens to have a hookFrontendBeforeOutput hook, which can operate on the entirety of the output produced by vBulletin's template rendering. I can thus create a plugin which will capture vB's output, correct it where needed, and feed it into my own template system for a final presentation - as well as fire the site's login and other logic mechanisms.
This forum thread has an example, demonstrating that very hook, albeit in a much simpler case.
I'm writing a basic CMS for one of my sites and have run into an issue where some pages need to dynamically serve PHP and JS, where as others are plain HTMl. I want there to be a setting which will allow this for the pages that need it and will load ACE editor instead of a different wysiwyg editor. I want to reject any inputs that code on non-code enable pages. How do I ensure that all JS and PHP included from the database will not execute?
You don't really want to do this. Beyond the security concerns if you do things wrong, it becomes an absolute maintenance nightmare - there's no good way to put CMS pages into version control. Testing and migrating code between development environments and live sites becomes brittle, at best. In one of my other posts, I detailed the problems that come along with running a Drupal site & you're starting down a similar road.
With that said, if you insist on following through with this plan, the way to go is to use a proper template engine (I've been using h2o lately) & leave the worry of escaping content to it. The other thing I'd do would be to separate the PHP and the displayable part of the code by putting them in completely separate fields. This not only gives you cleaner code (remember, mixing display and logic is bad) but you can always treat what you display as 'dumb' text and only allow it access, via the templates, to the output of your PHP.
I was having a "discussion" with my manager today about the merits of using PHP includes and functions as a template to build websites more quickly and efficiently. He has been using Dreamweaver templates for years and sees it as really the best way to go. I would like to start using some different and more efficient methods for web creation, because we need to get through our projects faster. I would like to know in detail what would make Dreamweaver dwts better than using code to accomplish the same task, or vice versa.
His reasoning is:
When you change links on the dwt file, it changes links for every page made from that dwt.
Even if you move pages around in directories, it maintains links to images
Everyone in the company should do it one way, and this is the way he chose (there are two of us, with someone who's just started who needs to learn web design from the beginning, and he plans to teacher her the dwt method)
If you edit a site made with a dwt, you can't change anything in the template (it's grayed out), making it safer
If he's building sites with dwt, and I'm doing it with PHP includes, we can't edit each others' sites. It gets all over the place. When we have new employees in the future, it will get all crazy and people can't make changes to others' sites if they're out of the office.
I've been studying PHP these days, and am thrilled with how powerful it is for creating dynamic pages. The site in question which sparked this "discussion" is more or less static, so a dwt would work fine. However, I wanted to stretch my wings a bit, and the code was getting REALLY jumbled as the pages grew. So I chopped off the header, footer, and sidebar, and brought them in to all the pages with a php include, as well as dynamically assigned the title, meta data, and description for each page using variables echoed in the header.The reasons I like this better are:
It's cleaner. If every page contains all the data for the header and footer, as well as the extra tags Dreamweaver throws in there, then I have to sift through everything to find where I need to be.
It's safer. It's sort of like the above reason dwts are safe, except I do all my code editing in a text editor like Coda. So on occasion I have accidentally deleted a dwt-protected line of code because those rules only apply within dreamweaver. I can't chop off part of the header if I can't see it. Incidentally, this makes it easier to identify bugs.
It's modern. I look through source when I see great pages made by designers and design firms I admire. I've never seen dwt tags. I believe by using PHP to dynamically grab files and perform other tasks that keeps me from having to go through and change something on every page, life becomes easier, and keeps things streamlined and up-to-date with current web trends and standards.
It's simple. This should be at the top of the list. Like I said we have to train a new person in how to create for the web. Isn't it much better for her to learn a simple line of PHP and get an understanding for how the language works, rather than learn an entire piece of (not exactly user-friendly) software just for the purpose of keeping her work the exact same as everyone else's? On that note, I believe PHP is a powerful tool in a web designer's arsenal, and it would be a sin to prevent her from learning it for the sake of uniformity.
It's fast. Am I mistaken in my thought that a page build with header and footer includes loads faster than one big page with everything in it? Or does that just apply when the body is loaded dynamically with AJAX?
I did extensive searching on Google and Stack Overflow on this topic and this is the most relevant article I could find:
Why would one use Dreamweaver Templates over PHP or Javascript for templating?
The answer is helpful, but I would really like to understand in more detail why exactly we shouldn't switch to a new method if it's simpler and has more potential. My manager insists that "the result is the same, so if there isn't something that makes me say, 'oh wow that's amazing and much better!', then we should just stay how we are now."
(I do apologize for the length of this question, but the guidelines asked that I be as specific as possible.)
Like I said in comments, without knowing what exactly sites you are working with it's hard to tell which PHP features are most important to showcase. However, I can try and describe the most simple kind of sites I was dealing with, and where and how PHP came in handy. If you work with something more complicated, the need of programming language may only increase.
The simple website may have a few different pages with text and images. I'm assuming nothing interactive (i.e. no inquiry form), no large amount of structured data (i.e. no product catalog), only one design template which is used by every page with no differences whatsoever. Here's the typical structure:
One PHP file (index.php) for handling all sorts of php-ish stuff
One design file (template.php for example) for storing everything html-ish (including header, footer and more. Basically all html with placeholders for text and menu)
One CSS file for, well, the site CSS
Most of the texts are stored in database or (worst case) just txt files. Menu (navigation) is stored in database as well
Images folder with all the needed images
The key features here are:
Simplicity. You only have as many files and code as you really need to keep things organized and clear
Reusability. You can basically copy/paste your php code with little to no changes for a new similar website
No duplicates whatsoever.
Data and design separation. Wanna change texts, fix typos? You do it without as much as touching design (html) files. Wanna make a completely brand new design for your website? You can do it without even knowing what those texts are or where they are kept.
like deceze said, no lock-ins. Use whatever software you like. (Including Dreamweaver)
PHP is responsible for taking texts, menus, design and rendering them all into a web page. If website is in more than 1 language, PHP code choose the right texts for the language of visitors choice.
If texts are stored in database, you don't even need notepad and ftp. You just need, i.e., phpMyAdmin (stored in server) so you can connect directly to database and edit any text you like using only web browser; from anywhere in the world. (I am assuming no real CMS). If you need to add one more page, you connect to database using myAdmin and browser, enter the page name (for menu) in 1 or more languages, enter the text for new page (in 1 or more languages), done! new page created, name placed in the menu, all hyperlinks generated for you. If you need to remove a page, you connect to database and click delete. If you need to hide a page for a while (i.e. for proof reading before publishing), you connect to database and uncheck "published" box.
All this doesn't come with just using database ofcourse, you need to program these features with PHP. It may take about 1 - 3 hours depending on experience and the code is fully reusable for every similar website in the future. Basically you just copy/paste php file, copy/paste database tables, enter new text and menu into database, put placeholders into your html file and done! brand new site created.
Which immediately makes most of the reasoning for DWT irrelevant. You don't move files around because you have only one html file and no directories, you don't need grayed out template because texts/images (content) and template are not even in the same file, there's no such thing as changing links in dwt file because it's PHP that generates them on the fly (these are not real links to real html files but rather links with parameters to tell PHP which exactly page must be rendered.. because remember we have just 1 file). The bottom line is, comparing features of the two side by side is like comparing features of a sword vs machinegun. Sharpness and length of the blade concepts are meaningless in a case of machinegun; while lifetime sword user won't really get the meaning of velocity and caliber before he tries and uses machinegun. And yet, while you can't compare their features one by one, no one brings sword to a gunfight for a reason :)
As for #3, currently there are many more people working with PHP than DWT (in a case you will need more employees in the future, or if other people will need to work with your websites later, etc.) As for #5, you can edit PHP websites with Dreamweaver as fine as DWT websites.
That's just off the top of my head. I wrote this in my lunch break so I likely forgot or missed quite a few things. I hope you will get a proper answer with detailed DWT vs PHP comparison too.
You simply can't compare PHP vs. DWT.
PHP is a programming language, where templating is just one of it's numerous features, and DWT is just a silly proprietary system to build simple web pages.
there is actually nothing to compare.
I would say that using DWT templates over PHP do have some advantages.
It does not need any extra server-side process, like PHP to process the files at the server.
You can serve all files to the user as .html files rather than .php files, though I suspect that it is possible to hide the .php extension. Why should any user see anything other than .html?
You don't have to learn PHP syntax/programming. It is true that you can do more with PHP that plain .dwt files but for plain templating the .dwt files can be just as clean.
It is not true that .dwt files are a lock-in technology. The feature is also implemented by other web editors, e.g. Microsoft Expression Web.
So I am making a CMS, a gallery script via Object Oriented PHP. Anyways, the problem is now that I have the basic layout for the objects and such to the point where I need to start putting together, I am stumped how to do this.
What I have is essentially a Navigation, Data, Gallery, and Module class. Module stands for pages, categories, et cetera. The problem is that Gallery outputs the images, module gives the data for the pages, navigation creates the (you guess it) navigation. You get the picture.
On the index page, I end up doing essentially this (this WILL change, but it is illustrative for how I was starting to set it up):
$navigation = new Navigation();
$navigation->top();
$page = new Module();
$page->basicPage($_GET['m']);
The basicPage() does a few things, but primarily this is the issue:
$gallery = new Gallery();
$gallery->setGallery($id);
$gallery->thumbGallery();
So on so forth.
The problem arises in that if I call basicPage(), the designer or whoever has very little control over the choices. As you saw, it is thumbGallery, and that doesn't allow full images, and it doesn't even let you set the size of the thumbnails (which I do let them do, only if they can call that function them self though).
So I thought of a few solutions to the problem. I don't have these basic pages, but I have the designers build out templates much like wordpress. I dislike this solution, because it makes the design process complicated, albeit thorough. I don't want to make it so that everything is controlled, and is one way. Of course you can "display: none" to elements as the designer and a few other tricks, but I want them to have the ability to do a lot of things, without the complicated way that Wordpress does it.
My question is how do I strike the balance between simple and flexibility?
Any help, even ideas are appreciated. Thanks.
EDIT: I forgot to mention. The problem is from just having the index have all of this data is otherwise I will have to do a lot of if/else and such, and I really didn't want to make this a procedural program, just one you can essentially just plop stuff down and we're good. See, module stands for both gallery and page. Most pages will not have images attached to it, and the categories will have images, but not always text. It will cause an error if I call thumbGallery and it is just an informational page, and if I call an informational page and it is a category, it will not show the images (to avoid the error). I could, and have started to build it together in what is called basic page,but the problem like I noted before is that it restricts how much freedom the designer has without having to mess with php, and most designers are pretty dumb when it comes to php, unfortunately. Espectially OOP (no offense. I am a designer too, but I happen too program).
Without seeing the rest of your code it's difficult to know the best solution considering what you already have. I've developed my own custom CMS Application Frameworks from scratch for the past 9 years, and I'd be glad to give you some tips.
I'm assuming you're storing all the CMS content in a database. Storing the configuration for the gallery settings in the database might be a possible solution. In theory you should have different views (following the MVC pattern) for displaying the gallery in different ways. A listing view for showing multiple image thumbnails, one for showing a single image, plus a view to list categories perhaps.
So, in the database you could define that page X should show the thumbnail view instead of a category view.
Not sure if that's a solution to the problem you have, but that's a very simplistic example of how I've done it in my CMS's in the past.
after using own custom cms for over 6 years, I decided to go for Drupal from now on. I will use Drupal for all my works. I'm pretty new at Drupal, started just 2 days ago :D
just a simple question;
I have a simple xhtml-css site (5 pages), and client is asking cms for gallery page (xhtml for now). so is it possible to make only 1 page with drupal and rest pages are using current xhtml somehow? How would I create the base with Drupal for such custom (out of Drupal) pages' links? or do I have to transfer all other html pages into Drupal as Page (drupal page)?
ps, as a new drupal user, i didnt see anything complicated as everybody complains, it is pretty well structured-clear... love it so far :) ps, i say 2 days but I had only few hours so far :)
Thanks a lot!!
The Drupal URL rewriting rules only apply to files and directories that do not exist on the file system, so as long as you avoid naming conflicts, you can put 'static' pages more or less anywhere you like, and Drupal will not interfere with them being served.
That said, it would probably be a good idea to consolidate them within a 'static' folder, either on the top level of the document root, or (more appropriate) within the 'sites' or the 'files' folder of the new Drupal install (which implies adjusting your current paths).
However, I agree with Kevin (+1) that for only 5 pages, it is probably less work in the long run to 'migrate' them to Drupal right from the start, as you will save work and trouble down the road as soon as you further enhance the site.
If its only 5 pages, why not put it all into Drupal? Less overhead that way. Otherwise you will have to edit .htaccess, manually update files instead of making simple changes in Drupal, and edit multiple files should the theme change in any way.
If you need a Gallery solution, I would suggest checking out the Gallery Assist module.
If all 5 pages use the same or similar layouts, navigation, etc then it makes the most sense to put them all in Drupal.
Setting up, configuring, and theming Drupal will be a lot more effort than one page is worth.
But if all your content does not share a similar layout and have very different looks then you may consider leaving them static.
There are many ways to vary the the layout, navigaiton, and such within Drupal, but this may be a challenge for a Drupal beginner and even require a substantial effort from Drupal pros.
If you leave content external to Drupal that includes identical layout elements, it leads to redundant work.