Import /Export not working correct #5211
Comments
|
Please provide exact steps to replicate. |
|
We are just sitting here (already one hour) because the plugin ep_imageconvert crashed the whole site. It was available in admin/plugins to install and boom! Replicating the issue is pretty simple by installing the plugins we have installed. Etherpad version Latest available version: 1.8.14 Git sha: d262e31 Installed plugins |
|
Please provide the commands to replicate. |
|
What commands? You open up admin/plugin in an empty fresh installed etheropad - we installed ours using git clone Only the last plugin - which was ep_imageconvert was crashing the complete installation as it did not even get installed in admin/plugins and hang up there. - we then saw that the code got installed but even after replacing that code we could the site not get working again. After each install of a plugin, we waited before we installed the next one or deinstalled the one that was giving errors because of the relative path missing. yesterday we realized that the admin/plugin seems to have problems when you click more than one plugins to be installed - But today we actually started with a completely fresh install. The goal was to find those plugins which work together. We started etherpad with the normal command run.sh and ran the dependency script before we started to install plugins. We did actually only what also our schools and their staff (students and teachers) would do - click and click! |
|
to install plugins you can do
etc. so go through the process and provide exact commands to replicate the import/export issue :) We have to be able to replicate step by step and commands allows us to do this. |
|
I'm gonna close this as it's likely it's due to plugins and not a core issue. |
|
Closing doesn't solve the problem and looks more like ignoring the fact that things are not working as they should! It can be that problems are from a plugin but then it is a plugin that got installed orderly via the admin plugin and if that admin plugin is installing plugins without checking that they are even working or existing then it is definitely something that needs to get addressed. NONE of the students or teachers will have even access to the coding part! You can do also the following and simply taking the list and copy always an "npm install" in front of the plugin name and a of course a
The point is that this procedure will not be the reality when people are using etherpad. They will do it the recommended way via the admin plugin interface and as long as that clutter of working and non-working and non-relative paths and not existing folders and log files or whats however blocks complete sites and installation it will cause only one thing FRUSTRATION! To get rid of that frustration factor that admin/plugin repository Issue DOES NOT have to be CLOSED but instead kept open so that as many people as possible can see that problem, test it out on their own installations, give feedback, give ideas on how to solve it, etc. Closing all those issues has exactly the opposite effect - A closed issue can NOT BE FOUND as it won't get listed anymore - so it is nothing else than PUR IGNORANCE which rules here and that is pretty unprofessional when it comes to mobilizing people and getting people actively involved. We for us will do now one thing, we will simply redirect all those issues to the students and teachers involved and they can then respond themselves in the languages they know i.e. Thai, Burmese, Swahili and then you can figure out their solutions ideas or bugs. I strongly recommend that you REOPEN all those issues incl the icon stuff and wait for RESULTS instead of closing issues that you don't like to be getting into public! The fact that in the last 3 days a whole lot of issues that have been existing for years even have been fixed shows actually that it is much better to address issues instead of closing and ignoring those Jm2c Always keep in mind that with a little more HELP from your site - instead of closing threads which is completely demotivating for people who found valid issues (I am only the one posting all those as otherwise you would not understand their language!) and besides that each one of those helping here would need an own GitHub account what they don't have. Help from your site could be i.e.
Yes, it might sound like a teacher is but sorry that is what I am and I try to help where I can and motivate others to step in if possible but your method of closing issues is completely contraproductive! It will only cost constant time to reopen them when new ideas for a solution come up and then actually waiting if they again get closed as fast as possible by you! Have anice weekend! |
|
Please see the community guidelines. We don't want anyone toxic spamming github repo issues. If this behaviour continues I will be required to block you. I will give you a few days to cool down and review/edit your comments. |
|
@lisandi Some of the problems you described are very complicated, some have been discussed in the past, some aren't core issues. E.g. if a plugin doesn't correctly export, it's not a core issue. If you have a good idea how we could support admins when they need to decide "Should I install this plugins? What won't work after installing this plugin? What problems with this plugin are currently known?" then don't hesitate. Maybe even a big meta issue like "Better /admin/plugins" etc. is possible, if it's clear which features you want or which problems you'd like to tackle. If you think something is clearly a bug "It's possible to install plugins via /admin/plugins that crash my instance" and people have another opinion (feature not a bug), don't be offended. Maybe there is a solution to the problem that we can work on (like a curated list of plugins, where curated means there are tests, coverage is more than X percent, no core tests fail when the plugin is installed, no other plugins fail when the plugin is installed), but maybe some of the problems won't go away (ie I can write a hostile plugin that fulfills all the above requirements). We won't do a "whitelist", ie review all plugins, but maybe another plugin, "ep_community_reviewed" is possible that collects information and helps admins decide if they should install a plugin. Also if you think we should add other labels like "in-discussion" or "agreed-on-a-solution" that shouldn't be closed by stale bot etc. that reflect the outcome of a discussion, we can talk about it. But no matter how good your ideas are, if you aren't polite and nice nobody will consider them. And if you threat someone ("I'll direct all problems to someone else who then will open up thousands of issues in languages you don't understand...") or talk about "pure ignorance" then please use other software. |
That I have done already many times but now even get warned to get blocked as an answer.
This issue got closed too and not solved. Instead of closing make it a feature request - just to give you an idea! Because as a feature request it will still be visible for others, they get motivated to step in there and to contribute, while closing will frustrate them as they see that they as someone who can't not even speak properly English and need the help of i.e. me to write down their ideas in English. Then it is again only a "western" thing. And that should not be the case at all. How can they follow discord when all is in English and not in Thai or their languages? Then here again they would need me as the middle man and doing that via discord would mean to be constantly online and listening - but I have to do also my regular job and have my family and a whole bunch of children who like to see their father and caretaker not only sitting in front of discord. The main problem is the way the plugin management is done - The way the plugins get allowed to be part of the list inside the admin plugin repository - Simply check out how many "relative path issues" had been addressed in the last days by me (us) and how many actually got followed by a pullrequest done again by us. Check how many times issues came actually up which were caused by that missing (actually wrong) relative path. or lets say two dots in front of that slash. To solve that issue for the admin/plugin repo it is a simple download of ALL plugins into a directory locally, if they only would also all then get downloaded!!!, and then running a search and replace for those missing 2 dots, when done testing if the relative path messages still appear and if they are gone submitting the pull request. Nothing else we actually did the last days and we did that to solve that issue and the motivation to do so - instead of ignoring it - was that they saw that their contribution gets "honored" by being accepted. We work here not with testing scripts instead we simply do real-world testing. Install try and error often even. Admins who maintain the etherpad will have access to the admin/plugin interface and therefore that must be changed to something which is reliable. Guidelines and rules are worthless if simple basic rules are not even met - which means that every plugin needs a description of what it is actually doing. And that description has to be available in the npm repository as that is the one the plugin name is linking to. Just as an example the problem yesterday - so you see what actually happened after one day's of work and contribution!!! We installed via admin/plugin - that is the recommended way to install a plugin and I hope you agree in that - we installed one by one a whole lot of plugins which all worked nicely together - in between we submitted the pull request for issues we fixed - quite a whole lot - most of them has been merged pretty fast which was good as were able to update the plugins which had been merged via the admin/plugin interface - which is also the recommended way to do so - and we continued to install the next plugin. 38 times actually - a whole lot plugins but OK they worked together and also here on github there was a work together which helped the community and us too as the fast acceptance of pull-requests definitely motivated all here to do much more. Internal communication is in very broken English and Thai, sometimes Swahili or Burmese, Some of those I need also a translator but as we have people here you know some of those languages no problem, even they, unfortunately, can't code but they help in translation. With the admins who actually, later on, would maintain all the etherpads in their schools there might be nobody who can translate! But of course, they could try to get an answer like me on Github and report issues, they won't understand all the talking on discord either as English proficiency is pretty low here, especially in rural areas! And the idea is not to integrate those etherpads for international schools with a huge budget but instead using it as a tool for pretty poor schools here and in Africa "Montessori for All" so they can better cope with Pandemic and past pandemic situations. If we take ourselves out of that whole (or get blocked) then they have only one chance to get answers and that is to write themselves - what most probably won't do because some of them had already the experience that they get ignored when not writing in proper English, what they can't. On the other hand, they saw that their help and contribution get honored by being accepted in the past few days. But having issues that are actually not solved closed is not the right way as it demotivates those who like actually to dig into it. From the motivational point - the one I am having here - it is completely contra-productive. I have no idea what or who adds labels but it sounds as a good idea. The same applies to the idea of a community review plugin but when the information collected with it won't be available and visible directly in the admin/plugin list again it would not help much. We already realized that we perhaps should set up a complete separate repository with only those plugins which are working and then link the admin/plugin interface to it, or another idea which came up was to simply rename all those where we contributed or which work or which should get combined and posting those on npm and then get perhaps listed in this plugin list too - but honestly I did not like that idea as it would only clutter that list even more. Check out how many plugins are in that list - tables = 4 or more - all doing the same - some abandonned, some not working - but which one is working??? - adminpad and adminpad2, headings and headings2 and with some you have pluginname and pluginname2 but actualy pluginname is the one which gets better maintained. All of that is a clear chaos! and makes it real difficult for an admin to find the right one which does not cause a crashing etherpad. Yesterday we had chosen: ep_imageconvert - it was listed, we checked even the developer and saw that it is probably a good one as we had already many of him installed and they were working. but boom - all was gone. We then tried to find the repo as we wanted to compare if their is a newer version but the link to the repo was 404. That actually then started to check some other plugins whe hadn't installed until now - and we listed those already as some even had not even one line code in their repositories - so why do those still get listed in admin/plugin . The admin does NOT know that perhaps some code or parts of it or some dependencies or whats however got installed as he can't see what is going on during the installation process in the admin/plugin panel. He only gets presented with the result of an installation process. In the case of ep_imageconvert that was a hanging installation process that did not end. So when something hangs up the admin does a reload - and Boom he was out of service and could not even access the etherpad anymore or the plugin/admin interface - well he had it open in a second window too but as there is no way to delete or cancel an installation process which would help to reverse all steps of the already done installation process, it did not help much. That was then the case where my help was needed again, but even the restart and manual deinstall did not help much, and as it was simply a way too late already we postponed that stuff till later.
This is meanwhile the only way we see as a proper solution as the etherpad we need has to be maintainable by ADMINS and not by PROGRAMMERS of SYSADMINS with root access. And those problems with hanging and not working or conflicting plugins have to be avoided! By the way, thanks for your very very useful contribution in the other thread about the admin interface - Your answer solves a whole lot as we now know where to look at it! And those answers are needed much more to solve the problems etherpad has in usability for admins - and users (the icons issue) which should be a feature request but not closed! as there is a way to make it accessible - we posted it already in the "icon" threads. |
The export to other formats than Etherpad and MD (separate plugin) functionality does not export the formatting of a text and also ads the user in a color actually not even assigned to the user - if it should get added at all - Instead it would be tetter to add only the contributors on top or underlining.
All plugins like color, fontsize, headers, etc work correctly and format correctly. But the standard core import/export functionailty does not recognize those formats as it looks like when it come to export to other formats than Etherpad and Markup/
i.e.
New.pdf
That is the page that got exported! The same problem with ODT
Other export formats look as follow - on the same page:
Github doesn't like all formats so .txt got added and needs to get removed first.
Importing the doc, odt, md document which had been exported results first in a red error message while still loading the document
The loaded Document has no formatting
The import of the exported etherpad format works fine, when no author had been exported it will set the author to null
Making adding an author name when entering the pad would be advised to avoid that problem.
When importing the Etherpad format the file menu bar gets no more displayed at the end of the import and it will come back after reloading the page. - Perhaps it would be helpful to reload the page after an import by default to avoid a missing file-menu-bar.
The file menu is actually still there after an import but has no content anymore - you can check when you move the mouse to the top until the dropdowns of the menu show up
(
empty)
Importing the odt format results in an open office style looking button bar :-) but the text format gets lost.
... and the odt button bar gets lost after a page reload
The MD import looks fine but during the export the line spacing and the alignment got lost and paragraphs got added a * at the beginning and all that won't get replaced when imported, while headings (beside H5 and H6 which no exist until now) and all list formats get imported OK (dl) not sure!
I would therefore add MD format to the default export formats in the filemenu menu - it would avoid having that plugin to be installed first. MD is actually the only format which comes pretty near to the etherpad format - all other failed!
The text was updated successfully, but these errors were encountered: