Forum development for v0.8

thanks for the info. I'll take a look at that

Just a headsup that I have sparetime again so I can work on coding again

Everyone, duck! There's 000's and 111's about to fly

Prototype is now ver 1.7 (e107 is using ver 1.6) and scriptaculous is ver 1.9.0 (e107 is using ver 1.8.3) Just mentioning it in case someone wants to update what e107 is using.

Hey everyone..

in the table forum_posts, I would only need
forum_post_id
forum_thread_id

then in forum_thread table, I would have:
forum_thread_id
forum_forum_id

and in forum_f:
forum_forum_id
forum_parent_id

in forum_p
forum_parent_id


No need to carry more then 1 parent id over to the child right?
I wouldn't need forum_parent_id, forum_forum_id, forum_thread_id AND forum_post_id in forum_posts table right?

It would be overkill?
Or would it be easier if I carried all the id's over like I had posted earlier?

I am now making a parent delete function, so I need to delete the parent and all the forums, threads and posts associated with it.
If I only carry over 1 previous id over to the underlying table, I would need to first
query the forum_f for the forum_forum_id where forum_parent_id = $_GET['id'] and store this in $forum_forum_id
Then query forum_t for the forum_thread_id where forum_forum_id = $forum_forum_id and store this in $forum_thread_id
Then query forum_posts for the forum_post_id where forum_thread_id = $forum_thread_id

And then delete those recursivly.
Otherwise it would be;

delete parent,forum,thread, posts where forum_parent_id = $_GET['id']

However, does this take extra load on reading the forum with this extra info pulled from the db?
Or can I just skip querying this info from the mysql db and speed things up?
(so instead of SELECT * I select everything except the more than 1 parent id?)



What you guys think?

Just a small clarification:

IF I ONLY give the thread_id to the posts,
the forum_id to the threads,
and the parent_id to the forums,

I would need to make several arrays for which to check which posts to delete when a parent would get deleted.

check parent_id (pid), check forum_id (fid) for which parent_id is pid and place them in an array,

foreach $key->$value, check which thread_id (tid) has forum_id = $value and store this in an array.

Then check posts which have thread_id.

I don't know if this is beneficial to do, or just store all the overlaying id's in all the child tables like in this post: [-link-]

I think I will only give through the parent_id #.

So forum_p gets forum_parent_id,
forum_f gets forum_parent_id AND forum_forum_id,
forum_t gets forum_forum_id AND forum_thread_id,
forum_posts gets forum_thread_id AND forum_post_id

When moving forums or threads around, this would save some time I guess.
Loading threads will still be the same speed as before, (as you won't load overheading id's anymore, just 1)

I see in e107_user table the following columns:

user_lastvisit, user_currentvisit

I wonder if they work the same way I wanted to do my user_forum_oldtimestamp and user_forum_newtimestamp...

Cause then I might be able to use just these variables...?

I think the current visit becomes the last visit the next time you show up and a new current visit is saved.

I did some checking the other day and here is what I find out:

Before I go to my website, I check the mysql table for the user_lastvisit and user_currentvisit.
For example: My last visit was 2 days ago, and my current visit was from yesterday evening.
I then go to my website, and refresh the mysql table after.
Now, my last visit was from yesterday, and my current visit is the present.
When I navigate to another page, my last visit is STILL from yesterday, and my current visit refreshes to the current present.

In other words, the last visit isn't being updated everytime a page refreshes, so I don't know when this gets updated?
Also, this means it is useless to track new forum posts, otherwise read posts would still show up as unread, as I explained earlier.
I will need to use my own function for this then, and mysql table columns

Isn't last visit the last time you log in?

No, I'm always logged in.

I am not sure what it is...but in any case it's not suited to find new forum posts

I made this little function to keep the forum_p table always sorted and ordered.

Basicly, you can set the incremental ID yourself when creating a parent.
If the ID already exists, it brings you to the edit page of that parent, else you can create a parent with that forum_parent_id.
Same for editing, if the parent with the id you specified doesn't exist, it brings you to the create page for that parent.



Then I also added something cause I am neat;



(Don't mind the FORLAN cause its only raw code)
What this does is:
If you delete the latest parent it will make sure the next parent you create is with the incremental ID of the latest table entry. This way you don't have emtpy values.

Example:
You have 10 entries, and you delete 9-10.
Next value would be 11, but now, the value will be 9 and up again.

If you specify an ID number, you can fill in the gaps if you want.

Example:
You have 10 entries, and you delete 4-5.
You can specify ID = 4.
It then it orders them all correctly in the table again. (So ID 4 won't be the last entry, but is sorted again)

I have a question regarding db access:

If I use the following statement:

$sql->db_Select("forum_p", "*");

OR

$mysql_table = "forum_p";
$mysql_result = mysql_query("SELECT * FROM ".MPREFIX."$mysql_table") or die(mysql_error());

which one is better?

Using db_Select() would make the forum less stand alone right?
Since this function is from e107 and not a native php function right?
What is the benefit of using this function? [-link-]

I have another question regarding list retreaval:



I used the code from the original forum as an example and edited for us in the current forum.

Question:
Why is there a "_" suffix ?

And another question:



Do I have to provide this input on every form aswell?

Ok, I have answered a few questions by myself, only the e_TOKEN question remains as of so far.

my gut tells me it should be in every form, but I would love to have some expert input on that .

For the rest, I am almost done with the groundwork I think.
Creating parents and forums is working.

Why would you set a viewclass and a postclass in a parent AND in the forums?

Wouldn't it be better to set this in the parent and keep this in the forums?

Some thoughts on this please

As for the etoken, I would agree it would have to be included in every from but I'm no expert on that so hopefully someone who is can comment on it.

As for the seperation of view and post class per parent/forum. In situation where for example you want a forum category to be readable by a specific class, but you want one of the forums limited to posting to another userclass. I use this on quite a few installations myself.

Yes, each form needs to have this (I personally expect it as logical to put the hidden e-token input just before the submit button).
Do not forget to check it at the top of each program before calling class2 like this:

Right, this also fixed a " Access denied" upon processing the user_time installation form.

Is the e_TOKEN only needed at the backend? Or also in the frontend?