|↑back Search ←Prev date Next date→ Show only urls||(Click on time to select a line by its url)|
|***||ChanServ sets mode: +o MichaelDaum||[06:13]|
|................. (idle for 1h22mn)|
|GithubBot||[VotePlugin] MichaelDaum created Item14425 (+3 new commits): https://git.io/vQZsD
VotePlugin/Item14425 cc69b56 MichaelDaum: Item14425: first restructuring
VotePlugin/Item14425 b4e8719 MichaelDaum: Item14425: trying to merge branch
VotePlugin/Item14425 f2d3eb8 MichaelDaum: Item14425: manually merge Item12672
|***||GithubBot has left||[07:35]|
|FoswikiBot||https://foswiki.org/Tasks/Item14425 [ Item14425: rewrite and modernize VotePlugin ]||[07:35]|
|...... (idle for 29mn)|
|GithubBot||[CodeMirrorContrib] MichaelDaum pushed 1 new commit to master: https://git.io/vQZZa
CodeMirrorContrib/master f451ceb MichaelDaum: Item14330: patching matchbrackets...
|***||GithubBot has left||[08:04]|
|FoswikiBot||https://foswiki.org/Tasks/Item14330 [ Item14330: Create CodeMirrorContrib. ]||[08:04]|
|........................................................ (idle for 4h36mn)|
|***||ChanServ sets mode: +o Lynnwood||[12:40]|
|ChanServ sets mode: +o gac410||[12:45]|
|..................................... (idle for 3h2mn)|
I have a strange question...
|CSUNetworking||I am currently a student tech at Colorado State University, and we use FOSWiki for documentation and the like. However, it is quite difficult to use and others who worked here have been using it since the TWiki days and chalked it up to issues migrating from there.
However, I noticed today we are running version 1.1.9.... from 2013
How difficult would it be to update our servers from 1.1.9 to 2.1.4 for example?
|Would there be a better place to get support for that?||[15:57]|
|...... (idle for 27mn)|
|Lynnwood||CSUNetworking - hey there. Updating from 1.1.9 to 2.14 is not so bad.||[16:24]|
|Lynnwood||The trickiest part is character conversion to make sure your content is clean utf8.||[16:25]|
|CSUNetworking||From what I've heard from senior staff who were here when we migrated from TWiki is that there were some snags with that migration. Would legacy stuff from that era be of any issue either?||[16:25]|
|Lynnwood||I doubt it. Any of that was probably cleared up in earlier migration.||[16:26]|
|Lynnwood||The latest Foswiki still has a TWiki compatibility plugin that deals transparently with and TWiki stuff remaining (common macros, web references, style references, etc)||[16:27]|
|CSUNetworking||Should I just send the link for the UpgradeGuide to the team responsible for our servers and what's in there should cover it? Or would there be some more steps as it was ~4 years ago we last updated our site.||[16:28]|
|Lynnwood||The way I'd recommend doing the update would be to do it as a parallel installation, if possible.||[16:28]|
|CSUNetworking||And that's good to hear. I'll relay that to quiet some fears.||[16:28]|
|Lynnwood||I believe the upgrade guide covers this.||[16:28]|
|CSUNetworking||So there are no major wrenches that could be thrown in our gears, especially with the parallel installation?||[16:29]|
|Lynnwood||One other tip I might make: there is an option in doing the upgrade to switch how topic and attachment histories are stored.||[16:29]|
|CSUNetworking||And what does that cover?||[16:29]|
|Lynnwood||Previously, Foswiki (as well as TWiki) used rsv versioning to manage topic histories. By default, the latest versions of Foswiki are using a new "plain file" store.
There is a script included in the distribution to convert all the old content and histories to the new format. However, you don't really need to do that and it adds an extra level of complexity to the upgrade process.
Plus, I'm not completely convinced the switch-over offers compelling benefits.
|CSUNetworking||We've been having frustrations using the tables recently and were mainly trying to see if a fresh start would help, or if the tables are easier to use in the newer version.||[16:33]|
|Lynnwood||So, if you stay with rsv as the store mechanism, it simplifies the upgrade.
What aspect of the tables provide most of the frustration? Also, do your users mostly use WYSIWYG editor?
(do you understand the question?)
We use the default editor currently.
|Lynnwood||I'm not 100% sure what the default editor is... whether it's WYSIWYG or not.||[16:37]|
|CSUNetworking||There have been a myriad of issues that are currently frustrating our users.||[16:37]|
|Lynnwood||Does your editor have a toolbar for doing formatting?||[16:38]|
|CSUNetworking||Yes it does||[16:39]|
|Lynnwood||Ok, so i think you are using WYSIWYG editor. I believe the WYSIWYG editor did undergo an update with version 2.0+ so you will probably see some improvement there.
Can you mention some of the common frunstrations? And were those mostly with editor or other aspects?
|CSUNetworking||Mostly with the editor; we get confused with the borders showing up sometimes and not showing up other times.
We also use Excel to do most of our table work and then we will copy-paste those tables into our wiki manually. FOSWiki doesn't seem to like that very much either.
|Lynnwood||ok. I can't speak to that specifically... Personally, i mostly don't use the WYSIWYG editor. I prefer the NatEditor.||[16:42]|
|CSUNetworking||Is that a plugin?||[16:42]|
|Lynnwood||ah yes. I don't know how well Foswiki does with that. I could give it test. Excel (and MS apps in general) tend to include a much of their own funky html that does not translate easily.||[16:43]|
|CSUNetworking||Yeah we figured the wiki would cut out most of the metadata pasted in||[16:43]|
|Lynnwood||y, that's very hard to preserve because it assumes it's within larger MS context.
I personally tend to "clean up" content from excel in a text editor before putting into Foswiki.
... but i admit that's more trouble.
To answer earlier question, NatEdit is a plugin... I _think_ it's now part of the default installation.
|CSUNetworking||Yeah. We're just not sure where to go from here to streamline our workflow
Does NatEdit make it easier to work with the tables?
|Lynnwood||Probably not in the case you describe...
But i don't know your complete workflow. You do a lot of what you describe: working Excel and then copy-and-paste into Foswiki? Is that the workflow you mean?
It would seem that you could simplify this workflow by working within Foswiki. There's ways for Foswiki to create a table from a template if you have a general spreadsheet format you use.
|CSUNetworking||Mainly yes, we're all quite comfortable and "adept" with Excel; and we will use that when we make configuration files for our switches within our operations center. But we provide the wiki for our helpdesk to use, and we always seem to have trouble translating our spreadsheets to the wiki.
That's our main holdup, summarized.
|CSUNetworking||And yeah I suppose we should just try to become more familiar with the tables in Foswiki, that way we're not updating multiple locations anytime we make a single change||[16:52]|
|Lynnwood||For sure... I have a client that uses for Foswiki to store their configuration info. But they use a Foswiki data form which makes it much easier to search information.
Plus, it allows for form-based creation and editing of the info.
|CSUNetworking||When working in the editor, we can use the plain-text table editing tools, which are nice but when we go back to edit it, it has the WYSIWYG table and we were wondering if there's a way to keep those tables as the plain-text format when editing
Is that what you were talking about with the NatEditor?
|Lynnwood||y, in fact it is.
I don't like what the WYSIWYG editor does to a number of things (including tables).
|CSUNetworking||Also random spaces inserted in the cells makes it very frustrating, this is a bug in our older version, correct?||[16:57]|
|Lynnwood||It may be. that's the kind of thing that was an issue.||[16:57]|
|CSUNetworking||We can definitely work with the plain-text tables easier, if we can figure out getting our version updated, and getting the NatEditor plugin, we should be closer to being more comfortable using the wiki.||[17:00]|
|Lynnwood||If you're doing the upgrade, you _might_ also consider taking a look at NatSkin. In my opinion, it add quite a bit of usability enhancement over the base installation.||[17:02]|
|CSUNetworking||Looks like those plugins go hand in hand||[17:04]|
|CSUNetworking||They interact easier||[17:04]|
|Lynnwood||Nat Skin makes a lot of things just easier and slicker. Thanks like setting topic permissions, handling attachments, etc.
NatEditor was part of NatSkin but the author spun it off as separate plugin at some point.
Michael Daun - the developer of NatSkin - has also created quite a number of additional plugins that add a lot of functionality to Foswiki - and these are also integrated into NatSkin if you use them.
|CSUNetworking||Yeah I've been looking at the plugin list||[17:08]|
|Lynnwood||Things like ClassificationPlugin which provides for managing content categories, tagging, etc.||[17:08]|
|CSUNetworking||It's a lot to sift through, haha||[17:08]|
|Lynnwood||yea, a bit....||[17:09]|
|CSUNetworking||Well I think we've got some things to work on. Thank you very much for your assistance, Lynnwood||[17:15]|
|Lynnwood||Good luck there!||[17:16]|
|......... (idle for 40mn)|
|gac410||Hi CSUNetworking ... just a few additions to what Lynnwood said.
The UpgradeGuide mainly recommends use of bulk_copy to to the conversion / upgrade to utf-8, however in my experience, the CharsetConverterContrib is quite a bit easier to use and is a lot faster too.
bulk_copy has to copy/convert each RCS revision in history - this can end up very slow if you have lots of history. CharsetConverterContrib converst the files directly, not the extracted content.
also historically people broke lots of rules in twiki/foswiki - sticking files in pub that were not legitimate / API visible attachments. Bulk_copy uses the API and will skip stuff it doesn't see. CharsetConverter updates the directories in place.
Also, when you upgrade, it's strongly recommended that the new server be running the latest perl you can get. 5.20+ ... the newer the better. With unicode, the regular expression code in older perl versions can be verrrry slow.
But note that Foswiki 1.1.x will not run on newest perl / cpan without some surgery. new perl deprecated a lot of code that we've had to fix in Foswiki 2.x
So new server/latest perl/cpan Install foswiki 2.x configure it, install extensions, then copy over the data and run the charset converter.
+1 on Lynnwood's NatSkin recommendation. ... but ... it is big. Has a lot of "optional" extensions, and in most cases, optional can be read as "optional, just like the tires on your car / engine, seats, windows, etc." :D So best to install the vast majority of the dependencies.
So converting / migrating + new skin might be a bit overwhelming ... best to take smaller steps.
|....................................... (idle for 3h10mn)|
|GuilainC||hi all, hope to everything goes well||[21:16]|
|gac410||hi GuilainC ... Things good here ;)||[21:16]|
|GuilainC||before I reinvent the wheel, do you know if someone use foswiki as a xml attribute dictionnary (in a contexte of software developpment)||[21:17]|
|gac410||I don't know, but that's not saying much. Best is to ask widely / frequently.||[21:18]|
|GuilainC||ok, thanks gac410||[21:19]|
btw did you figure out a good way to organize a docker container for foswiki?
|GuilainC||about docker I've made some improvement and decided to make an mix between docker for the "main" foswiki application side
and for the file data & conf, to go toward a git repository
|GuilainC||but is not enough advance and tested in order to "shout the victory"
but I have to say is much more an Proof of concept rather than a production release
but if it's work it will be good too :)
oh, for the story, my last company
|gac410||well if you work things out, please consider adding your experiences to Foswiki:Development/AddDockerContainerForDistributionMethod||[21:27]|
|FoswikiBot||https://foswiki.org/Development/AddDockerContainerForDistributionMethod [ AddDockerContainerForDistributionMethod ]||[21:27]|
|GuilainC||had request to me to restart the old wiki i've used during 4 years old, on my automotive hybrid powertrain project
for sure gac410
|GuilainC||be sure, that if that's works i will share||[21:28]|
|gac410||well even failures are learning experiences, so what doesn't work can be valuable too :D||[21:28]|
|GuilainC||GuilainC discover that the verbs stay is a regular verbs [off]
yes your right, noted
time to sleep see you, I should be more present during the summer (15th july up to mid august) => a new foswiki installation in my company is expected
|gac410||g'night sleep well.
July 22nd is Oshkosh. I'm going again, weather permitting.
|↑back Search ←Prev date Next date→ Show only urls||(Click on time to select a line by its url)|