World is now on Opti ID! Learn more
AI OnAI Off
World is now on Opti ID! Learn more
To be honest, it looks like a bug or bad design. Optimizely usually only give the means to make your own type classes, not a ready class that cannot be replaced. And the document hints to a class that they don't show. Besides the package hasn't been updated for two years.
Are you sure the your GetFirstMatching are in fact returning your content type instead of the built-in PdfFile?
Hi Stefan,
Yes GetFirstMatching is returning my custom type, but it seem like the CMS file upload pipeline might not be using the ContentMediaResolver to determine the content type when uploading PDFs. Diagnostic logs show that my content type is being resolved with my custom resolver, but it's not hitting this when uploading a PDF.
Has anyone successfully used the PdfPreview add-on while preserving their custom PDF model type? Even though I followed the documentation in ensuring I implement the IPdfFile interface on my custom model as well as creating a Custom PdfContentMediaResolver to override the GetFirstMatching(string extension). The file upload process still uses the PdfFile model from the PdfPreview add-on instead of my custom type. If this is a bug, is there a safe/creative way to tap into the OnSavedContent event to maybe look for those PdfFile instances and create another version using my custom type? I would appreciate any help or guidance if someone has done this successfully.