Version: 0.2.9
Last Updated: 2011-11-28
Requires bbPress Version: 0.9 or higher
Compatible up to: 0.9
I was wondering if it might not be a typo in the html causing the shift. It reminds me of times when I've forgotten to close a div tag while designing layouts.
Thanks for the update on the other issue. I'll download and try it as soon as I get a few free minutes.
Cheers.
For those getting "silent fails" where there are no errors reported but the image never shows up in the directory so it only displays the dreaded red X, I've discovered that my code is not detecting when open_basedir is preventing the file copy.
So if the above is happening to you, put a phpinfo file temporarily in the bbpress folder and look for open_basedir and make sure it's not starting at your webroot instead of your account's home directory. If you don't run your own server you will probably not be able to change this but if you can, you can try using php_admin_value in php.ini or SetEnv PHPRC in httpd.conf or .htaccess
I'm using bb-attachments 0.2.0, and everything seems to work as expected in the forums - very useful.
The only kink I found was in the attachment links in the RSS. The link to the attachments aren't absolute, so they're not much good from the feed reader. It also appears the HTML needs to be HTML-encoded to be consistent with the rest of the feed and to keep the RSS readers happy.
...or maybe I'm just missing something
Ah you are correct, I completely forgot to test RSS and there are several bugs with that.
Should now be fixed in 0.2.2, let me know.
Yup, that seems to have done the trick.
Great plugin, will have it live soon.
Quibbles/bugs/suggestions:
1. The file icon is linked to the actual icon gif - should ideally be a css background, or at least an unlinked image.
2. Image files do not open in the browser, but rather are downloaded? Ideally using Highslide would be preferable, but would it not at least be possible to have the image open in a new window? Having it behave more like a normal image (so you could right click save as) would be more intuitive for users.
3. Perhaps something for the future: maybe we could have the autoinserts generated with some alt/title text - perhaps just grabbed from the thread title or similar, or user entered (probably not).
4. I'm afraid I haven't tested this, but is it safe to use multibyte characters (I'm especially concerned with East Asian character support personally) in filenames and so forth? Will it fail gracefully if not?
Just tested - you need to put in some kind of sanitiser, or better yet multibyte character support, to handle/stop filenames with special characters otherwise the file attachment fails rather ungracefully.
Pertinax786, are you on Linux or Windows server? If the aerver's OS doesn't handle unicode as filenames, it won't work obviously and will have to be sanitized.
But I already do some very limited sanitizing, it should not interfere with the name encoding, as long as the server supports it.
My biggest problem in testing is that my local filenames don't support unicode so impossible to upload that way.
Pertinax786, I've adjusted 0.2.3 to use UTF-8 in the database table.
It will automatically convert the existing table from latin to UTF-8 but you must deactivate and then re-activate the plugin for that to take effect.
See if that clears up the visible portion of the filenames.
It will not fix the OS portion however if your server does not allow non-latin characters as filenames and I will have to investigate alternative workarounds (if even possible).
Thanks, I will test it.
My server (dedicated CentOS running LiteSpeed) is ok with MB (Japanese in my case) filenames, though I don't usually use any as people have trouble downloading/viewing them if their character encoding is off. I'm just concerned people would upload such filenames without realising it may cause problems.
One solution I have seen is just to cheat and convert the filename to something like "multibyte-filename-001.jpg", but that's not exactly elegant. Another option might be to just force standard characters at upload, and refuse MB character filenames.
Tested - it works perfectly now with filenames in bbPress, thank you. Probably leaving it like this is better than worrying about browsers with broken encoding.
The remaining issue is either server or PHP, I don't know which - the files saved to the attachments dir have mangled filenames, it looks like they are still being saved with a different encoding, but that the names in the DB are being used so they still work and display ok:
Original filename (correct):
妄想.jpg
Saved filename:
螯・Φ.jpg
In bbPress it still displays and downloads as 妄想.jpg
The "corrupted" file names on the disk are probably due to the limitation of your OS.
There are patches that can be done to linux that will give it full UTF-8 filename support but it's not necessary as bb-attachments has a file numbering prefix protection so not even two of the same exact filenames can overwrite each other. It doesn't matter what it's called on disk, as long as the OS can still write and read it (if you are on cpanel it's not possible anyway).
The corruption also might be from a str_replace I do which is the only filtering I try to remove repeating punctuation and spaces. It's possible it's not behaving well with UTF-8 but I am uncertain. I'd have to write a debug version that logs what filename it's actually trying to write vs. what's ending up on the disk. My money is on centos (linux) changing it since the same exact filtered filename is stored in the db table.
I did some testing and discussed it with the host, and it looks as if the OS is handling utf-8 flawlessly. I've had similar problems with non-unicode PHP myself - fixing it is usually as simple as replacing the string handling functions with their multibyte versions, though I'm not sure about str_replace. It seems to me the string is either being mishandled in the PHP, or else it is being passed to the OS with the wrong encoding specified.
As you say, it seems safe to ignore, but is not perfect...
I'll have to double-check the script but I only manipulate the filename with str_replace which is supposedly multibyte safe. I can also try mb_ereg_replace.
UPDATE: aha, I bet it's the stripslashes that I do for safety.
Multibytes use slashed prefixes if I recall properly so stripping them would be very bad.
Could you try testing this for me - go to line 314 and change it from
$filename=trim(str_replace($strip,'_',stripslashes($value)));
to
$filename=trim(str_replace($strip,'_',$value));
and see if the filenames become correct?
Still comes out garbled with that line changed.
Only thing I can think of is that the move_uploaded_file is tampering with the name and is not properly multibyte aware or has a bug. What version of PHP do you use?
It makes no sense that the same filename which is sent to mysql is stored properly but a supposedly UTF-8 aware OS is not storing the same exactly filename properly.
I take it you've tried uploading the same filename via FTP to your server to see if it holds the correct name without corrupting?
I've been double checking everything using several different terminals - looks like it's not a problem with the PHP, the code, or with the OS, but with how the encoding is displayed by these various terminals (buggy unicode support in other words) - some fiddling with the encoding in a different shell gets it displaying ok, and it looks to be stored on the server OK now - it may be that the second mod you made was not required.
I think everything is cleared up now - have to force absolutely everything to unicode in cases like this I see.
Thank you for the help, I should have it live very shortly as a result!
Could you tell me which part I need to modify to enable the uploader for anonymous users? I enabled it in the options but it looks as if a check is still hiding the file selector?
I assume it's just this part:
if (!$post_id) {$post_id=intval($_GET['bb_attachments']);} // only can upload if user is allowed to edit post
$user_id=bb_get_current_user_info( 'id' );
if (!$user_id || ($post_id && !bb_current_user_can('edit_post',$post_id)) || !bb_current_user_can($bb_attachments['role']['upload'])) {return;}Not sure if this is WASD:
Blockquoted full width images are pushed out of the text area by the indent - they will overlap the sidebar if present, or just look silly - any fix for this?
bb-attachments was not designed to allow anonymous uploads and I don't intend to modify it to allow that. You can try breaking it like this but you are on your own:
$user_id=intval(bb_get_current_user_info( 'id' ));
// if (!$user_id || ($post_id && !bb_current_user_can('edit_post',$post_id)) || !bb_current_user_can($bb_attachments['role']['upload'])) {return;}There are bound to be other security checks in the program you will need to disable. I highly recommend you install "instant password" instead and let people register quickly rather than "hit and run" on your forums and create a mess that you can't easily clean up.
You must log in to post.