A new (old) PHP forum on the way

Feeling a bit nostalgic, I tried my hand at PHP once again. Looks like I may have new forum script out using old code I’ve had lying around with excerpts I’ve found on tutorials. Expect the alpha to be out sometime over the weekend (assuming work doesn’t get in the way).

It will be using MySQL and have a total of six tables (some will not see action until the beta). The templating system is very basic and I’m going for bare minimum in features. A lot of it is inspired by the *chan imageboards, minus the sparsity of the UI and image uploading capabilities. More than likely, the core code would probably be on only one file.

I’ll be substituting “good” programming practices with “reasonable” ones instead. ;)

Update *cough* Monday 25th

OK, so the weekend was a bit over enthusiastic. Work did get in the way so I’ll have to push this back a bit.

15 thoughts on “A new (old) PHP forum on the way

  1. Very informative PHP.

    Speaking of which, I’m looking to go into the design phase today for my CMS. I’ve been trying to figure out how to pose the question – I figure I’ll just make a post on my blog that is open to all for suggestions, along with my own thoughts. But if you have any specific input for the CMS design, I’d love to hear it.

    • I think CMS design should be structure and output driven.
      Structure (parent child etc..) for all content. Output formatted depending on the type of content. I had a reply with more detail on this including a demo db schema on that JavaScript loader post’s comments.

      I would think a templating system would give you enough breathing room to concentrate on the core functionality. This way, you can use any ye olde HTML during the build phase to quickly find rendering quirks or add/remove aditional output to the browser.

      Smarty maybe?

      I came across an article by Brian Lozier. Don’t know if you’ve already come across this one; It’s a few years old. But I think it has some good ideas on how to render output via templates. Would come in handy if you’ll go with your own template engine rather than a third party option.

      • Yep, I have both your previous article and the Smarty website linked on my CMS wiki page, as I intend to use both as I go.

        I also very much agree with a structure/output approach to architecture. Ideally, I was thinking almost of a node-based CMS, where each bit of functionality is essentially an independent and interlocking servlet that performs its core duty, but can access information held by other nodes, or servlets. The only consideration I’m having a difficult time with is how exactly to represent dependencies between nodes.

        For example (a bit extreme, but illustrates the idea) : suppose I created a node responsible for translating all the content from one language to another (or perhaps from english to binary…that’s always fun as a prank :P ). It would either have to be expressed as a dependency for every single other node, or it could operate independently in between all the other nodes and the output. While the latter would be much preferred, I’m not exactly sure how to structure the program so a single node could intercept all the output from all the other nodes, if each node is an independent entity.

      • Are we picturing the same thing when we say “node”? :P

        And then you need to consider how complex do you really need it?
        It is a CMS and though diving into this is a lot of fun, will you be able to complete it in a meaningful timeframe?

        In the end, you’ll need to map out what the software you’re writing is meant to do and won’t do and how it will handle both situations.

        Your description reminds me of a Property Bag.
        Arbitrary number of properties and arbritary number functions depending on need.

        Good thing is that there is inifinite flexibility.
        Bad thing is that there is infinite flexibility.

        I think there needs to be some sort of lockdown on node behavior to make sense of this. You may need to introduce node types (I.E. it’s a specific type based on which function nodes are assigned to handle it’s content). Dependency does seem like the practical approach in this case. Too much interdependency will make storage an issue (unless you’re going for an object database).

        You could work this out with some sort of inheritance with node primitives.

        Say, “translate” module node inheritance signals this content node is text and should be treated as such (I.E. enable WYSIWYG editing, activate the “Title” and “Description” fields etc…). And now the content will have related versions(EN, BIN etc…)

        The “file” module node inheritance means the original content node is a blob or at least holds the upload path. Inheriting the “file” node will also identify what the child node is (image, archive, document etc…) and activate appropriate properties for editing.

        Inheriting both “translate” and “file” nodes means this content is now available as a download and online text.

        Hope that makes sense.

  2. Pingback: It’s design time « Theatre of Consciousness

  3. Pingback: It’s design time » lolcat.us

  4. Pingback: Update on the new (old) PHP forum « This page intentionally left ugly

  5. Pingback: New (old) PHP forum SQL tables « This page intentionally left ugly

  6. Pingback: Forum Core.class.php progress update « This page intentionally left ugly

  7. Pingback: PHP Plugin/Module system « This page intentionally left ugly

  8. Pingback: Forum core source dump (as of July 31) « This page intentionally left ugly

  9. Pingback: What’s with the holdup? « This page intentionally left ugly

  10. Pingback: PHP Plugin/Module system | Текстиль & Ко

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s