all very nice but I don’t want to hash the password – I want it raw.
Too late now I have added my own code and field to the table to fix it
The password is saved in the table in an encrypted form that can be decrypted as and when required.
all very nice but I don’t want to hash the password – I want it raw.
Too late now I have added my own code and field to the table to fix it
The password is saved in the table in an encrypted form that can be decrypted as and when required.
The solution will be to dig into the code, add an extra field to the table, and set this field with the real password (encrypted with a workable encryption routine) the next time a forum user logs on.
After a reasonable length of time all users should have logged back on and an accessible copy of the password obtained.
As said I still don’t understand why the md5(‘mypass’) does not match the one in the table – there must be a comparison made at some stage or no one would ever get logged in.
The solution will be to dig into the code, add an extra field to the table, and set this field with the real password (encrypted with a workable encryption routine) the next time a forum user logs on.
After a reasonable length of time all users should have logged back on and an accessible copy of the password obtained.
As said I still don’t understand why the md5(‘mypass’) does not match the one in the table – there must be a comparison made at some stage or no one would ever get logged in.
Perhaps the only solution to this is to replace all the hashing code and store a retrievable passford in the field.
It is going to really upset the users having to go through registration again but it is far better getting one hit of all the frustrated users while I can blame it on the dumb software rather than being hit by the same problem time and time again as new users forget their passwords, we integrate other systems, etc.
I still don’t get why md5(mypass) doesn’t give the same as in the database and I really cannot be bothered unraveling all the code to find out what is not obvious.
Perhaps the only solution to this is to replace all the hashing code and store a retrievable passford in the field.
It is going to really upset the users having to go through registration again but it is far better getting one hit of all the frustrated users while I can blame it on the dumb software rather than being hit by the same problem time and time again as new users forget their passwords, we integrate other systems, etc.
I still don’t get why md5(mypass) doesn’t give the same as in the database and I really cannot be bothered unraveling all the code to find out what is not obvious.
Sorry, I’m confused – either it is or isn’t.
As the user logs on regularly to bbPress they enter their user name and their password.
I presume that these are compared with the values in the database to enable logon. Either the given password is md5()’d or the database value is unencrypted to make this comparison.
As I have tried md5(‘mypass’) and it does not produce the same value as in the database something fishy is going on.
Sorry, I’m confused – either it is or isn’t.
As the user logs on regularly to bbPress they enter their user name and their password.
I presume that these are compared with the values in the database to enable logon. Either the given password is md5()’d or the database value is unencrypted to make this comparison.
As I have tried md5(‘mypass’) and it does not produce the same value as in the database something fishy is going on.
That’s where you are wrong!
In the case of views (the number of times a topic is viewed), and yes I DO mean views and NOT voices (the number of different contributors to a topic)
look here for an example http://www.steamsheds.co.uk/bbpress/
On the subject of spaghetti code:
Perhaps the fact that you cannot find the bit that tags the number of views on to the topic title – makes my point.
That’s where you are wrong!
In the case of views (the number of times a topic is viewed), and yes I DO mean views and NOT voices (the number of different contributors to a topic)
look here for an example http://www.steamsheds.co.uk/bbpress/
On the subject of spaghetti code:
Perhaps the fact that you cannot find the bit that tags the number of views on to the topic title – makes my point.
I find all this SCN TRAC TRUNK all a bit gibberish and well beyond what I need to know.
I find the version control of bbPress also confusing and always thought that the most stable version was on the main download page.
The “bug” being discussed is not a show stopper (there are more irritating things) but it is fairly obvious in the code what is breaking this.
Two things in functions.bb-template.php
The use of <fieldset> and <div> inside the form – comment them out in bb_get_topic_move_dropdown() and add the lines
$r .= bb_get_topic_delete_link($args);
$r .= bb_get_topic_close_link($args);
$r .= bb_get_topic_sticky_link($args);
after the initial <form> line.
commenting out the original lines in the bb_topic_admin() as
// ‘delete’ => bb_get_topic_delete_link($args),
// ‘close’ => bb_get_topic_close_link($args),
// ‘sticky’ => bb_get_topic_sticky_link($args),
This is by no means an elegant solution but it appears to work.
I’m sure something more elegant could have been done in css.
‘trunk’ ?
I’m still a newbie – I though the download was the latest release “approved”
I didn’t even know of that bug list
… so good is the documentation … and I’ll bet that most users don’t or can be bothered to dig around in the maze of code to figure out why it doesn’t perform how expected.
This sort of bug fix is easy to apply – affecting only a couple of lines of code there ought to be a forum/list somewhere to enable these sort of changes to be publicised – perhaps there is but I just haven’t connected with it yet.
Still at least I managed to fix this problem one on my own … I get the feeling watching others struggle that this is what comes with bbPress … being on your own
Quote:
It’s a known bug, fixed in [2400] if I remember correctly.
Not in the version I downloaded and installed only a couple of months ago.
Anyway that fix is no good as it will still not work correctly. The id ‘forum_id’ needs to be passed for the dropdownlist to be correctly ‘selected’ and sent 
Is it not also wise to prevent nasty code being sent through the id or is this somehow cleaned elsewhere … in which case why the esc_attr() use on the other inputs above/below?
! BUG ALERT !
It was an error in the core code.
The solution, found after experimenting is as follows:
In line 943 of class.bb_query.php
Replace the occurence of ‘forum-id’
with ‘forum_id’
It is also recommended that the missing line prior to this should read
$q_forum_id = esc_attr($q_forum_id);
in order to prevent attacks using the input value for ‘forum_id’
The form now will function correctly along with any other call to this input field in any plugin.
As always just a simple typo in coding rather than a serious error in code design.
No, I want to move the errant post(s) from the new duplicate topic into the correct already running topic. Then deleter the errant topic (that will now have 0 posts)
I have had a go at doing this manually and everything seemed to work:
Step 1: find the post_id of the errant post and change that record in bb_posts so that it has the correct forum_id, topic_id and post_position (next available in that topic) Also make a note of it’s post_date
Step 2: find the topic record in bb_topics and change the poster_id, username, date and number_of_posts.
Step 3: delete the errant topic_id record
Step 4: Perform basic counter maintenance through Admin/Tools.
Messy and laborious but not beyond automation.
Just waiting for some unforseen effect
I’m still struggling with this one – and it seems everyone is flummoxed as well.
The problem has evolved a bit.
I’m looking to change the default topic list view not only as described above but also to give the user the option by clicking a image button in each header to change the display order. Also taking the view count out and into a column. So a user can view the most viewed as well as most posted as well as the freshest – all sub listed by ascending alphabetical order.
Although i can change the image buttons and the raw sql for ordering the data – I still cannot get my head round how it is currently working (or should that be not working)
@kevinjohngallagher
Hey ho!
Perhaps it is just that the forums I participate in (well most of them) and especially the subject specific ones seem to have very disciplined users.
I have seen and heard of the rabble that frequent some other forums probably with many 1000’s of visits per day.
The specific site I’m developing (redeveloping) currently has 100-200 per day and has been pretty constant for years – it is a fairly close and insular community that is not there to take over the web
It has outgrown the current coding which has proved difficult to maintain, has evolved through several programmers and is unmanageable. Taking PmWiki and bbPress “off the shelf” has enabled the regeneration of the site in the manner intended with, so far, only minor but resolvable hiccups.
Both products meet the needs of being lightweight and easy to use with minimal implementation effort. Even if the documentation of bbPress leaves much to be desired – unless it is hidden away somewhere I’m yet to find.
The problem I have with wordpress is much like the problem I have with Microsoft products- They start out simple and easy to use with minimal functionality then bloat into leviathans that are full of functionality that is neither required or in line with the way users are used to doing things.
As I have not see it listed yet
Bluefish http://bluefish.openoffice.nl/
on both Linux and Win platforms
for just about everything coded.
but sill use Notepad++ for txt files (don’t know why – force of habit I guess
@Lethality
Sorry I’m late to this topic but what you are asking sounds very similar to what I was asking here
https://bbpress.org/forums/topic/feeding-topics-from-external-source
It seems as if I differ with @kevinjohngallagher’s interpretation of what users and communities want from their forum/blog/wiki/crm solution 
However what you seem to be looking for is very similar to what we have decided on PmWiki+bbPress
We voted firmly against wordpress as a product mainly because
1. It has become dreadfully bloated
2. It is difficult to customise (partly as a result of 1)
3. It is a blog (a time driven format) conversation centered around one individual and un-managed comments from visitors. Typically “this is my opinion” followed by “I agree” comments.
I would also steer fairly clear of IP.Board and IP.Blog it is very much under development and considering it is a commercial product is very expensive for what it does.
I feel that someone with a basic knowledge of worpress should be able to add a similar button form to wp code to allow a “Forum This” from wordpress.
@kevinjohngallagher
I’ll ignore all the personal rhetoric and slight aimed in my direction and try to respond to the points raised.
I am new to bbPress (you may have noticed that this is my first topic/post on the forum) so know nothing bbPress, its history, development and evidently tight allegiance to wordpress.
bbPress was selected because “out of the box” it works, and from what I have seen of the plug-ins they also work well.
I think my original topic title has been mis-understood by you, and maybe others as well.
“Feeding topics from external source”
In the external source users will not have the option to set a topic title it will be predetermined by the PmWiki page that is being edited.
In fact it is the reverse of the “Blog this” that has been suggested elsewhere though restricted to the same site’s forum rather than the user’s own personal blog.
Any member has full access to the forums and so is able to start a new topic with a slightly varied topic title. That is not a major issue as the moderators will attend to them. However when posting externally a new topic there is the chance that any editor of the Wiki could initiate the “Forum this” button to start a discussion of that page in the related forum. Therefore without the check the potential of having 100’s of topics created with the same title is great.
In the end it has been very easy to code – It works well and I will even look at the possibility of including it to generate a warning to users in the forum so that we can cut back on duplicate topics in general.
Every forum/blog/wiki open to members has to have a set of accepted policies to govern usability. The site is very specialised with nearly 2000 wiki page-topic combinations. The topics are specifically for a parallel discussion about each wiki page. Elsewhere just about any reasonable discussion is possible.
I understand where you come from in that statement.
However, in some forums (especially one of the forums on the site I am building I do not want users repeating the same topic and would want them to add to the topic that has already been started.
Ideally with a user friendly warning or a redirect to that previously started topic.
Anyway a bit of hard coding and some reuse later I have a working button on the main site
using bb_get_forum() to check that the forum exists before
testing $bbdb->get_var($bbdb->prepare(“SELECT topic_id FROM $bbdb->topics WHERE topic_title = %s”, $topic_title));
seems to resolve this issue.
OK
That mini script appears to work in part.
But. I am astonished that there is no checking in bbPress to see if a topic already exists in a forum before allowing a topic with exactly the same title to be created. Surely this is an important feature and should be handled by bb_new_topic() if only through an optional arg.
Off to generate my own checking routine ?
Thanks, I already have a way round that one.
In the main site the “create topic” is a simple button on a blank form POSTing to bb-post.php with the other fields as ‘hidden’ inputs.
But still not working.
As may have been gathered the operation needs to be silent or with error handling by the main (pmWiki) site
I would have preferred to go down option 1 route:
essentially stripping out most of bb-post into a new ext_post.php
bb_new_topic()
bb_new_post()
bb_add_topic_tags()
redirect – to site page
however this does not appear to be enough!
I would rather not go down the route of having to deconstruct these routines simply to recode them to store the in relevant tables – especially when re-usability should be possible. Besides that requires an understanding of each table in bbPress – something I have not seen documented anywhere.
