Applying Product Launch Formula from Jeff Walker to launch a membership based website for a mission-based organization. jQuery, Python, Django, Flash, ActionScript 3, are applied to software as a service educational website.
Tuesday, December 25, 2012
Responsive Web Design
Why I Have Been Made to Feel Ashamed of Liking Asian Men
Facebook’s 2012: IPO, a billion users and a shift to mobile
Why startups shouldn't be afraid of Facebook cloning them
Is Paying to Message Strangers a New Texting Business?
Sunday, September 2, 2012
Google Patents Real-World Image Recognition Algorithm For Video, Photography S
It's Becoming Clear That No One Actually Read Facebook's IPO Prospectus Or Mark Zuckerberg's Letter To Shareholders
Tuesday, July 10, 2012
wordpress + django on same account - advisable or not?
bobhaugen
Member
Registered: 2008-02-25
Posts: 34
wordpress + django on same account - advisable or not?
I have a client that wants to host a wordpress blog and a django app on the same account.
I understand from a bunch of forum posts that this is doable, for example: http://forum.webfaction.com/viewtopic.php?id=4656
But I have a few questions about the best way to do it, and if it is a good idea.
1. The examples say to put them on the same domain with django at the root, and wordpress on e.g. /blog. The client would prefer to have wordpress at a root, and django maybe at a subdomain. Is this possible? (The two apps will only be connected by hyperlinks.)
2. The two apps do not need to be on the same website, and the django app could remain at something.webfactional.com while the wordpress site is at a registered domain, e.g. somethingelse.com. So would it be cleaner to create two websites under the same WebFaction account?
3. Is this a good idea (running wordpress and django apps on the same account), or would be better to get 2 different accounts? The django app will be more mission-critical than the wordpress app, and go through more software changes. I assume they will both be running on the same apache server. Will the 2 apps interfere with each other? Is there a clean way to restart django without stopping wordpress?
4. Another complication might be that the people administering the wordpress and django apps will be different. By that I mean, the people logging onto webfactional via ssh and tinkering with the software and configuration. What should we watch out for there?
5. Assuming it is at least an ok idea, what size plan would be advisable? Neither app will have large number of users or hits, but the django app will be fairly complex and process a large amount of data. Moreover, the django app will use postgresql while wordpress will use mysql.
#2 2010-09-20 12:05:13 David L Administrator Registered: 2009-04-13 Posts: 578 Re: wordpress + django on same account - advisable or not?
1. The examples say to put them on the same domain with django at the root, and wordpress on e.g. /blog. The client would prefer to have wordpress at a root, and django maybe at a subdomain. Is this possible? (The two apps will only be connected by hyperlinks.)
This *is* possible, but Django really doesn't enjoy being anywhere but the root of a site. With some finagling, you can usually make it run with minimal issues. It's possible that this has been fixed in one of the more recent releases, though.
2. The two apps do not need to be on the same website, and the django app could remain at something.webfactional.com while the wordpress site is at a registered domain, e.g. somethingelse.com. So would it be cleaner to create two websites under the same WebFaction account?
That solves the above problem quite nicely
This is really up to you. We don't count PHP-based applications against your memory limit so if your Django application happens to chew through some memory your WordPress site won't be affected.
3. Is this a good idea (running wordpress and django apps on the same account), or would be better to get 2 different accounts? The django app will be more mission-critical than the wordpress app, and go through more software changes. I assume they will both be running on the same apache server. Will the 2 apps interfere with each other?
As I said above, they shouldn't interfere with each other.
Is there a clean way to restart django without stopping wordpress?
These run as entirely separate processes, so restarting Django has absolutely no impact on Wordpress.
4. Another complication might be that the people administering the wordpress and django apps will be different. By that I mean, the people logging onto webfactional via ssh and tinkering with the software and configuration. What should we watch out for there?
Naturally, if you're giving someone SSH access to your account it's possible that they can do damage. Other than malicious users, there really shouldn't be anything else to worry about.
5. Assuming it is at least an ok idea, what size plan would be advisable? Neither app will have large number of users or hits, but the django app will be fairly complex and process a large amount of data. Moreover, the django app will use postgresql while wordpress will use mysql.
We always recommend starting with our lowest plan and upgrading if/when necessary.
From what you've described, it's like you won't need much more than a Shared 1.
[Editorial: this post came from the webfaction forum so they are answering how much resources would be necessary.]
Monday, July 9, 2012
Speed up WordPress, and clean it up too!
Speed up WordPress, and clean it up too!
by Joost de Valk on 21 January, 2008 at 15:17 110 comments
Every once in a while people will ask me to fix their blog, because it's either slow, or broken. When it's not something to do with their WordPress hosting, (some hosts are just plain bad and slow), most of the time this is caused by either broken plugins, or broken themes. There are a few things I tend to do when I get to clean up stuff, and I though I'd list them for you.
Clean up your theme
header.php
First of all, what I do is make the header.php file do a lot less queries. Because themes have to be easy to spread, they have to get almost all the blog specific info from the database. That results in a lot of queries for stuff that you could just hardcode into the theme. Some examples, taken from the default kubrick theme:
1 | <html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>> |
2 | <head profile="http://gmpg.org/xfn/11"> |
3 | <meta http-equiv="Content-Type" content=" |
4 | <?php bloginfo('html_type'); ?>; |
5 | charset=<?php bloginfo('charset'); ?>" /> |
Could just as well be:
1 | <html xmlns="http://www.w3.org/1999/xhtml" dir="ltr"> |
2 | <head profile="http://gmpg.org/xfn/11"> |
3 | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> |
You can also:
•.make your stylesheet URL's static
•.make your pingback URL static
•.make your feed URL's static
•.you can remove the blog's WordPress version
•.make your blog's name and tagline / description static
Doing all that, you can remove 11 queries to the database, and this can highly speed up your theme.
footer.php
The default theme also has some of these calls to the database in the footer which you can make static, or remove altogether:
•.your blog's name
•.RSS feed URL
•.Comment RSS feed URL
You can also remove all comments that aren't necessary, like "If you'd like to support WordPress, having the "powered by" link somewhere on your blog is the best way; it's our only promotion or advertising." I can tell you that that line is in a LOT of footers, and it's a waist of bandwidth once you have decided to leave the link for WordPress in or not.
Check your coding habits
You will have added code to your themes for your plugins. Let's say you have a line of code like the one below, for a plugin that thanks people coming from search engines:
1 | <?php refer_thanks(); ?> |
This creates a problem, as soon as you, by accident or another cause, disable the plugin that holds therefer_thanks function. When the function doesn't exist, the code errors out, and your page doesn't continue to load, thereby breaking your blog. To fix this, PHP offers a special function calledfunction_exists, and using it, the code would look like this:
1 | <?php if (function_exists('refer_thanks')) { refer_thanks(); } ?> |
Now, if the function doesn't exist, your theme, and thus your blog, won't break. It's probably a good idea to do this for every line of code you added for a plugin.
Install a caching plugin
Lastly, you should really consider installing either WP-Cache, or WP-Super-Cache. They make your blog so much faster, that you won't know what happened to you once you've got them running.
All of this makes sure your blog remains maintainable, and fast.
The heading structure for your blog
The heading structure for your blog
by Joost de Valk on 2 September, 2010 at 16:00 45 comments
The heading structure of your pages is one of the very important aspects of on-page SEO. It defines which parts of your content are important, and how they're interconnected. Because they have different goals, a single post needs another heading structure than your blog's homepage or your category archives. This post intends to give you the basic pointers to get your heading structure right for those three different cases.
If you've ever heard of this new kid on the block called HTML5, or maybe even consider yourself an expert on it, please note that this post still treats headings in the HTML4 / XHTML1 way of using headings. I'll briefly talk about headings in HTML5 in the end, it's a whole 'nother ball game!
This post will cover:
5 basic principles about HTML headings
Let's get these things straight before we do anything about our heading structure:
1.The most important heading on the page should be the H1.
2.There is usually only one H1 on any page.
3.Sub-headings should be H2's, sub-sub-headings should be H3's, etc.
4.Each heading should contain valuable keywords, if not, it's a wasted heading.
5.In longer pieces of content, a heading is what helps a reader skip to the parts that they find interesting.
Based on headings, there are tools out there that can, and will, make an outline for your content. If you were to make an outline for this article, it would look like this:
•.[h1] The heading structure for your blog
•.[h2] 5 basic principles about headings
•.[h2] The headings for your homepage
•.[h3] The issue of full posts on archive pages
•.[h2] Heading structure for your single posts / single pages
•.[h2] Structure of headings for your category / tag / taxonomy pages
•.[h2] Headings and HTML5
•.[h2] Conclusion: re-think your blog's headers
The most widely known, and probably also the easiest, tool capable of doing this is the W3 Validator.
The headings for your homepage
So while we can (and will) discuss some specifics in the comments, your homepage should probably have a structure that looks like this:
•.H1: Blog's name
•.H2: Your blog's tagline, if it's "keyword-rich"; if not, all your recent posts should have an H2.
•.H3: Your recent posts, or, if those have an H2, this could be used for somewhat older posts.
•.H4: related content in the sidebar, like the heading of an "about" widget.
•.H5: Unrelated headings in your sidebar, footer, etc.
As you can see, I differentiate between "related" widgets and unrelated widgets. It's no use at all to have an H3 heading saying "Our Sponsors". An H4 HTML heading saying "About this SEO blog" could be useful though, if "SEO blog" is what you want to rank for.
The issue of full posts on archive pages
Maybe you've seen it, maybe you didn't yet, but this sort of heading structure creates a problem. If you're displaying full posts on your front page, your sub headings would be H2's, just like your post titles. That's wrong, of course, and a good example of why we should be separating our content and markup a bit more then we're doing now, but that's not an easy fix. Basically, if you're displaying a post on an archive, category, tag or home page, each H2 should become an H3, H3 should become H4, etc.
No code samples yet, but my mind is working on this now, so it might come soon.
Heading structure for your single posts / single pages
This one is simple:
•.H1: post / page title
•.H2's and H3's: subheadings and sub-subheadings
•.H4: your blog's name, and possibly related widgets
•.H5: same as above: sidebars etc.
Makes sense right? The most important line on the page is the post or page title, second come the subheadings. Your blog title still has some value because, if the post is good, people will search later on for "Yoast WordPress SEO", for instance.
Structure of headings for your category / tag / taxonomy pages
If you actually want your category and tag pages to rank, meaning you've given them some unique content and are making them interesting for people, the heading structure should basically be the same as the homepage, with this difference:
•.H1: category / tag title
•.H2's: post titles
•.H3: blog's name
•.Rest: repeat from homepage.
Headings and HTML5
In HTML5 the entire method of dealing with HTML headings changes, and while it's a bit harder to grasp for people at first, the new system makes a lot more sense for content management systems. In short: headings and heading structures are section specific there, where section could be any part of a page. It would take too long to explain here, but if you're interested, read the header section of Mark Pilgrims excellent Dive into html5.
Truth be told, Mark doesn't talk about how search engines deal with HTML5 headers yet. In all honesty: I couldn't tell you yet. Simply a case of "not enough data to tell".
Conclusion: re-think your blog's headers
Now it's time for you to take some action. Go and use the W3 Validator now to check your blog's outline. If you've read an understood all the above, you should now be able to determine whether your theme is doing a good job. If you're using a premium theme or a theme that you downloaded from WordPress.org, I'd love for you to share your results in the comments!