Which CMS?

I'm just about to start a new site and wanted to know what CMS does a site like fuzz.com use?

I'm sure I could probably just do it with wordpress but want to know if there is something better for this.

 

seems t be a custom one , you can use joomla for this

 

The cheapest option is to use WordPress with a premium theme.

 

this is s good solution.

 

This is the way I was going to do it but thought it would be a good idea to ask here for a second opinion as I've only used wordpress for sites so far.

 

i think joomla or drupal is best and nothing else.consider either Drupal CMS that is being used by all US Presidential Candidates

 

i prefer joomla if you need an exact replica of fuzz, otherwise WP is the better solution. ( still it depends the business you gonna do there )

 

i wrote fuzz... well, a lot of it anyway.

The site's 100% custom:

I was the first engineer at fuzz and am the lead developer. when i first started I wrote a custom MVC framework, custom DB interaction/abstraction layer & a custom template system. things have been upgraded over time by myself and other dudes on my team but 80-90% of the core architecture is what it was when i first wrote it. why use custom stuff? well, i checked out a ton of stuff and it wasn't gonna cut it for a million different reasons.

I'm eventually going to open source the MVC, db and template stuff. I'm in the middle of doing a major upgrade to it. after the big upgrade and some time to document it i'll put it somewhere.

The stuff over at http://www.fuzz.com/articles/* is the only section of the site that kinda runs off something else. that "something else" is wordpress. Wordpress is ONLY used there for data entry. so the writers login to a wordpress installation which lives on its own box (has nothing to do with the rest of the site). the writers type their stuff in wordpress then an editor publishes it. When an article is saved or published custom wordpress plugins send a notice to the fuzz.com server to go grab the article. we then grab the entry and save it on the Fuzz.com side and when its displayed at http://www.fuzz.com/articles/* it flows thru our normal stack. So essentially all we use wordpress for is the data entry portion.

any specific questions? you wanna copy our site? maybe i can help

-Arin

 

Joomla all the way

 

Joomla a great cms. I use it on a couple sites and have had excellent results.

 

phatduckk, really great to hear it from you! thanks a lot. i may need your help. can i get your mail id( could you send it to my PM)

 

There are a lot of fans to Joomla and Drupal (and others).

But you can achieve all that with just Wordpress.

 

you guys can reach me at arin [at] fuzz [dot] com if you have any questions about stuff.

FWIW the whole sites in PHP and everything is object oriented. Every "page" is an object (we call 'em Action objects).

so for example there's a url www.fuzz.com/people/activity

Here the action is PeopleAction. The framework will instanciate a new instance of PeopleAction then call the "activity" function... so in very basic terms it ends up something like this:

$action = new PeopleAction ($bla, $bla);
$action->activity ();

somewhere in that mix we have a few little bits that go on. since each page is an object that extends our BaseAction they all implement a couple methods: setupVars (this sets up variables like loggedInUser and crap like that) then checkAccess gets called. checkAccess will kick a 403 if a user isn't allowed on that page (trying to edit someone else's profile etc).

The names of the actions and methods to call are based on the URL. so we have a few different types of actions each of which chops up the URL a different way.

a url like www.fuzz.com/fan/phatduckk/blog behaves mostly the same (created a FanAction object) except it knows that the second part of the path is a user's screenname. So when setupVars is called on this type of action we pull the user data for that screenname and set it as a var available to the rest of the FanAction object. then after that it knows to call the blog method on this same instance of FanAction.

the simplified code for that page is:

class FanAction
{
// bla bla
public function blog ()
{
$this->blog = $this->getBlogService()->getOrCreateBlog($this->getEntity ()); // entity setup in setupVars
$this->archiveEntriesList = $this->getBlogService()->getArchiveBlogList ($blog);
$this->render ();
}
}

so now the $this->render () part kicks you into the custom template system...

here a new template object is created. since the FanAction is creating this object it initializes a bunch of stuff. the important parts are the path to the template, whether to "wrap" the output in the site's chrome (or a different wrapper or nothing at all) and sets up the variables available in the template.

the template gets all the properties from the Action class that created it. so above we had $this->blog ... so in the template we have an variable called called $blog which is a ref to the same var that was in the fanAction instance. same with every other "$this" variable ($this->archiveEntriesList becomes $archiveEntriesList, $this->user becomes $user) etc etc

even in the template system we have some things that make life easier for us...

to render the contents of $archiveEntriesList we just do the following:

foreach ($archiveEntriesList as $blogEntry)
{
// $blogEntry is an instance of a BlogEntry object which implements the RenderAble interface
$blogEntry->render ();
}

so anything that implements RenderAble gets some magic. it knows how to render itself... aka it knows how to configure and use a Template object to turn itself into html (or xml actually).

beyond that the Template engine and the dispatcher we use are aware of their "style" so the directories they "know" to look in for their templates can be changed super easy in the program flow. this allows having multiple skins.

another thing to note is that we have an internal path translation we use too. we need this since Action's are determined by the first part of the path. So this would screw up things like going to / since there is no first part of that path... so due to that and other reasons we internally rewrite the path in certain cases. so / turns into /home which ends up as an instance of HomeAction ... this helps with keeping URLs pretty etc

so that's the front end... on the backend we have some more make-life-easy stuff.

we NEVER do mysql_query ("select * from bleh"). direct calls to the mysql functions are not "allowed". we just don't do em. we have a DB layer that we really like that makes our lives pretty damn easy....

to save a User object (like after a profile edit) we just call $dataLayer->save ($user). The DB layer knows what its doing and can turn objects that extend the Entity class into SQL or XML and visa versa. There's metadata that drives this so its not exhaustively dynamically creating SQL strings each time you call a DB function (that would be a serious waste of cycles).

custom queries work off a series of files that essentially have an assoc array of keys to SQL: so something like this:

$userQueries['getById'] = 'select * from user where id = $userId';

note the single quotes. these are used so $id doesn't get interpreted as a variable... yet. obviously these custom queries are more complicated than the one above but its an easy example. So we run this query do something like this

function getUserById ($id)
{
$queryData = array ('userId' => $id);
$user = $dbLayer->get ('User', 'getById', $queryData);
return $user;
}

$u = getUserById (99)


The db layer takes the $queryData's info and creates a SQL string based off queryData's and the str held in $userQueries['getById']. so the 'userId' key from the assoc array turns into $userId used in the SQL string. during this process all strings are escaped (so we a single place in all the code to deal with sql injection bs - kinda nice), numbers are not escaped and arrays are broken into "IN" syntax (ex 'IN (1,2,3,4,5)').

so once we run the query we take the result, turn it into a User object and return it.

This is a very simple and kinda BS example cuz things are more complicated but that's the jist. We also have this thing we call a Page object (short name for can-be-paginated). these objects have info like total results if LIMIT wasnt used, items per "page", current "page" current data (objects).

Again... these page objects are kinda smart and know how to render the data they have and the pagination links. theyre even smart enough to know the URL to the next page etc.

So there's a pretty crude explanation of how fuzz works. there's way more to it than that. we did some work up front to make future dev pretty damn easy. there's no real "magic" but there's a ton of things built in to make developing the system pretty easy.

hope that's helpful.

-Arin

 

phatduckk, Thank you so much for this very detailed info. you are so kind and helpful. really appreciated.

 

lol, phatduckk!

 

i'm using cmsms

 

And if you need help here's a review and a tutorial about Wordpress ...videos included.