Making a cms (kind of)

[Jimerson]

I am working on making a cms system for my new gaming site.

I have a book here (Don't laugh at me) that goes step by step into how to build a news / cms system.

My question is however, If I start with their example and build that, will I be able to add other functionality in? Or am I better just trying to learn and build one from scratch.

Thanks for your understanding and help.

-Jim :hi:

[Pauly]

It depends what book it is I guess? I've found when reading books that it's generally best to follow the whole thing through, then start over again. That's just how I learn though, you're probably different.

Personally I like to follow instructions then see what I can make of it afterwards. I'm speaking more for graphics but the same applies ;)

[Jimerson]

See, I'm still in the learning stages. :) I am not sure that I could do anything by scratch yet.

[Pauly]

I'd follow it then, learn as you go, you can always build on what you make, or start over :)

[Jimerson]

I appreciate the advice :)

Thanks,
Jim

[Pauly]

No problem, I just hope it's the right advice :lol:

[Jimerson]

You wouldnt give me bad advice would you?

[BigBison]

While Pauly's advice sounds good on the surface, I'm afraid it amounts to "stick with the status quo thinking on content management", which just raises my hackles. What do I always say about CMS software, and by extension, any books explaining how they're built? They start off by putting their head squarely up their ass with this "MVC Architecture" business, which is not how the web works. It harkens back to how Bulletin Board Systems were built, before the URI was ever invented. The web runs on URIs, use them!

So if you want to build a simple, effective CMS don't listen to what the books say. Lay out your site as a bunch of static files in a hierarchical directory structure with descriptive URIs, instead of accessing each page in a non-web-like RPC (Remote Procedure Call) fashion where every resource "takes a number" and gets accessed through an API, for example, "showthread.php".

No, this is not something you can work around later by using mod_rewrite, you should really start with something where you won't need to rewrite any URLs, and where you won't need any "breadcrumb trails" to keep folks from getting lost on your site -- a good website or CMS design will have its breadcrumb trail reflected in its URL. Whole tomes have been written about REST, I'll leave you with these links:

http://naeblis.cx/rtomayko/2005/04/22/on-http-abuse
http://webservices.xml.com/lpt/a/ws/2002/02/20/rest.html
http://webservices.xml.com/lpt/a/ws/2002/02/06/rest.html
http://www.prescod.net/rest/mistakes/

If all the MVC-based CMSs out there are crap (they are) why would you build your own by reading a how-to book which glorifies their mistakes as desirable? </rant> (Sorry, Pauly, nothing personal it's just that this "MVC is the answer" crap has done more to kill the usefulness of the web than anything else...</extrarant>)

[Jimerson]

I'm not sure whether to thank you or hate you with that type of advice ;)


I will read into this.

Thanks,
Jim

[Christopher Lee]

With all due respect to BB:

Model View Controller is an archetecture that predates the web by years. It is a methodology for developing maintainable software. Implicating the MVC methodology because people improperly build the controller is akin to blaming the current crop of bad films on the chemical makeup of Film. It is a poor artist that blames his instrument.

[Jimerson]

You all are begining to lose me very quickly. I read over thoose articles they wer e a bit over my head however.

[BigBison]

Model View Controller is an archetecture that predates the web by years. It is a methodology for developing maintainable software. Implicating the MVC methodology because people improperly build the controller is akin to blaming the current crop of bad films on the chemical makeup of Film. It is a poor artist that blames his instrument.

Obviously, I beg to differ. The REST architectural model takes into account the medium the software is being developed for -- HTTP + URI, i.e. the Web. While MVC has its place, it's an electric guitar being played at a brass-band concert when applied to website content management. You can drive a screw in with a hammer, too, but that doesn't mean it's the right tool for the job.

;)

[Christopher Lee]

I won't argue the merits/pitfalls of REST archetecture, but I will state that an MVC system does not preclude the use of REST principals at all.

[Jimerson]

:? ehh?

[BigBison]

Yeah, sorry 'bout that. I don't really know of a "beginner's guide to REST" anywhere, or a REST-compliant CMS to look at as a guide. But really, it isn't so complicated, REST just describes how the Web works. If someone could put it in lay terms, most folks would nod along in agreement, muttering, "of course" and such.

[Christopher Lee]

The OpenSearch initiative from A9.com attempts to standardize searches using REST by establishing specifications for discovery of, generic format for use with REST based systems have included RDF, XTM, Atom, RSS (in its various flavours), and Plain Old XML (POX) with XLink to handle links.


One Quick Rule(tm) that I follow from REST is always use GET to get data, and always use POST to post data. Why? So people can bookmark a resource with a unique URI (examples: search results, multi-page documents). I had a larger reply, but really, it boiled down to this.

PUT and DELETE: I've never used, and I do not have any knowledge of anyone using those methods in a production environment. I've always known them as huge security holes, but I think that has become more "religious practice" than a hard-and-fast fact over the years.

Semantic URIs: I agree with Bison that a semantic URI is better than the http://crufjunk that tends to permeate many systems. However, note that:


http://www.example.org/users?surname=Michaels


Is perfectly acceptable in REST systems. In fact, an MVC Framework sweetheart (Ruby on Rails) is listed in the Wikipedia as an example:


Ruby on Rails URL routing supports RESTful application design using Model-view-controller design pattern


Basically, this is a highfalutin (http://dictionary.reference.com/search?r=2&q=highfalutin) argument that comes down to the same point: if you wish to build a high-quality CMS, ensure it creates quality, semantic links. My next post I'll actually post some practical tips on mistakes I've made over the years.

[sea otter]

Jimerson,

As you're new to coding, go with the book. Follow along what it does, build the system as it tells you to.

At some point (weeks? a month?) you'll feel comfortable enough with the language and syntax and libraries that you'll suddenly get the urge to change something in the code that you don't like or that's missing or that makes you simply say "gee, I wish it did that."

At this stage, you'll find it far more satisfying to put your "mark" on the code this way, rather than trying to write something new or learn new design methodologies.

Even adding something as simple as tag clouds (I'm sure the sample CMS doesn't have them) will give you exposure to working with various language libraries for databases, arrays, math, and client-side stuff like CSS and XHTML output, and get you in the right frame of mind for "modding" code and creating new stuff.

(BTW, Eric, I'm with you 100% on your take on MVC and the web).

[Christopher Lee]

Actual Practical Tips In No particular order:

Needs Assessment:
-Who are you designing this for? If this is for Grandpa, it best be as simple as possible to use. If it is for you, maybe you could forgo time on a pretty UI for some back-end improvement.

-What kind of content will this system manage? Is this to be updated hourly? Daily? Is it three pages that change maybe once a year? If it changes very little, perhaps that 46-table load balanced cluster is a bit of overkill. If it changes hourly and has 10,000 hts/hr, perhaps that $4.99 'Account for Life' using simple HTML pages might not be up to the task.

-Where will this system be utilized? Is this for an intranet or for the whole web?

-When do you have to have the system working? If you need the site up tomorrow, some features will have to be left out due to the nature of the space-time continuum. :)

Version Control:
Pick some method of version control and learn it, live it, love it. Even if it is the crudest form, a history folder with a daily snapshot, at least it is something! Really what you need is CVS or Subversion. When you toast your app when you write something stupid (we all do), or the production copy gets hosed (it does) you will thank the stars you have something.

Security:
Understand the flaws that the platform you develop for has, and how you can avoid it. Every platform has potholes you can fall through, and ways to inject it, so learn how you can avoid being 'PWN3D'.

Plan Twice Cut Once:
A pit I fall into all the time. Remember those four questions up top? Well, once you have your plan STICK TO IT! The next version can have the cool multi layered XML-Driven contextual AJAX-JSON hotswap content, but if it aint in the specification document, it DOES NOT GO IN. Note: the caps are for me, because I tend to violate this one all the dang time.

READ READ READ:
Read everything you can get your hands on (dead-tree and virtual), and then make up your own mind what constitutes a good design pattern.

[sea otter]

Actual practical tips...


Yes, they are. But I think it's all a bit OT for OP :)

NOT disagreeing with your points (they're excellent, every single one), but I think it's too early for that.

At this stage, the point is to "get coding", to "have fun" with it. He'll know when it's time to read the next level of book, research a VCS, or delve into the arcana of $_COOKIE vs $_SESSION (or some other equivalent language minutiae if not learning php).

When I first learned javascript, just about any old book or resource would do. But one day I suddenly realized that I was coding JS differently; more "inately". I suddenly "got" the language (and it's far more sophisticated than people realize; more like LISP than Java).

At that point, I had to start using new references (no pun intended). I had moved to the next level.

It just "kinda happens." You feel it.

[BigBison]

PUT and DELETE: I've never used, and I do not have any knowledge of anyone using those methods in a production environment. I've always known them as huge security holes, but I think that has become more "religious practice" than a hard-and-fast fact over the years.

Careful... Don't be claiming that there are any "huge security holes" in HTTP. The security holes in web servers result from operator error. Unfortunately, PUT and DELETE became generically associated with Microsoft's FrontPage extensions, which did have some security issues, it's all FUD and pretty much always has been. They're just other methods of the same tried-and-true, time-tested, rock-solid, nigh-unto-bulletproof HTTP protocol.

Find me a CMS which returns any status codes beyond 200 OK or 500 Internal Error. The custom error pages most generate come with a 200 OK response, despite the fact that we have a specific set of status codes (the 400 codes) which are designed to inform the client of a client-side error. Try submitting a post that's too long into vBulletin -- it gives an error message with a 200 OK response, instead of setting the value for a 413 or 414 error in Apache.

Why do all these CMSs override the basic functionality that's already built in to the HTTP servers they are running on? The Web only works because we allow it to be broken, but that's no reason to limit oneself to GET, PUT, 200 and 500 -- that's what, 5% of what HTTP can do if we let it? This is instead of forcing Apache to follow the MVC paradigm of a hosted CMS.

Try this thread on for size:

http://www.iwdn.net/showthread.php?t=3799

As you can see, there is plenty of use available for PUT and DELETE, which are easily configured to a different set of roles than GET or POST. While it's good that you understand the "idempotent GET" concept, it's improper to just use POST for every upstream interaction with the server. Personally, I use WebDAV to move files to and from my servers, and even to connect to my remote XML DB directly from eXcite, my XML editor.

File systems have evolved as a result of consensus that it is a sensible model which most humans can relate to. Hierarchical directory structures are the basis of how we store documents. Have you ever named files in your working directory, "1", "2", "3" etc. like a CMS? No, we try to name things and locate them in a way which makes sense to us. As a result, we've evolved a powerful system for setting file permissions based on directories and user roles, which doesn't change conceptually between Operating Systems, or most other types of software.

It's silly, IMO, to throw all of this built-in functionality out the window, and go with an RPC-type setup which requires us to then invent our own security system based on associating sequentially-numbered database entries with user roles somehow. This reinvention of the wheel is inherently inferior to just placing files in directories, and using the server's existing facilities (the time-tested, rock-solid, nigh-unto-bulletproof security method which has evolved as and from best practice) to restrict access to those directories.

Don't even get me started on all the problems with using cookies for authentication instead of HTTP AUTH headers. Don't even think about getting me started on the difficulties inherent in caching MVC web applications, which most don't even attempt, despite the fact that it could save us bandwidth, the one thing we are charged for!

Instead, with MVC, each resource has its own separate security settings with the application determining who may post and who may not after the request is received and processed. Left to its own devices, the HTTP server could take care of so much of this for us. Which is more secure, Apache or vBulletin? Apache hands down, even an open-source app like phpBB is still a 'proprietary' security implementation whereas using AUTH headers is a standard.

So build your app around a directory structure, not remote invocation of procedures, to take advantage of all the code built-in to Apache and your OS instead of bypassing it for a brand new, untested, proprietary security solution -- a concept which goes against the very openness which made the web such a success in the first place -- or even one that's been around a while as part of an application framework like PHP. Try to follow the IETF's RFCs, which are the result of years of collaboration resulting in widely-agreed-on standards for implementing Web applications. Is your book advising you to read the RFCs and referring to them often, or is it casually ignoring all the places where its advice goes against best practices? ;)

Semantic URIs: I agree with Bison that a semantic URI is better than the http://crufjunk that tends to permeate many systems. However, note that:

http://www.example.org/users?surname=Michaels

Is perfectly acceptable in REST systems.

Hmmm... Is it? You're not wrong per sé, there are cases where such an URL is not only acceptable but also desirable. Ostensibly, this resource is a user profile, though. So why are we sending a query to invoke a remote page-generating procedure? If this were truly a dynamic resource, like a query for every surname of Michaels, this would be OK. In such a case, we have a process which takes an argument and returns a result -- a query, not a request for the latest version of a specific file. Such an URL gives this dynamic result a static URL which may be bookmarked. Maybe there's a Michaels, maybe not.

However, if the resource is a user profile, this is really a static resource. Yes, a profile changes over time and may be edited by the user, but that's updating a static resource, not dynamically generating anything with a query. For as long as this person is a user on the system, they will have a resource on the website for their user profile. This data may even persist longer than the user remains on the system, and the data may even become outdated if not updated. But one thing we know -- there is a Michaels, so we assign him a URI like this:

http://example.com/users/Michaels/Lorne (or Michaels_Lorne)

If your back-end has to see that as /users?surname=Michaels&givename=Lorne that's fine, just don't inflict it on users, rewrite the URLs instead. Which brings me back to the fact that MVC systems are inherently non-hierarchical, so fitting them into such a paradigm is like trying to get the square peg into the round hole, but it can be done. I'm just saying that something which must be jiggered with mod_rewrite to look like a user-friendly hierarchy, in direct conflict to the way it is coded internally, isn't the best way to go about writing applications for the Web.

The other beef I have, is these MVC CMS books and advice always seem to start by assuming that we're better off storing our collection of text files (we're managing HTML files, not scientific or financial data) in a SQL database, which is just absurdly silly despite being so popular. How our collections of text files and images are best stored, is on a filesystem, not in a database. Most of these books don't ever explain just exactly why we need to store everything in a database, or explain that perhaps, just perhaps, that's why the search interfaces for these apps are so woefully bad compared to something like Google which is indexing and cacheing their output.

So write a CMS which manages a hierarchy of files on disk. If you have real data which belongs in a database (like keeping track of forum members' birthdays and such), save your database for those needs, there's certainly nothing wrong with having multiple files on disk (instead of one procedure like showthread.php) perform a MySQL query when they're served. But the assumption that everything must go into a DB and then traditional RPC front-end applications get developed for accessing and manipulating the data (a CMS) is fundamentally flawed, and as outmoded as making all web pages one big table layout.

The worst thing you can do, in terms of building a Web application given that the Web can overwhelm even a tiny site with traffic surges from time to time, is require that every request compile and execute a script, open and close a DB connection, and fail to cache any of the response. Yet that's exactly what most MVC CMSs do! </endranting>

[Christopher Lee]

Careful... Don't be claiming that there are any "huge security holes" in HTTP. The security holes in web servers result from operator error. Unfortunately, PUT and DELETE became generically associated with Microsoft's FrontPage extensions, which did have some security issues, it's all FUD and pretty much always has been. They're just other methods of the same tried-and-true, time-tested, rock-solid, nigh-unto-bulletproof HTTP protocol.


Never claimed one way or another. As I said, it is more a practice of time than one of logic for me.


Find me a CMS which returns any status codes beyond 200 OK or 500 Internal Error. The custom error pages most generate come with a 200 OK response, despite the fact that we have a specific set of status codes (the 400 codes) which are designed to inform the client of a client-side error. Try submitting a post that's too long into vBulletin -- it gives an error message with a 200 OK response, instead of setting the value for a 413 or 414 error in Apache.


I can't speak to every CMS in existence. However, this is not an error of a Methodology (MVC) it is a shortcoming of the developer.


Why do all these CMSs override the basic functionality that's already built in to the HTTP servers they are running on? The Web only works because we allow it to be broken, but that's no reason to limit oneself to GET, PUT, 200 and 500 -- that's what, 5% of what HTTP can do if we let it? This is instead of forcing Apache to follow the MVC paradigm of a hosted CMS.


The 'C' is for 'Controller' and exactly what developers are missing...it isn't a limitation of the framework...its the limitation of the people putting it to use.


Try this thread on for size:

http://www.iwdn.net/showthread.php?t=3799

As you can see, there is plenty of use available for PUT and DELETE, which are easily configured to a different set of roles than GET or POST. While it's good that you understand the "idempotent GET" concept, it's improper to just use POST for every upstream interaction with the server. Personally, I use WebDAV to move files to and from my servers, and even to connect to my remote XML DB directly from eXcite, my XML editor.

File systems have evolved as a result of consensus that it is a sensible model which most humans can relate to. Hierarchical directory structures are the basis of how we store documents. Have you ever named files in your working directory, "1", "2", "3" etc. like a CMS? No, we try to name things and locate them in a way which makes sense to us. As a result, we've evolved a powerful system for setting file permissions based on directories and user roles, which doesn't change conceptually between Operating Systems, or most other types of software.

It's silly, IMO, to throw all of this built-in functionality out the window, and go with an RPC-type setup which requires us to then invent our own security system based on associating sequentially-numbered database entries with user roles somehow. This reinvention of the wheel is inherently inferior to just placing files in directories, and using the server's existing facilities (the time-tested, rock-solid, nigh-unto-bulletproof security method which has evolved as and from best practice) to restrict access to those directories.


This is one point of disagreement that we have that isn't relevant to MVC as a methodology. I have never, ever seen a 'natural key' (because that is really what we are talking about, the 'naturalness of a URI as a discrete pointer to a resource, which is EXACTLY what rest is about) that was truly a key. Trust me, I've been on the other side of that arguement. Every 'natural key' I have EVER run across from the most expensive enterprise-y monster, to the simplest blog. Keys don't have to be sequential -- that's a convention born out of routine to most folks. But you don't need to implement a key-based system with an MVC framework, even if you use a key based system in your datastore.


Don't even get me started on all the problems with using cookies for authentication instead of HTTP AUTH headers. Don't even think about getting me started on the difficulties inherent in caching MVC web applications, which most don't even attempt, despite the fact that it could save us bandwidth, the one thing we are charged for!


Either method can be used in an MVC developed app. Basic or Digest is trivial to do in the simplest of scripting languages, say, PHP (http://us3.php.net/manual/en/features.http-auth.php). A developer can validate against a datastore with these systems, and retrieve personalization information from that store. None of this is limited by the MVC pattern and one could say, the webserver (Apache) is actually part of the controller!


Instead, with MVC, each resource has its own separate security settings with the application determining who may post and who may not after the request is received and processed. Left to its own devices, the HTTP server could take care of so much of this for us. Which is more secure, Apache or vBulletin? Apache hands down, even an open-source app like phpBB is still a 'proprietary' security implementation whereas using AUTH headers is a standard.


Again, MVC does not preclude the use of HTTP AUTH headers in an application. See above.

If the assertion is "why do so many systems use another method of authentication". The most likely answers are: ignorance and User-Dictated demands. Cookies are convenient because they allow the work of remembering passwords to be pushed back to their respective systems for a specified period of time. If cookies are encrypted with a good salt, I would argue that odds are that you arent going to crack it in a relevant period of time anyways. But no matter your thoughts on this subject, it isn't relevant to Model-View-Controller, its just a BAD implementation of the controller.


So build your app around a directory structure, not remote invocation of procedures, to take advantage of all the code built-in to Apache and your OS instead of bypassing it for a brand new, untested, proprietary security solution -- a concept which goes against the very openness which made the web such a success in the first place -- or even one that's been around a while as part of an application framework like PHP. Try to follow the IETF's RFCs, which are the result of years of collaboration resulting in widely-agreed-on standards for implementing Web applications. Is your book advising you to read the RFCs and referring to them often, or is it casually ignoring all the places where its advice goes against best practices? ;)


Using a directory structure can be the perfect fit for a CMS, or can turn into a WTF (http://thedailywtf.com) (Aint even gonna try to find the article that this relates to, I love the community there, but Community Server is the worst software in existence!) The point is: deep nested directories can choke and kill Data Access, just as badly as a dB that gets called 158 times on a page, and remains uncached. It is about understanding your toolkit, not about a particular design pattern.

[missing some text here...is this usual when the quote button is pressed?]


Hmmm... Is it? You're not wrong per sé, there are cases where such an URL is not only acceptable but also desirable. Ostensibly, this resource is a user profile, though. So why are we sending a query to invoke a remote page-generating procedure? If this were truly a dynamic resource, like a query for every surname of Michaels, this would be OK. In such a case, we have a process which takes an argument and returns a result -- a query, not a request for the latest version of a specific file. Such an URL gives this dynamic result a static URL which may be bookmarked. Maybe there's a Michaels, maybe not.

However, if the resource is a user profile, this is really a static resource. Yes, a profile changes over time and may be edited by the user, but that's updating a static resource, not dynamically generating anything with a query. For as long as this person is a user on the system, they will have a resource on the website for their user profile. This data may even persist longer than the user remains on the system, and the data may even become outdated if not updated. But one thing we know -- there is a Michaels, so we assign him a URI like this:

http://example.com/users/Michaels/Lorne (or Michaels_Lorne)

If your back-end has to see that as /users?surname=Michaels&givename=Lorne that's fine, just don't inflict it on users, rewrite the URLs instead. Which brings me back to the fact that MVC systems are inherently non-hierarchical, so fitting them into such a paradigm is like trying to get the square peg into the round hole, but it can be done. I'm just saying that something which must be jiggered with mod_rewrite to look like a user-friendly hierarchy, in direct conflict to the way it is coded internally, isn't the best way to go about writing applications for the Web.


Couple of thoughts:

How does the querystring surname=Michaels&givename=Lorne offer less syntactic information to me than /users/Michaels/Lorne. On the former, as a user I know that the resource points to Lorne Michaels record. On the latter, does the record point to Lorne Michaels or Michaels Lorne? I assert that it contains few if any syntatic hints at all.

As far as "conflict with its internal structure": because Apache is really part of the 'Controller' part of the application, an MVC-designed application doesn't violate any sort of principal of a REST-based application, it ENCOURAGES IT.


The other beef I have, is these MVC CMS books and advice always seem to start by assuming that we're better off storing our collection of text files (we're managing HTML files, not scientific or financial data) in a SQL database, which is just absurdly silly despite being so popular. How our collections of text files and images are best stored, is on a filesystem, not in a database. Most of these books don't ever explain just exactly why we need to store everything in a database, or explain that perhaps, just perhaps, that's why the search interfaces for these apps are so woefully bad compared to something like Google which is indexing and cacheing their output.



I can't speak to the design patterns of any book, but using text files does not preclude the use of a SQL database in the back end, just bad design patterns on the part of developers. I imagine the reason books use this as an example is for the exact reason that sea otter posited earlier in this thread - that learning students need to "Hello, World" before they can load balance an app. Do this qualify as CMS? Well, the term is so widespread that perhaps the answer is "yes", but its debatable. Are beginner books really dealing with MVC patterns anyway, or are the teaching the reader how to yank and push data into a poorly-normalized SQL datastore. I think the answer is much more of the latter, than the former.


So write a CMS which manages a hierarchy of files on disk. If you have real data which belongs in a database (like keeping track of forum members' birthdays and such), save your database for those needs, there's certainly nothing wrong with having multiple files on disk (instead of one procedure like showthread.php) perform a MySQL query when they're served. But the assumption that everything must go into a DB and then traditional RPC front-end applications get developed for accessing and manipulating the data (a CMS) is fundamentally flawed, and as outmoded as making all web pages one big table layout.


Again, MVC doesn't FORCE you into any particular practice. It doesn't keep you from best practices regarding data storage either. In fact, if you go to most newbie forums and the question "how do I store images in my dB?" the answer most often given is "you can store it as a BLOB [or whatever is appropriate] but, just store the path to the image, it'll save you." The model can pull from or encompass the datastore. In fact, from the [very] brief overview of your system, that it has been designed around an MVC style design pattern!


The worst thing you can do, in terms of building a Web application given that the Web can overwhelm even a tiny site with traffic surges from time to time, is require that every request compile and execute a script, open and close a DB connection, and fail to cache any of the response. Yet that's exactly what most MVC CMSs do! </endranting>

Again, no argueing that there are frameworks and/or CMS systems that claim those titles, yet do exactly as you outline, open-slopit-closit round-robin. But that is not the result of the MVC design pattern, it is, in short, the result of designers and their decision good or ill in using the tools in their respective toolkit.

[sea otter]

Eric and Christopher, are you two done crapping all over this thread?

Can we get back on topic? DID YOU NOT EVEN NOTICE the OP becoming increasingly disillusioned with the direction things were going?

If you two wanna slog it out, start another thread.

sheesh.

*shakes head, walks off*

[Christopher Lee]

To avoid "Crapping all over the thread again"

I am working on making a cms system for my new gaming site.

I have a book here (Don't laugh at me) that goes step by step into how to build a news / cms system.

My question is however, If I start with their example and build that, will I be able to add other functionality in? Or am I better just trying to learn and build one from scratch.

Thanks for your understanding and help.

-Jim :hi:

Build it from the book, then take it apart, piece-by-piece, and put it back together again. Just like if you were trying to figure out how a toaster worked.

I don't think it is possible to write something that you can't extend later, at least 9 times out of ten. Even if it is written "poorly"[1] if you've learned something from writing the system, you will figure out how to change it.

Save the estoteric stuff in this thread for later. Think about it this way: you're trying to learn your ABCs, maybe read a book. But you shouldn't expect to write Moby Dick out of the gate. Take it in steps that works for you.

Later, download other pieces of software. This site has some folks working on a "Bespoke Blog". Download that, Wordpress, PHPNuke, Drupal and all the others that you can get your hands on. (But not all at once, as you'll freak yourself out.) Check out how they do stuff. Observe the pitfalls they have in their software. See if you can't implement some of the features that you like in those systems in your own.

Oh, and finally: there is nothing more admirable than someone attempting to learn something. Anyone that belittles you is simply insecure. Go for it.

[1] "Poorly is a subjective term. Does your system work, or doesn't it. At the end of the day that is a 1|0 proposition, and the subjective label is just background color.

[ethicaldesign]

Eric and Christopher, are you two done crapping all over this thread?

Can we get back on topic? DID YOU NOT EVEN NOTICE the OP becoming increasingly disillusioned with the direction things were going?

If you two wanna slog it out, start another thread.

sheesh.

*shakes head, walks off*

:notworthy

I'm glad someone said it (I was thinking the same thing myself, though I have to admit I was enjoying reading the discussion between Eric and Christopher aswell). Perhaps one of the mods could split this thread and tidy it up and move some of it to a new thread.

[Jamie]

Perhaps one of the mods could split this thread and tidy it up and move some of it to a new thread.

If somebody could give me a thread title, I'll happily split the posts. I got lost too (Damn Eric, you always lose me. :lol:) so I'm not quite sure what the subject should be named. Open for suggestions...

[BigBison]

I think we're done here.

[rich w]

Ok so here's a question..

I'm currently writing 'a system' which allows users to edit the content etc on the pages. The clever bit is the ability to create new pages of the site...not done using id=232 etc, but actually physically creating files, with meaningful names.

So what kind of CMS system is that?

[sea otter]

^^^ A wiki?

[rich w]

Could be!

[BigBison]

Yeah, check out PmWiki:

http://www.pmwiki.org/

No DB needed, nice URI scheme but not REST compliant (POSTs go to a different URL).

[rich w]

Ah it's a bit more sophisticated than a wiki I think...supports file management etc, and literally builds the site itself :)

Guess i'll see how it develops!