This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
511
The Pub / Re: Getting ready for an alpha release: CSS fixes
« on September 2nd, 2012, 09:37 AM »
Also b and HTML
512
Off-topic / Re: PHPSESSID Brute force
« on August 23rd, 2012, 03:09 PM »
Sometimes poeple have the same IP:
like Proxys and Networks (AOL)...
like Proxys and Networks (AOL)...
513
Off-topic / Re: PHPSESSID Brute force
« on August 23rd, 2012, 10:27 AM »
So what about the php build in session_regenerate_id() funktion?
Perhaps not the perfect solution but it will be more difficult to fix an session.
What do you think?
Perhaps not the perfect solution but it will be more difficult to fix an session.
What do you think?
514
The Pub / Re: Print Page
« on August 20th, 2012, 10:24 AM »
For me it's OK to stay in core. But with permissions attached.
515
The Pub / Re: Getting ready for an alpha release...
« on August 20th, 2012, 09:59 AM »Just take a short look at your install.sql and i have a view remarks:
boards table:
In boards table there is no field named id_draft where you define: PRIMARY KEY (id_draft).
Perhaps change PRIMARY to id_board?
What about the messages table?
Do not need to have an PRIMARY KEY on id_msg?
Also the topics table. No PRIMARAY KEY?
board_members, group_moderators, log_boards, log_mark_read, moderators and subscriptions_groups:
ENGINE=MyISAM ?
This is my first view. Will take a deeper look later.
THX for all your work!!!
Sven
516
Features / Re: Auto_increment madness...
« on July 11th, 2012, 12:41 PM »
This will look for "empty" ID's and put it into the database. Soo you can besure to have always the right value in your databse.
517
Features / Re: Auto_increment madness...
« on July 11th, 2012, 12:36 PM »
One way is to join the table by itself and do a select statement before inserting.
Perhaps something like this:
Code: [Select]
Perhaps something like this:
SELECT A.ID+1 AS NEXTID FROM drafts LEFT JOIN drafts ON A.ID+1 = B.ID WHERE B.ID IS NULL ORDER BY A.ID LIMIT 1;
518
Features / Re: Database field formats
« on July 2nd, 2012, 05:09 PM »Quote I would consider using MEDIUMINT UNSIGNED for all fields.Yes. But the description "all fields" where ment for id_board and id_album.Quote Except for where we have to have signed fields. Which is more than you'd think. And there are quite a few places where INT is still required too, like timestamps.
Perhaps we should merge id_board and id_album together to id_item or something else?
This should be done by adding another field to the table (e.g. is_board) to determine that id_item is a board or an album,
Only a suggestion.Quote There shouldn't be a performance difference, the only advantage you get is a slightly smaller table size (25%) by using MEDIUMINT instead of INT.Yes. You're right.Quote Except for the fact you don't just get a smaller table, you get smaller indexes too. And that does make a difference for querying times.
519
Features / Re: Database field formats
« on July 2nd, 2012, 04:40 PM »I would consider using MEDIUMINT UNSIGNED for all fields.
MEDIUMINT gives you enough space up to 16M rows (unsigned).
There shouldn't be a performance difference, the only advantage you get is a slightly smaller table size (25%) by using MEDIUMINT instead of INT.
The number in parentheses (int10) in a type declaration is the
display width, which is unrelated to the range of values that can be stored in a data type.
520
The Pub / Re: Database Backup, Restore and Repair
« on April 27th, 2012, 02:00 PM »
We use Percona as DB-Server with XtraBackup. Works like a charme. Even with incremental Backups.
521
Archived fixes / Re: Error when posting a large image...
« on April 26th, 2012, 08:20 PM »
By the way one suggestion...
In Subs-Graphic.php there will be an call for extra memory (48M).
If you have to deal with large pictures AND using GD this is realy not enough.
You'll always get error 500 in all topics with larger images.
Have to mess around with this problem for five days now. Just set this value to 256M and all is working like a charme again.
In Subs-Graphic.php there will be an call for extra memory (48M).
If you have to deal with large pictures AND using GD this is realy not enough.
You'll always get error 500 in all topics with larger images.
Have to mess around with this problem for five days now. Just set this value to 256M and all is working like a charme again.
522
Features / Re: timeformat annoys me...
« on April 3rd, 2012, 02:12 PM »
Did you try it with %-e ?
The "-" option requests no padding.
The "-" option requests no padding.
523
Off-topic / Need something for your kids to do over Easter ?
« on April 3rd, 2012, 10:26 AM »
Here we go : :eheh:
524
Bug reports / Re: Board order issues
« on March 29th, 2012, 10:27 PM »(You may have to move a board, then move it back to force MySQL to rebuild the indexes, assuming it's in a MyISAM table)
525
Bug reports / Re: Board order issues
« on March 29th, 2012, 07:35 AM »
By the way. For use with InnoDB the categories table must be updated too:
Code: [Select]
ALTER TABLE `$prefix_categories` ADD UNIQUE KEY (`id_cat`), DROP PRIMARY KEY, ADD PRIMARY KEY ( `cat_order`, `id_cat` ), ENGINE=InnoDB;