I'm new in these forums because I need advice for a new web project I'm working on.
So what I'm looking for is advice on where to start, how to dig deeper into the right technologies, whether or not I should rely on a specific framework, how to not just get the site working but also be secure (we're dealing with private information, right?), and so on.
Any help is more than appreciated!
This looks interesting, but I guess such questions should go into General Web Development & Application Design Issues subforum?
I never developed a forum/online-community type software, but I do have member profiles and private messages feature in my browser-game application. I believe you should start by designing the architecture of your software, usually a proper interface design takes longer than writing the actual PHP implementation code. In a multi-layered system, you need to properly separate your application into appropriate layers like Domain layer, Application Layer and Presentation Layer, while make sure not to mix code from one layer to another. Using frameworks will make it easier for you(it already does separation of concerns behind the scenes), but on the other hand you lose some flexibility/controllability of your web application.
In the meantime, think about what features you plan to implement for your project and how complex you need them to be. I am assuming yours is not an one-and-done application so you will continue to work on new features after its initial deployment. In this case, always design with future insights, try to decouple your classes from each other as much as you can so they can be easily maintained and extended in future. Security is another important thing to think about, for my own application I use a combination of Username, Password(original), Salt and Pepper with sha512 to create a highly complex hash, but there are other issues to worry about such as SQL injection and XSS attack. You probably want to read some online articles to see each security risk/attack possible for PHP application, a rule of thumb is never to trust user input data.
After the initial planning stage, you will start by designing the database structure/layout(unless you dont use persistent storage, its will be hard to believe). Your database tables usually map directly to your model classes(assuming you know what Model mean from MVC), so they are somewhat coupled to each other. A mistake made at the database design level will be difficult to fix in later application code implementation stage, so be extra careful here. When you have a database structure completed, write the corresponding domain models and fill in your business logic. It may not be easy to figure them out all at once, but development process is iterative so you can always get back to your business layer and make some changes later after you are more familiar with the needs for your clients. Note your database scheme and domain models are not application-specific, try to design them in a way that they can be easily ported from one application to another.
The very last step should be writing the application code and finishing off your presentation layer, these are application-specific and tied to the very forum/online-community app you are working on. If the business layer does not provide functionality needed by your application/presentation layer, you may now go back to the domain layer and add more logic to it. Lets say you have a Registration system, you will need the database for users to exist first, and then a domain model for registered users to work, before even starting to worry about the application code for user registration. Its not a good idea to reverse the order(unless you are doing big refactoring of a procedural legacy code trying to convert it into OO architecture, but this will be a different topic).
Once the Registration/Authentification system works, you will be able to design a User Profile system next. There are again some other design decisions you have to make, you probably will need to persist the user profile data so create another database table for user profile if you havent done that yet. It will map to another domain model for user profile, which depends on the user domain model itself(use composition to associate a user with his/her profile). At last, you can work on the application code and the actual presentation/HTML design for your User Profile page. To add other features to your application, repeat the same process, always design at database/domain level first and then worry about the application code, everything has to be done in a logical order.
Thanks for taking the time to give such deep insightful thoughts, I guess I understand most of what you mean, but this is really next level sh - uhm - stuff for me, so there's a lot of catching up for me to do. I'd love to get someone involved who's already experienced with this who I can sit together and talk through with, but I either know one nor do I have the money to hire somebody. But I always just tried to find my own ways to achieve whatever I want to, so I'm confident with a lot of learning and taking time and investing of blood, sweat and tears I am able to make it, and maybe I am able to find somebody who helps along the way.
Just to avoid misunderstandings, what exactly do you mean by Domain Layer, Application Layer and Presentation Layer? I guess Presentation Layer is pretty obvious, but what about the other two?
Thats a good question. Its not that easy to distinguish Domain layer from Application Layer, a rule of thumb is that the latter is application-specific(tied to the very application you are currently developing) while the latter is more generic. Lets say you have an ItemShop system, one application may have a standard official itemshop in which you buy from the site, while another application will probably be more like an auction/bid website that you buy from another user, similar to eBay. There's a chance that your site will have both of them, and that will be another application(or a combo application). At this point, it will be necessary to distinguish which methods/logic should go into Domain layer and what else belong to the application layer. For instance, the items are all purchasable, so behaviors such as acquiring the item's price, and checking whether the customer can afford his/her invoice should belong to the domain layer. Other behaviors such as placing a bid for an item should go into application layer, as the capability of bidding for items is specific to auction itemshop system. Again, the domain/business layer contains more reusable objects and methods that can be ported from one application to another, while application layer contains objects and behaviors that are strongly tied to the very application you are currently developing. You can always ask a question here on SitePoint whether a behavior should belong to domain or application layer, I am sure expert coders will love to engage in this kind of discussion and help you figure out the best answer(after all, the forum needs more users asking intermediate to advanced programming/design questions than mysql not loading data type of newbie topics).
Yeah I guess the newbie "Why doesn't this and that work" kinda questions will follow later on For now I just need a heads up on where to even begin with this, as I've never worked on such a deep programming level. But thanks again, this has already helped alot, and if you have any further advice or ressources where to read on just keep em coming
I don't believe that the requirements that have been specified are so unique that they warrant a completely custom solution. There is nothing new about message boards, member profiles, and private messaging. I myself would build it in a tool I know which would probably be either Drupal 7/8 depending on the project deadline. Putting aside the requirements that have not been listed someone who know Drupal well could probably build the site/application in about half or even less the time it would take to reinvent the wheel. I guess that would all depend on the other requirements as well and whether the admin would need to be customized. You could probably even get away with Wordpress but I hate Wordpress so I myself would never recommend it.
Actually I have been thinking about doing the same, just not in PHP but in python. My efforts are still pretty much on the drawing board. However I think you need to define clearly your motivation for such a project if even only to yourself. For me its along the following :
No excellent forum software for Python seems to exist.
I haven't found a forum with a good plugin system that doesn't involve either monkey-patching, poor documentation or badly designed database (and one popular one is exceedingly bad not just awkward).
a template system that isn't stored in hard to edit xml files (I prefer html files as templates) and encourages 3rd party template creation
a lack of suitable rest api for integrating with other systems
difficulty in changing or bridging with other authentication systems
Anyway, would be interested to hear where they fall short of being an excellent choice for your requirements.
One could always have a look at discourse.org for the latest innovations in community portal web software. Its written in ruby but it has some interesting concepts.
I agree that building a forum/message-board software can be achieved with PHP frameworks, but not sure if Drupal is enough for this. After all, CMS like Drupal and Joomla aint like MVC/MVP frameworks, and they have their own limitations that prevent them from being as flexible and reusable/maintainable as Zend/Symfony/CakePHP frameworks.
What makes you think that Drupal 8 would not be appropriate for this project? Have you ever used Drupal 6/7/8? If not than what makes you qualified to say it is not an adequate framework to satisfy the business needs of this project? I will have you know that Drupal 8 is pretty much a complete rewrite of the entire system using several Symfony 2 components including the DI container and router. There is no reason why you can't write a Drupal 8 application/site in a away that models MVP with the way the system has been reinvented from an architectural standpoint. Drupal 8 is probably one of the most powerful, well architected CMF's available. Drupal 8 is probably about 75% object oriented as this point. I believe Drupal 9 the hook system is getting removed and being replaced completely with events.
If you want do it then do it. You should definitely use MVC framework and other popular frameworks. I can give advise on Java but I'm cluless on PHP. Isn't those CMS open source? maybe you can take their code and modify to your own need.
My strong point isn't PHP.
However, since you are most conversant in that perhaps if you outline to us why, for example, Wordpress/Buddypress/bbpress falls short of your needs I might get a better handle on your unique requirements.
This topic is now closed. New replies are no longer allowed.