-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wiki articles with images do not always load... #216
Comments
I assume you are talking about the Image plugin and not the Assets plugin. I'll also assume that you are talking about your site, clive.tries... By hosting a site in Singapore I see higher latency but not lower throughput. This matters for fast small changes, not large pages. Here is a list of your pages over a megabyte in length.
I think if you avoid these pages you will have more success. Let me know if you do then we can talk about how to shrink these pages and avoid them in the future. |
Note that as pages are incrementally enlarged they will eventually exceed 5mb which is the payload size limit for operations like "fork". We should probably refuses any edit that grows a page beyond the size that can be forked. |
misplaced comment |
Looks like last comment intended for integration of draw.io with fed wiki discussion fedwiki/wiki#108 |
Look forward to discussing how to shrink pages. To foster wiki forking I could imagine pixel sized traffic light for didactic UX. Green (go) < 1MB. Amber > 1 MB (caution). Red >5MB (stop). Alas in NYC till March. |
It might be worth investigating if the router is stripping out the base64 encoded image. |
Paul might be on to something though I can't imagine where in the stack that might be happening. The Network tab of the Chrome Inspector would be a good place to start an investigation. If screen sharing is working for you then maybe we can video chat and debug this together. If you have one particular page you need, I can hop on the server and start hacking at that page with a text editor. We have had many discussions of longer-term fixes but no single fix solves all problems. I consider large images to be the easiest of the "demanding media" and have imagined having all media work well. http://ward.asia.wiki.org/demanding-media.html I steer clear of page size problems by habits that have accumulated over the years. I hesitate to suggest these to others because they make wiki seem fragile in a way I wish it weren't. I wrote a page about my workflow this morning. http://ward.asia.wiki.org/how-i-post-images.html I am sorry you are having these difficulties. I hope NYC is treating you well otherwise. |
The whole base64 encoded image thing has turned out to cause a lot of
problems for users. It is probably the number 1 reason for lost data in
wiki (which is otherwise rare), and of un-for kahle and bloated pages.
The description of how to add an image + use a scratch page is one of the
more complex things to explain, and yet has little point. Neighbours and
foreign servers need understanding, adding an image to a page should be
transparent.
It would be better (moving forwards) to take this functionality out of the
default factory behaviour and replace it with the new asset folder upload
and embed behaviour.
…On Sun, 25 Feb 2018 at 15:38, Ward Cunningham ***@***.***> wrote:
Paul might be on to something though I can't imagine where in the stack
that might be happening. The Network tab of the Chrome Inspector would be a
good place to start an investigation. If screen sharing is working for you
then maybe we can video chat and debug this together.
If you have one particular page you need, I can hop on the server and
start hacking at that page with a text editor.
We have had many discussions of longer-term fixes but no single fix solves
all problems. I consider large images to be the easiest of the "demanding
media" and have imagined having all media work well.
http://ward.asia.wiki.org/demanding-media.html
I steer clear of page size problems by habits that have accumulated over
the years. I hesitate to suggest these to others because they make wiki
seem fragile in a way I wish it weren't. I wrote a page about my workflow
this morning.
http://ward.asia.wiki.org/how-i-post-images.html
I am sorry you are having these difficulties. I hope NYC is treating you
well otherwise.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#216 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAE71iCPyHJHm_8OZXXAtejQ0wBxWHffks5tYX6DgaJpZM4SR_Mc>
.
|
Server operators are free to provide whatever services they feel useful to their communities. |
In NYC area on certain home routers wiki articles with picture assets do not load (no matter how long one waits). In NYCPL (https://www.nypl.org) the same articles load after an observable time delay. As I understand it, tries fed wiki instances are hosted at Digital Ocean in Singapore to tease out odd latency issues. Is there any debugging I can do in Chrome dev tools to track down the root cause?
The text was updated successfully, but these errors were encountered: