Need help for bugfix
May 24, 2016
I already reported this bug to the team. But the consequences seem to be more serious than I thought. I despairing of finding a work around.
I insert many webobjects. Now I updates the webobject html file. If I right click "web objects" > "edit" > "check link" it shows me the correct new file. If I click "web objects" > "open" it shows me "C:/Users/MyProfil/AppData/Local/Temp/Articulate/Storyline/6XAiNwhb3kz/zip/66YLocGL1zx/index.html" which is the old file. If I delete this temporary file and republish the whole project it recreates the old file.
If I am reselecting the web objects folder I have the same effect. How can I storyline force to update the webobject index.html file?
Where can I find the storage for the old webobject html file to delete it?
13 Replies
Hi, Alexandra -- Thanks for reaching out! As you mentioned that you have already 'reported this bug to the team', may I ask if that means that you previously submitted a ticket to our Support Engineers? If so, do you have a case number you are able to share? I did a search with your name and was unable to locate a ticket to read up on their notes.
Here is my post, which I also send in as a feature request: https://community.articulate.com/discussions/articulate-storyline/relative-paths-for-web-objects#reply-355464 (Request Number: 00793313; ref:_00D30Txo._50033wuEZx:ref)
Hope this was right or is there a different bugtracker system which I don't know?
Hi Alexandra! Looks like you posted correctly. Thanks!
Any news on this topic? If there is no quick fix, it would be very helpful to know there the temporary storage for the weboject files is locaed.
Thanks!
Hi Alexandra!
If you are updating/editing your web objects as explained here, re-publishing the content, and still having difficulty I would advise that you work directly with our support team here.
After a longer conversation with the support team (many thanks!), here is an update for all who struggle with this issue:
There is no way to update local webobjects. Once there are included, storyline keeps the first version of the weboject.
If you have to update a webobject there are only two workarounds to do so:
1. Delete the webobject in the storyline document each time you update the weboject and insert it again after you saved the project.
2. Rename the webobject folder each time you update them. Then go to the storyline document update the link / relink the renamed webobject folder and saved the project.
Both solutions may involve a lot work. I wrote a little batch file which automatically rename all my almost 100 webobject folder. Anyways, in the second steps I have to go through all slides and relink them manually.
Additional information:
When you use “Web Object” > “Edit” and then “test link”
You will see your updated webobject files, which is recognized by storyline under this link. But storyline still keeps the old version of the webobjects (it was copied to the project file and won’t be updated).
To see the real status of your projects you have to use this way:
“Web Object” > “Open”
This option previews the file that is already inserted as a web object in your project file (and won’t be updated; except solutions above).
I requested a fix / feature request for this topic. So let’s cross the fingers that articulate will get active here.
Thanks for the details and for sharing with the community Alexandra.
Hi Lesli,
could you my have a look what the status of this issue is ( https://community.articulate.com/discussions/articulate-storyline/relative-paths-for-web-objects#reply-355464 (Request Number: 00793313; ref:_00D30Txo._50033wuEZx:ref and Feature Request Number: 00811048; ref:_00D30Txo._50033xBPFT:ref).
This issue bothers me a lot, because each change involves a lot of work. So If I would know that the developer work on a fix for this bug, I would postpone all activities which are related to webobjects. Having more informations would make my planning much easier.
Thank you!
Hi, Alexandra -- Thanks for reaching out to touch base and although we do not have the functionality that you have requested available at this time, the following message was sent recently via email in response to your feature requests:
"Thanks for suggesting a feature! We love to hear what our customers have to say, and we pay close attention to your suggestions. As we plan new features, we take your requests into consideration. To give you some insight into our process, here's how we evaluate each request:
1) First, we see if the request is currently possible, and we let you know if there's a way to achieve your goal.
2) If the request isn't currently supported, we estimate the value it could bring to our products.
3) If a request adds value, we submit it to our product development team for review.
4) Our development team gauges the impact of the request. Will it benefit many of our customers, or does it meet a niche need?
5) If the request is approved, we add it to the development pipeline where it gets designed, developed, and tested.
6) When the feature is ready, we release it and announce its arrival.
We can't promise that a feature request will be fulfilled, but we work hard to address the issues that impact our customers the most. We’ll be in touch if we have questions about your request. And thanks again for helping us improve our products!"
Hi Christie,
thank you for your quick response! I got this email and recognized it. It would be very helpful to get a feedback after the bug is evaluated (step 5).
If development team comes to the decision that they don't fix a bug / implement a feature I will never hear about it. It would make a huge different to know if the development team is working on it or not.
At the moment I have to take a decision just guessing if the development team thinks it is worth to pay attention to it or not. At the moment this means I have to postpone a task and wait, to abdicate a feature I would like to realize or to use a workaround, which often involves a lot of effort.
I love to contribute to storyline whenever I reporting bugs. I would really appreciate to get a feedback in return, which make my developing process a bit more predictable.
Hi Alexandra,
I wanted to clarify that it's not considered a bug or a defect in the software but a feature request as it's not something we support currently per this documentation.
For feature requests or bugs that we report to our QA team, we're unable to share information in regards to a timeline for a fix/new release or information regarding if it'll be included in a future release or update, and that's why you don't hear back after step 5 (or earlier in the process) in regards to the status of feature requests.
As for bugs and features and determining that we'll never include them - that's something our team doesn't do. They may decide it's not in the next update, but if we continue to hear user feedback and requests for something that may change the status or timeline.
Hi Ashley,
I am aware that articulate does not considered this issue as a bug. From my user perspective this issue behaves like a bug. Because I know no program, there I kan select and relink a file and this action has no effect (Why an relinking option if the old file always keeps in place?). Furthermore it looks quite awkward to me, that there is no way to change an included file, except deleting it.
I don't want to bother you, complaining a lot. I am sorry for that! I just wanted to let you know, that I would appreciate an earlier feedback about what articulate means to do next - for both feature request and bugs. This would make my developing process more predictable.
This is why ask to get some information about this issue.
Hi Alexandra,
It's no bother at all - it's what we're here for! I wish I had more information to offer, but we're unable to share timelines or the status of any features or bugs. I know that doesn't assist with your developing process, and our team continually reevaluates this set up as well.
This discussion is closed. You can start a new discussion or contact Articulate Support.