SMF2 attachments - only inline img tag attachments migrated
Hi there,
I've followed the Vanilla Porter 2.5 instructions carefully, checked that the SMF2 section of the porter script supports attachments, etc, but I still can't get it to properly export all attachments.
While it will export anything that's part of a discussion, such as a BBCode img tag with a URL in it, it will not export attachments that are, well, attachments.
This works:
This does not:
And you can see both here in the file created by Porter:
With inline images:
"6430","26","58318","0","17","built myself a coffee cart !","well I'm not sure if it comes under the topic of rebuilds\, but it's definitely a project! I built a coffee cart specifically to fit my La Rocca Verona Expres coffee machine which I purchased second hand recently<br /><br />say what you like about the build quality of Spanish coffee machines - it's very simple under the hood - but it makes great coffee and the 5lt water tank combined with a 2lt boiler mlmeans that I can make a lot of coffees between refills !<br /><br />in fact I've had 4 gigs since building the cart a month ago\, and I made 70 coffees on it yesterday\, and it didn't miss a beat !","2018-10-14 16:47:51","1970-01-01 10:00:00","304","2018-10-18 10:08:51","304","304","BBCode"
Without:
"6432","36","58346","0","11","Roasting to a) relative points or b) absolute points","Heya guys! Just had a curiosity...<br /><br />I'm relatively new to monitoring temps while roasting (for many years just roasting on the 'fly'\, time-based)\, but was wondering something.<br /><br />In terms of consistent roast depths\, is it better to roast to:<br /><br />a) a relative temperature point based on when first crack occurs/ends<br /><br />Or<br /><br />b) absolute temperature point (just ending when the beans hit a certain temperature)<br /><br />Am not sure if what I'm saying makes sense\, but I recently did a few roasts\, the first two roasts FC happened pretty much the same temps. The third roast it was slightly different measurements..<br /><br />Eg If in roast:<br /><br />1) FC happened at 205\, rolling was 212\, end of FC was 220\, and I pulled the roast at 224<br /><br />2) FC happened at 211\, rolling was 215\, end of FC was 223<br /><br />As the numbers are slightly higher\, in order to get a consistent roast depth\, would it be better to end that second roast at the exact same temp (224)\, OR end it relative to the end of FC in that first roast (about 4 degrees past the end of FC) which would be 227 degrees?<br /><br />I hope this made sense haha.. thanks guys :)<br /><br /><br />(And obviously the profile ie how it got there matters\, but I mean if I keep the same profile. These two profiles are attached too just for more info. The probe position was the same in both\, and ambient temps were the same)[img width=800 height=436]https://uploads.tapatalk-cdn.com/20181021/13177270102a945b3d2cf685f0600784.jpg[/img][img width=800 height=436]https://uploads.tapatalk-cdn.com/20181021/a64b8feb9283e598274386dcefe7fdea.jpg[/img]","2018-10-21 15:37:45","1970-01-01 10:00:00","6837","2018-10-31 10:49:10","6837","6837","BBCode"
I feel like I've missed something crucial!
Any help would be appreciated.
Comments
Which editor is enabled on your forum?
You need to enable an editor that supports attachments (like the rich or advanced editor) for them to display.
My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
I can see I screwed up in my initial post.
The second block of code is with inline images, the first is without.
You can see in that first block of code that there's no reference to the images attached to the post at all.
Also, I'm not sure how SMF2 stores attachments, but the directory is full of what looks like hashed filenames, and the link to download files is dynamic, not referencing either the filename or the hashed file... So not sure how to resolve this part of it either, and get the actual files moved over.
It most likely stores the names in the database.
Anyway, Vanilla Porter should take care of that, attachments are a supported feature for SMF2 to Vanilla conversions.
Did you try enabling either one of the editor plugins in the dashboard?
My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
Thanks for the continued assistance.
Yes, I've tried with both the Rich Editor v1.0.1 and Advanced Editor v1.8.1 and neither show the attachments - or even broken images for attachments.
It's worth noting that anything inserted using the inline image button [\img\] (I've escaped it here to avoid it actually working) is totally fine, and all of those images are hosted externally.
It's only files loaded via the native attachments button that aren't coming through. I checked the GDN__attachment table, and there's no data.
GDN_Attachment is actually not for uploaded attachments, but used for other external resources.
All regular media attachments should be in the GDN_Media table. Could you check, if the missing attachments are there and if they have a value for ForeignID and ForeignTable?
My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
I've confirmed the following things:
1) The GDN_media table has thousands of records and that they all have ForeignID and ForeignTable records
2) I used the ForeignID value to confirm which comment that attachment was related to
3) Checked that the correct image file is available in /attachments
4) Checked that the comment isn't displaying the image
So we seem to have all the pieces in place for this to work: there's an actual image, it's in the database, and it's linked to a comment - it's just not showing up.
I hope that helps narrow it down a bit!
That's weird, because it should work. The ForeignTable is set to either "comment" or "discussion" aswell?
My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
Yep! They all say "comment" or "discussion".
I realise my last comment probably sounded like the problem was solved.
Unfortunately not :)
Just confirming that each ForeignTable field is set to either comment or discussion, and still can't see the attachments.
Sorry, forgot about this!
Could you post an example row of your GDN_Media?
Also try enabling the rich or advanced editor and upload a new file. Comparing the newly inserted row to one from your import may help narrow down the problem.
My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
I had this problem too after using the Porter to move a version 2.4 forum to 3.3 running on a different VPS (a sad story in itself). None of the attachments in the GDN_Media table marked with valid ForeignID/ForeignTable columns pointing to old-style discussions and comments (with Format = Html) were shown.
The new formatting mechanisms (e.g. RichFormat) treat attachments differently. In the case of RichFormat by storing the attachment link in the body of the comment wrapped in some JSON. Although interestingly, an entry is still made in the GDN_Media table (with ForeignTable set to "embed").
I hacked a very ugly solution by making HtmlFormat call a routine still present in BBCode that queries the GDN_Media table and returns all attachment links for a given discussion. Then inserting those links into the formatted comment text. I had to resort to using global variables to pass the current DiscussionID/CommentID to the right places because the newer API doesn't allow for this as far as I could tell. A truly awful solution.
I can't understand why the developers allow such an obviously common use case to go unsupported. There are vague references in the Porter documents and code to attachments being do-it-yourself. They weren't kidding..