Posted by StapleButter

---

First question, why do we have the option to choose the redirect type? Most people are going to either choose instant redirects or not care. While it's nice to give them the choice, I don't believe it's very useful.


Then, I looked into the code, and the way it's done isn't the cleanest. I may give some help in adopting a cleaner code structure when I find some time/will.

How I typically do these things is basically:

1. check if a POST action was requested (if not, jump to 4)
2. if so, run the appropriate checks on the input. Raise some error flag if something is wrong.
3. If no error happened, perform the action, send Location header and die()

4. start HTML output (pageheader() for Acmlmboard)
5. if an error was raised, display it
6. display the form, with the appropriate data


That's basically how I did it for editprofile. This method also addresses the issue of 'when to send header()s/cookies without getting "headers already sent"'.

It also makes error reporting more user-friendly. Right now, if your submission has an error, it sends you to a separate error page that invites you to just come back to the forum/thread instead of going back to correct your input.


Relatedly: newthread/newreply/editpost/sendprivate have their form code duplicated between normal and preview modes. That has no reason to be.


This isn't to complain about the code, but to give pointers for the code cleanup/refactor that we're planning.

---

I could run a query and see how many people on Kafuka used the feature. I don't think getting rid of it in 2.5/6 without serious discussion first due to it's legacy nature.

You tend think of things more on the code end, and I tend to think of it more on the end user side. While to everyone else in the world would never use the redirects, there are a few (and shrinking) people who may or will use it for the Acmlmboard nature. So it may not hurt to still include a check and to always show it. That little bit of extra run time/sql is likely worth it. If we rework it, and we find no one does use it can pull it out if we deem in completely bloaty. We'll need some more input but we can talk more about it.

Otherwise I agree. I like approach for an unified notfication/editing system. We also need to reduce or eliminate all duplicate code as you just said.

No complaints.. they are just observations

Actually I think we should push for the overhaul as SB layed out. I'd still like more options so I've moved this into the public discussion area. Feel free to throw in your two cents!

Staplebutter: indeed. I would. Sounds like it's progressed further than our current setup (as suspected).

Posted by StapleButter

---

I wouldn't say my code is better or worse, it still lacks some features that are part of 2.5 or even 2.1. It's just following a different direction. Pretty much like ABXD vs Blargboard back then.

However I do think that 2.5 needs simplification. The permission system should be simplified (things like group inheritance are understandable but in practice they tend to overcomplicate things, esp. GUI wise), and some other changes should be done to generally make the codebase cleaner, more consistent and more efficient.

It's still using a ton of queries per page. That's better than storing the entire database in RAM, though.

Also, things like the NEW counters. Those should be static images. In fact: see there, announcement about numgfx. It's kinda like we're going backwards there

The sprite system should be an addon. It's not a generally wanted board feature, it's something that is made for this board and gives it character, pretty much like Board2's dodongos or Jul's Ikachan.

---

Sprites are indeed meant to be an Addon.. just we've never really bothered to create an addon system lol. Agreed. I want to have it out for the migration to github so we can not have to flood the tree with BLOB images.

Templates are another thing that's needed. I don't know if you are templateing your fork but I think that's a required step for any real board going forward.

Actually all of the images used are static images pulled with individual Image tags. We Should have limited to no dynamic images save the RPG one on the profile. Really there is no difference on output 1 or a *img src="meh/1.png" /* that's a client side issue.

I agree for the perms, We could limit it down to the point of making sense. Right now if your not familure enough with this code it's like another language. I doubt anyone is doing a spec sheet on it anytime soon. ;D

Actually to be perfectly honest I really think what you are doing for your board is the right path. So you don't really have to twist my arm Lol. I really don't want to abandon what has been done however. If anything Maybe an official fork or revision (2.6) could be done to wrangle it in and not have to lose everything put in already.

I don't have the time to code anymore. Really I only have enough to time to put in my two cents. My goals from now on to audit code I get and approve or reject it. (Which as you can see are slow as I have about 30 commits from Squiddy that are just sitting there)

So what do you propose (in full)?

Well I would rather an Intermediate or higher skill level person tackle that one as it's such a linchpin of the board it needs to be designed, than executed with optimizations on the fly. If you try to do it too 'green' it could end up becoming a bear that eats you.

Acmlmboard 3.0 requires dedicated coders. Last time I checked we don't have enough of those to fill a thimble. (and that's with me included). I think you are absolutely right, but we should only start that if it's going to have the support it needs to succeed. Also I feel we should at least one dev with the python experience to make the code solid from day one. Otherwise we could repeat a mistake that experience would have prevented us from doing. That's not a requirement though.. part of learning is just doing it. Again another factor is I am not in a position to give the time required myself either. I don't have to be for the project to start, but I also can guide it from a mile away either.

A 2.6 rewrite of the PHP board is feasible but the same constraints apply in terms of my time. A real plan would have to be drawn up and we would have to focus on making it lean; removing pointless functions; condensing functions, and make it rock solid.

How is blargboard a failure? I mean people use it don't they?

Edit: Python works with any DB. you aren't stuck with PGSQL

Posted by StapleButter

---

Hell we could base if off Ninji's bitBoard. If we got rid of SQLAlchemy that is.


Sure, it's possible to write shit code in any language, but PHP makes it easier to mess shit up. It was built for quick dirty coding, and it shows. Any sane language offers some safety, PHP doesn't.

* use an undefined constant? or typo in a constant name? instead of throwing an error like any sane language does, it assumes you meant the corresponding string (for shit like $array[blarg]). It throws a notice but that's all.

* variables are more or less the same, any non-existing variable is automatically created with an empty value, you don't really declare variables

* function names are case insensitive, but everything else is case sensitive (what?!)

* OOP feels... tacked on, as if you added some weird plugin to PHP

* then there's shit like magic_quotes and register_globals, but those are being removed


The only thing PHP has for it is that it's present everywhere and gets you going quickly.


As for Blargboard, well... this sums it up well.

---

I have thought about bitboard. It's an option indeed. We wouldn't have to start from scratch and Ninji's code could has a chance to continue on. It's not off the table..

To add PHP is a terribly inconstant language that was based off of three totally different language types. I am not a fan of it at all. It is indeed quick to pick up and is often a person's first language in this day in age. What sucks is it allows a lot of things other languages would have issue with.

---

Most of the people who download forum software expect to be able to run it and customize it without needing to edit code or open PMA. It's a tough market.

---

Well that's why 2.5 is heavy on the perms and such. However it's not even middle ground of what people want so it's kinda just.. eh. I really don't care if this project is a popular board. Frankly I just want to make sure it exists for those who do want to put the time in to maintain such a board. I also don't want Acmlm's work to die. That's all this is and ever was. At first we did try to make it more inclusive and try to make something that maybe would be considered in a more mainstream way. However if you checkout the code I made sure to tag every major version so that if you wanted to go wind back to very day that we got the code from BH you could (without having to sift the git log or look for the commit hash). That's real goal. Make sure the code sit on some guys HD for ever and no one can ever do anything else with it.

Also for the record I thought Blargboard was successful project. It's by far the most sane and useful of the AB/AB clones for an end user. Sure you still have to mod the files and do a lot of work, and that seems to turn people off. You what, that's fine. Forget them. Just because a project aren't successful in the one area (in this case public option/adoption rates) does not mean it's a failure. Did you have fun doing it? Did you learn something while doing it? Than it's all good. Decided that stopping the project and moving on also doesn't mean it's a failure. You just found something that fits better or gives you more enjoyment/learning chances/etc.

In this business you can't be disheartening by lolipants. It's going to happen. All of that stuff will put you off indeed. But I can respect your reasons. It's hard not to lose motivation sometimes. Sometimes you have to shut out the noise and just go with your guts.