IRC Archive for channel #xwiki on 30 August 2016

Last modified by Vincent Massol on 2016/08/30 21:28

<ansuz> has quit
01:30 <martinus__> has quit
01:33 <martinus__> has joined #xwiki
01:49 <martinus__> has quit
01:51 <mflorea> has quit
01:55 <martinus__> has joined #xwiki
07:17 <msmeria> has joined #xwiki
08:28 <vmassol> has joined #xwiki
08:37 <sdumitriu1> has quit
08:44 <acotiuga> has joined #xwiki
08:51 <tmortagne> has joined #xwiki
08:58 <tmortagne> has quit
08:59 <tmortagne> has joined #xwiki
09:13 <sdumitriu1> has joined #xwiki
09:30 <mflorea> has joined #xwiki
09:35 <gdelhumeau> has joined #xwiki
09:45 <ansuz> has joined #xwiki
10:19 <Enygma`> has joined #xwiki
10:20 <evalica> has joined #xwiki
10:30 <xwikibot> has joined #xwiki
10:38 <vmassol> tmortagne: thanks for your comment on the diff between Text and PureText
10:38 <vmassol> so I guess this means I need to change the type for the WikiMacroClass "code" property which I had set to puretext
10:38 <tmortagne> has left #xwiki
10:38 <vmassol> it should be "text" instead
10:38 <vmassol> right?
10:38 <vmassol> oops he's left :)
10:39 <tmortagne> has joined #xwiki
10:39 <vmassol> (since it contains wiki markup)
10:42 <vmassol> fixing
11:10 <Trefex> if i should upgrade, what's the upgrade path?
11:10 <Trefex> thanks :D
11:10 <vmassol> Trefex: upgrading is always good :)
11:10 <vmassol> (almost always)
11:11 <vmassol> hehe
11:11 <Trefex> directly is ok ?
11:11 <vmassol> yes
11:11 <Trefex> ya gonna snapshot the VM before i spuose
11:11 <Trefex> s/though/saw/
11:11 <vmassol> yep it is!
11:11 <vmassol> it now even supports wysiwyg editing
11:11 <vmassol> bad bot!
11:11 <Trefex> lol
11:12 Trefex punches the bot
11:12 <vmassol> but I've made it optional
11:12 <vmassol> no longer bundled by default
11:12 <Trefex> really? Can I try it somewhere in a demo ?
11:12 <vmassol> so you need to install it as an extension
11:12 <vmassol> in your wiki :)
11:12 <Trefex> before i upgrade :D
11:12 <vmassol> you can try in your wiki but you need to remove the existing one
11:12 <vmassol> there are instructions here:
11:13 <vmassol>
11:13 <vmassol> so in your case:
11:13 <vmassol> "To do so remove the following 2 JARs:WEB-INF/lib/xwiki-rendering-syntax-markdown10-<version>.jar and WEB-INF/lib/xwiki-rendering-syntax-markdown11-<version>.jar."
11:13 <vmassol> and then restart and install the extension
11:14 <Trefex> ok two options :d
11:15 <Trefex> is there a doc page about the new editor capability for markdown ?
11:15 <Trefex> If it works well, it's HUGE for us :)
11:16 <vmassol> TBH it's preliminary work but should work for the basic mardown syntax. I need someone who uses MD to try it out for real
11:17 <vmassol> my tests are done on contrived and small examples
11:17 <vmassol> so you could help me test it and tune it
11:17 <vmassol> do you have a wiki on
11:23 <vmassol> Trefex: releasing a new version now
11:24 <Trefex> vmassol: i don't have a wiki there i think, but i can make one?
11:24 <vmassol> no need
11:24 <vmassol> I'll install it on playground so that you can try it
11:25 <Trefex> vmassol: ok perfect, let me know
11:25 <vmassol> ah no
11:25 <vmassol> can't
11:25 <vmassol> :)
11:25 <vmassol> playground is running 7.4.2
11:25 <vmassol> so just do what I mentioned above
11:25 <vmassol> (remove the 2 jars and install the extension)
11:26 <vmassol> (if you want to try it)
11:26 <tmortagne> if you just want to test it the simplest is probably to use a jetty/hsqldb 8.2.1 instance
11:26 <vmassol> yep true
11:26 <tmortagne> plus you get to test other 8.2.1 stuff before upgrade
11:27 <Trefex> what's that
11:27 <tmortagne> Trefex: "Demon installation" on
11:27 <Trefex> Zip Package ?
11:28 <tmortagne> s/Demon/Demo/
11:28 <tmortagne> I prefer the zip package but it's just different way to install the same thing
11:28 <Trefex> uh i could run it in a virtualbox
11:28 <tmortagne> (the zip package does not put crap around)
11:28 <tmortagne> no need it's completely portable app
11:29 <tmortagne> you get embedded database, all data stay in the folder
11:29 <Trefex> i can run in my Mac?
11:29 <tmortagne> yes anywhere you have Java installed
11:29 <tmortagne> you just unzip and run
11:29 <vmassol> mflorea: i'm on and I'm running the EM Extension Updater. I'm checking for updates on farm but I see it's checking all subwikis, is that normal?
11:30 <vmassol> maybe we can't check just on the main wiki?
11:30 <tmortagne> vmassol: checking just on main wiki is the default AFAIK, you explicitely asked for farm if it search on all wikis
11:30 <vmassol> (which is a pity when you have 300 subwikis and you're looking for an extensions on the main wiki)
11:30 <Trefex> holy moly
11:30 <Trefex> that is fantastic
11:30 <vmassol> ahhhh I could have misread or misunderstood the text
11:31 <vmassol> it's very long, let's hope it doesn't bring down :)
11:31 <mflorea> vmassol: "I'm checking for updates on farm" <-- this means on all subwikis
11:31 <vmassol> can't stop it...
11:32 <mflorea> it's a job, runs in a background thread
11:32 <mflorea> and yes, you can't stop it atm
11:32 <tmortagne> vmassol: it's finished as far as I can see
11:32 <vmassol> yep just now
11:33 <vmassol> hmm didn't list anything
11:33 <tmortagne> yes there seems to be some error
11:33 <vmassol> org.xwiki.extension.job.plan.internal.DefaultExtensionPlanNode cannot be cast to org.xwiki.extension.job.internal.AbstractInstallPlanJob$ModifableExtensionPlanNode
11:33 <vmassol> anyway I'll do the upgreade of the extension I wanted manually
11:33 <vmassol> but this might be something we need to fix
11:37 <Trefex> k will get back to you
11:37 <Trefex> but so far i see
11:37 <Trefex> error when rendering
11:37 <Trefex> when editing the page again, all normal whitespaces are gone
11:38 <vmassol> Trefex: when editing a page using MD?
11:38 <Trefex> yep
11:38 <vmassol> (using the wysiwyg editor)
11:38 <Trefex> and the WYSIWYG is broken in the editor
11:38 <vmassol> refresh your cache maybe
11:38 <vmassol> browser cache
11:38 <vmassol> you're supposed to see CKEditor btw
11:39 <Trefex>
11:39 <Trefex> second image now here too:
11:39 <Trefex> this was after i hit save once
11:39 <Trefex> brb vmassol
11:40 <vmassol> wait
11:40 <vmassol> Trefex: would be nice if you could open a jira issue at with content with which you can reproduce the problem
11:40 <vmassol> (it has to be a problem with the content since I don't get this problem even with complex content)
11:41 <Trefex> you can see the content in the screenshot
11:41 <Trefex> it's not that complex
11:41 <Trefex> i have meeting now, i'll do later
11:41 <vmassol> I don't see it
11:41 <vmassol> I only see the error
11:41 <Trefex> refresh the page
11:41 <vmassol> ok got it
11:41 <vmassol> thanks
11:41 <vmassol> see you later
11:50 <vmassol> ok I can reproduce the NPE, fixing
11:51 <vmassol> then I need to reproduce the newline issue
11:51 <vmassol> FTR this NPE issue you had it already in your current version :)
12:05 <vmassol> FTR the issue is having a space in the image reference
12:06 <vmassol> (this is not supported by MD and pegdown)
12:06 <vmassol> preventing the NPE
12:33 <vmassol> tmortagne: what do you think is better to do for the MD parser when there's a space in an image reference (ex: "![label](ref with space)"):
12:33 <vmassol> option 1: generate ![label]  + the text "(ref with space)"
12:34 <vmassol> option 2: generate an exception failing the whole MD rendering saying that spaces are not supported in image ref
12:34 <vmassol> ?
12:34 <vmassol> I'm hesitating
12:36 <vmassol> the problem with option 1 is that it doesn't generate something that has much meaning
12:37 <vmassol> actually in html it generates
12:37 <vmassol> "<p>(link with space)</p>"
12:37 <vmassol> <p>(ref with space)</p>
12:41 <vmassol> basically pegdown ignores the reference part when there's a space
12:42 <vmassol> I could generate something with the label
12:42 <vmassol> bu t not sure what would make sense
12:56 <vmassol> ok I know what I'll do
12:56 <vmassol> since I've done it already for links
12:56 <vmassol> I'll consider the label to be the reference
13:15 <tmortagne> vmassol: I don't know what is best, I would look a other MD rendered like github
13:15 <tmortagne> i.e. the best is to do the same as other tools
13:16 <vmassol> good idea
13:16 <vmassol> but they probbaly handle spaces :)
13:16 <tmortagne> then it's a pegdown bug
13:16 <vmassol> it is IMO
13:16 <vmassol> but that doesn't help us :)
13:16 <tmortagne> is it reported on their side ?
13:16 <vmassol> you reported it
13:16 <vmassol> for links
13:16 <vmassol> but it's the same
13:17 <tmortagne> ok, don't remember
13:17 <vmassol>
13:17 <tmortagne> maybe we could try to fix it ourself then and provide a pull request, should make easier to have it
13:17 <vmassol> too bad we don't have an ErrorBlock
13:17 <vmassol> for inline errors
13:18 <vmassol> I can generate something like "Error: …."
13:19 <vmassol> yes it's pluggable and we can most likely plug a custom parser part
13:19 <vmassol> but it's complex
13:22 <tmortagne> vmassol: seems to me the real issue for you use case is actually
13:22 <tmortagne> [label](url) syntax is only for urls
13:22 <vmassol> yes
13:23 <vmassol> we do support the [[…]] syntax, it's only missing labels support in pegdown
13:23 <vmassol> but that's for links
13:23 <vmassol> not images
13:29 <gene> has quit
13:29 <gene> has joined #xwiki
13:45 <mflorea> vmassol: re and I think we should *by default* display the page titles in the current locale and sort the pages by the raw translated title (which is the closest to what we display). WDYT?
13:48 <vmassol> (mflorea, will check this after lunch, finishing somthing first then going for lunch)
13:49 <mflorea> the downside is the order of the default pages we get when you install XWiki
13:49 <mflorea> order by name: Blog, Home, Sandbox, XWiki (<-- what we currently have)
13:49 <mflorea> order by title: Blog, XWiki, Home, Sandbox
13:50 <mflorea> that is because Blog title is empty and XWiki title uses $services.localization, so the title starts with $
13:51 <tmortagne> mflorea: what does "*by default*" mean ?
13:51 <mflorea> what you see in the navigation panel and in the page index
13:51 <mflorea> and the breadcrumb trees
13:51 <mflorea> what you get with {{documentTree /}}
13:54 <tmortagne> what about adding a configuration somewhere to indicate what source to use for document tree and provide (at least) the following two sources:
13:54 <tmortagne> * a raw title based one (the one used by default)
13:54 <tmortagne> * a Solr based one (configured in XE)
13:54 <tmortagne> ?
13:54 <vmassol> Trefex: just fixed the white space issue:
13:56 <tmortagne> Solr is the best implementation in term of performances but it's not very nice to make core feature like document tree require it when we want solr to be an extension
13:56 <mflorea> tmortagne: db is faster than solr
13:57 <mflorea> but we don't have the rendered title
13:57 <tmortagne> yes so it's not faster :)
13:58 <tmortagne> I'm talking about source here, not just the first request to get the list
13:58 <tmortagne> Solr is by far the fastest because of title rendering
13:58 <mflorea> now, the Solr schema as it is right now doesn't provide all the required info. We would need to index spaces, in order to be able to support the holes we can have in the hierarchy
13:59 <tmortagne> that's something we want anyway I think
14:00 <mflorea> for my fix I'm still using the db, but I moved the code that controls the hierarchy in a component. So we can later add an implementation based on Solr
14:01 <mflorea> the document tree uses $services.tree.nestedPages.getChildren(...)
14:05 <vmassol> Trefex: new line work fine here. Can you tell me exactly what you've typed so that I can reproduce?
14:05 <vmassol> (going for lunch now but I'll read your answer when I'm back)
14:19 <mflorea> tmortagne: one thing that I'm not sure how we could implement in Solr is "sort by translated title with fallback on default translation". i.e. if the document has a translation for the current locale, then use its title otherwise use the title of the default translation. I'm currently using a left join on DB, but for Sold we need something different.
14:19 <mflorea> actually the fallback is [translated title, default title, page name]
14:20 <tmortagne> mflorea: don't we have something already for this ? solr is supposed to have a field locales with all the supported locales for which this title fit
14:20 <mflorea> for Solr we probably need to have a field that does this fallback at index time
14:20 <tmortagne> well that's the thing we have this field already
14:21 <mflorea> tmortagne: how would you use this locales field to sort the results?
14:21 <mflorea> sort by [translated title, default title, page name]
14:22 <tmortagne> what do you mean by sort
14:22 <tmortagne> this field filters
14:22 <mflorea> the child nodes are sorted
14:22 <mflorea> in the tree
14:22 <tmortagne> sure but but the sort is done "after" the filtering
14:23 <mflorea> ok, then how would you express this filter "given me the translation, or, if it doesn't exist give me the default translation"
14:23 <tmortagne> you don't
14:24 <mflorea> you need to
14:24 <tmortagne> again you have a "locales" field which you contains all the supported locales for which this document is the right one
14:25 <tmortagne> for example if you have in supported languages "fr, en" a document with locale "" and no translations you will all 3 locales in "locales" field
14:25 <mflorea> using locales=en doesn't match multiple translations?
14:25 <tmortagne> all you have to do with do the Solr request with a locales which is part of the supported locales
14:26 <tmortagne> locales=en will matches only documents you would see if you have en as current locale
14:27 <tmortagne> the "locales" field contains all the supported locales for which the document is the one to show in the UI
14:28 <tmortagne> the fallback is "calculated" during index basically
14:30 <tmortagne> I initially did this so that the main Solr search would look in all the documents you would see with the current locale instead on only the documents explicitly for the current locale
14:30 <tmortagne> so this field is pretty old
14:31 <mflorea> I know it'old
14:34 <mflorea> I though there could be multiple translations of a doc matched by locales=en, but it's not the case
14:35 <tmortagne> "so this field is pretty old" = might have been broken since it is not used anymore in the main UI but it's what it's supposed to do
14:36 <mflorea> it shouldn't be broken, I don't remember touching it, but indeed the search UI doesn't use it
14:37 <tmortagne> anyway import thing is that the concept already exist and just need to check if it still work and fix it otherwise since that would be a regression
14:37 <mflorea> now, another thing that worries me about Solr is sort and pagination performance. Solr is super fast for getting the fist page of result sorted by score
14:37 <mflorea> but if you want to paginate and sort by something else, it may not be that super fast
14:38 <tmortagne> sort performances is not so bad (especially compared to render each title one by one :)), highlight is
14:38 <tmortagne> s/highlight is/highlight is pretty bad/
14:39 <tmortagne> this remind me that we are starting to be quite behind on Solr version, they often improve performances
14:39 <mflorea> another thing, if a page uses $services.localization in its title, what do we index?
14:40 <tmortagne> whatever was the current locale when this document was saved I guess
14:41 <mflorea> most probably, so the sort won't be perfect
14:42 <tmortagne> not in this used case no, the only way around would be to have a field for each locale and render the title for each locale when the document is saved
14:42 <tmortagne> anyway it's not possible to fully support dynamic titles
14:42 <tmortagne> it could depend on the current user, the date, etc...
14:42 <tmortagne> but won't be better with DB
15:01 <vmassol> mflorea: back. You still  need my input or is the discussion with thomas enough?
15:02 <mflorea> the discussion with tmortagne was on a different subject (related though)
15:02 <Trefex> am back vmassol, will try to create a use case for you
15:03 <vmassol> Trefex: ok great thanks. I'm watiing for see if there's a bug before releasing a new version of the markdown extension
15:03 <mflorea> basically my initial question is where it's fine if the user sees "XWiki, Blog, Main, Sandbox" in the tree by default
15:03 <Trefex> vmassol: ok it breaks when you drag and drop an image into the WYSIWIG part, and then save
15:03 <vmassol> actually it works
15:03 <vmassol> I think
15:04 <Trefex> well i can do a video if you want :)
15:04 <vmassol> but you must not have spaces in the image name
15:04 <Trefex> ah
15:04 <Trefex> that is a shitty constraint
15:04 <Trefex> can't you rename those in import ?
15:04 <vmassol> and the image syntax only accepts urls
15:04 <vmassol> see
15:04 <vmassol> and
15:05 <vmassol> wrong last link
15:05 <vmassol> (
15:05 <vmassol> mflorea: where = whether? checking what you said above
15:05 <Trefex> so you opened a ticket and an issue
15:05 <Trefex> and you say it works :D
15:06 <vmassol> what I mean is that it only fails if you have spaces
15:06 <mflorea> yes, "whether it's fine"
15:06 <Trefex> vmassol: ok, can i rename an attachment?
15:06 <Trefex> or somehow remove white spaces on import ?
15:06 <vmassol> no
15:06 <vmassol> no
15:06 <vmassol> :)
15:06 <vmassol> attachment names support all chars
15:07 <Trefex> roh
15:07 <Trefex> then we don't want to use it yet :)
15:07 <Trefex> let me do some other tests
15:08 <vmassol> actually
15:08 <vmassol> forget that
15:08 <Trefex> no tests?
15:08 <vmassol> wdym?
15:08 <Trefex> not sure what you mean :)
15:09 <M-mouhb> has quit
15:09 <M-mouhb> has joined #xwiki
15:09 <M-cjd> has quit
15:09 <M-yflory> has quit
15:09 <M-cjd> has joined #xwiki
15:10 <M-yflory> has joined #xwiki
15:10 <Chris[m]> has quit
15:10 <jihad[m]> has quit
15:11 <Trefex> vmassol:
15:11 <Trefex> try the following
15:11 <Chris[m]> has joined #xwiki
15:11 <Trefex>
15:11 <Trefex> save, edit, save
15:11 <Trefex> now it is fucked and the content of the code block vanished
15:12 <vmassol> mflorea: not sure what you mean by "basically my initial question is where it's fine if the user sees "XWiki, Blog, Main, Sandbox" in the tree by default"
15:12 <vmassol> Trefex: ok, I'l try. Coud you also find how to reproduce the issue you had with newlines
15:12 <vmassol> ?
15:13 <Trefex> vmassol: that happens when you insert an image with spaces
15:13 <Trefex> then it renders the edit window by putting everything in one line
15:15 <mflorea> vmassol: currently the navigation panel shows "Blog, Home, Sandbox, XWiki". The nodes appear sorted (because the tree is sorted by page name). With my changes the navigation panel will display "XWiki, Blog, Home, Sandbox", which is the order when you sort by (raw) page title.
15:16 <jihad[m]> has joined #xwiki
15:16 <vmassol> mflorea: I don't get it. You want to sort by raw page title but not display the titles?
15:18 <mflorea> no, I'm just explaining you how the navigation panel looks like when sorted by page name vs. sorted by page title, and I would like to know if you're ok with how it looks like when sorted by raw page title
15:18 <vmassol> sorry but I can't answer without seeing how it's displayed with titles
15:18 <vmassol> (I don't know them by heart)
15:18 <vmassol> would you have an image?
15:18 <mflorea> I just showed you..
15:18 <vmassol> I don't understand
15:18 <vmassol> "Blog" is the title?
15:19 <vmassol> and "XWiki" is the title?
15:19 <vmassol> so why is "XWiki" before "Blog"?
15:19 <vmassol> (I'm mssing some data/context to understand)
15:19 <mflorea> you can check on your instance, "Blog" is the rendered title of the Blog home page
15:20 <vmassol> raw title is what?
15:20 <mflorea> empty, for Blog.WebHome
15:20 <vmassol> so raw title is WebHome, is that it?
15:20 <mflorea> the tree display the rendered title, no change here
15:21 <mflorea> raw title is what you put in the title field in wiki edit mode. It's not WebHome. For Blog.WebHome the title field is left empty
15:23 <vmassol> so what's the proposal? to have the sort by default or to have it as an option?
15:23 <vmassol> because it doesn't look that good
15:23 <vmassol> I remember saying ""Just to be clear, what's a no go for me is not that we sort by raw title but that we sort on something different than what we display (so if we display raw titles then sorting by raw titles is ok).""
15:24 <mflorea> the reason "XWiki" appears before "Blog" is because the row title of XWiki.WebHome is "$services.localization..."
15:25 <mflorea> vmassol: you cannot sort exactly on what we display as long as we have dynamic titles, there's no perfect solution here.
15:25 <mflorea> the question is whether sorting by raw title is better than sorting by page name
15:26 <mflorea> I think it is, for the end user, even if the navigation panel show XWiki before
15:26 <vmassol> I don't know
15:26 <vmassol> I would need to see this in action for real
15:26 <vmassol> hard to answer
15:26 <vmassol> now for the tree entries you get in a clean wiki
15:27 <vmassol> I guess it could be possible to tune some titles so that they appear in the "right" order
15:27 <mflorea> the users won't change the navigation panel or the page index to change the sort order, if we don't use title sort by default
15:27 <vmassol> unless ther'e's a sorting option in the panel
15:27 <mflorea> and the users will care more about their content
15:28 <mflorea> not the default pages
15:28 <vmassol> we can be sure they'll ask questions anyway
15:28 <vmassol> especially if the default doesn't match the order
15:34 <tmortagne> mflorea: content is not just simple wiki pages, entries created in some app usually have empty title
15:34 <mflorea> empty title is fine, there's a fallback on page name in this case
15:34 <mflorea> the problem is with velocity code in page titles
15:34 <tmortagne> but the page name might not have much to do with the rendered title
15:35 <mflorea> sure, I didn't say it's perfect, there's no perfect solution
15:36 <tmortagne> well that's my point too, "we sort on something different than what we display" is impossible to reach 100% if we show display title
15:37 <tmortagne> mflorea: like you I'm fine with it but as long as vmassol make it a blocker I don't see any way to support rendered titles
15:46 <vmassol> "empty title is fine, there's a fallback on page name in this case" why is it fine?
15:46 <vmassol> for nested pages this means "WebHome", no?
15:47 <msmeria> has quit
15:49 <vmassol> IMO the documentTree macro should support several options: display rendered titles or page names and sort on raw title or page name. Then the question is about the default and what we want to have in the Nav Panel and in AllDocs's tree tab, by default (and whether it's possible to change the view from there).
15:50 <vmassol> It's really hard to know what's the best default without seeing it on a default wiki and on a wiki with data (for example some existing wiki).
15:50 <vmassol> which is why I was asking for some images
15:51 <vmassol> I'm fine to try whatever you want to not be blocked though
15:51 <vmassol> let's sya it differently
15:52 <vmassol> without seeing more and spending more time to try it out under various situations, I'm 0
15:52 <vmassol> (not -1 and not +1). I'll go with what you think is best
15:52 <vmassol> (since you've worked on the topic a lot more than I've done)
15:53 <vmassol> FTR this is exactly what I mentioned in the jira issue too
15:54 <vmassol> ok not exactly, but close :)
15:54 <vmassol> Anca said:
15:55 <vmassol> "I changed the type of the issue from "improvement" to "bug" because, for the end user, seeing a hierarchy as the one in the attachment looks more like a bug than an improvement. It's difficult to understand why that tree looks like that."
15:55 <vmassol> my bet is that someone will report a bug soon after we do this, saying that same thing, in the opposite direction ;)
15:55 <vmassol> especially since by default it'll look unsorted
15:55 <vmassol> by default  = when starting with xwiki
15:56 <mflorea> 16:46 <vmassol> for nested pages this means "WebHome", no?
15:56 <mflorea> no
15:57 <mflorea> for nested pages it means the space name, I've taken care of this
15:57 <vmassol> ok
15:57 <tmortagne> mflorea: IMO if we show display title, Solr is the solution that will give the less complain (since that's the only one storing them, at least display title in the context when the document was saved). We will have way too many issues with applications with a DB based solution
15:58 <vmassol> mflorea:  a quick offtopic solution. Can I still have a debug view of the WYSIWYG even with CK? I don't reember what query string parameter I should use (but debug=true doesn't seem to work)
15:59 <vmassol> too bad if we don't have it with CK, it was a nice feature when debugging a rendering issue in the wysiwyg ;)
15:59 <blabla2[m]> has quit
16:00 <M-vmassol> has quit
16:02 <mflorea> tmortagne: Solr provides a solution for the rendered title, but it brings its own complexities. I find it strange to use a search engine to get the data for the tree. Solr wasn't meant for this and I'm worried that its performance may decrease when it's used as a store rather than as a search engine. I remember reading somewhere that it's not recommended to use only Solr to store your content
16:04 <vmassol> so you're saying that solr is not a contender for elasticsearch for example
16:04 <mflorea> vmassol: I'm not sure what debug mode you are referring to
16:04 <vmassol> because ES is supposed to be used as a store for sure
16:04 <vmassol> mflorea: the mode where you could side the various inputs side by side
16:04 <blabla2[m]> has joined #xwiki
16:04 <vmassol> s/side/see
16:04 <vmassol> syntax before conversion to HTML
16:04 <vmassol> s/syntax/content
16:05 <vmassol> content after HTML conversion
16:05 <vmassol> content after conversion back to syntax
16:05 <M-vmassol> has joined #xwiki
16:05 <mflorea> I haven't use that in years
16:05 <mflorea> you have the network tab
16:05 <mflorea> that's what I use, I forgot about this debug mode
16:05 <mflorea> brb
16:05 <vmassol> testing
16:06 <vmassol> hmm
16:07 <vmassol> don't see the request
16:07 <vmassol> wait
16:07 <vmassol> I was filtering on XHR only
16:07 <vmassol> :)
16:09 <vmassol> still trying to find it
16:10 <vmassol> ok I'm stopping searching
16:10 <vmassol> I'll just put breakpoints in the code...
16:28 <mflorea> vmassol: you need to Save & Continue or switch to Source to see the request
16:32 <vmassol> ah ok
16:33 <vmassol> mflorea: could you help me location the place where I can put a breakpoint in CK
16:33 <vmassol> the place where it converts from HTML to the target syntax
16:34 <mflorea> the conversion is done on the server side
16:34 <vmassol> so still using the gwt service?
16:35 <vmassol> (don't remember exactly the same)
16:35 <vmassol> looking ofr it...
16:35 <mflorea> no
16:35 <vmassol> DefaultHTMLConverter
16:35 <mflorea> for save action there is the ConversionFilter (servlet filter)
16:35 <mflorea> which calls DefaultHTMLConverter indeed
16:36 <vmassol> fromHTML() I gurss
16:36 <mflorea> yes
16:36 <vmassol> thx
16:37 <mflorea> this is for save action
16:37 <vmassol> hmm something is weird
16:38 <vmassol> this is what I see when editing in CK:
16:38 <vmassol> but when I hit save
16:38 <vmassol> in fromHTML() I get the following HTML as input
16:39 <vmassol>
16:39 <vmassol> as you can see the content has been lost
16:40 <xwikiorg_guest_8> has joined #xwiki
16:40 <mflorea> that's normal
16:40 <vmassol> ah ? :)
16:40 <mflorea> what you see in CK is the macro output, we don't submit the macro output
16:41 <mflorea> the macro output is not saved
16:41 <vmassol> argh….
16:41 <xwikiorg_guest_8> b
16:42 <xwikiorg_guest_8> hey there
16:42 <xwikiorg_guest_8> i'm new to open source
16:42 <xwikiorg_guest_8> could i get some help
16:43 <mflorea> vmassol: the macro content is missing from the macro marker it seems
16:43 <mflorea> !--startmacro:code|-|language="php"|-|-->
16:43 <mflorea> this means {{code language="php" /}}
16:43 <mflorea> no content
16:43 <vmassol> yes that's what I get in output thus failing the round trip
16:44 <vmassol> checking the HTML syntax code now
16:44 <mflorea> check the HTML input, is the macro content correctly encoded in the macro marker?
16:44 <mflorea> there may be an issue there
16:44 <xwikiorg_guest_8> has quit
16:44 <vmassol> you mean output of toHTML()?
16:46 <mflorea> I don't think so, let me check
16:46 <vmassol> seems good:
16:46 <mflorea> $!services.wysiwyg.toAnnotatedXHTML($source.content, $source.syntax.toIdString())
16:47 <vmassol> (what I've pasted is hte output of toHTML())
16:47 <vmassol> ie from source syntax to HTML
16:47 <vmassol> then CK uses that HTML
16:48 <mflorea> ok, let's check with a validator
16:53 <mflorea> seems to be valid
16:54 <vmassol> so the content is lost somewhere inside ck processing right?
16:54 <vmassol> (when saving)
16:54 <vmassol> I guess you have some cleanup when saving
16:54 <vmassol> before calling fromHTML()
16:55 <mflorea> yes, on the client side
16:55 <vmassol> what shall I do? Shall I open a jira issue with the HTML input?
16:56 <vmassol> can I debug further or is it going to be complex for me?
16:58 <vmassol> what's strange is that it seems to work with with xwiki syntax 2.1
16:58 <vmassol> s/with with/fine with
17:00 <vmassol> wait
17:00 <vmassol> needs ot use the same input
17:00 <vmassol> maybe it's the <php> causing the problem
17:00 <vmassol> testing
17:00 <mflorea> could be an issue on (parseMacroCall / serializeMacroCall)
17:01 <vmassol> yep
17:01 <mflorea> I have some unit tests in
17:01 <vmassol> same proboem with xwiki syntax 2.1
17:01 <mflorea> I could add a unit test for this use case
17:01 <vmassol> so the issue
17:01 <vmassol> is the first <
17:01 <vmassol> if I remove it, it works fine
17:02 <vmassol> mflorea:
17:02 <mflorea> maybe because it's not XML-encoded
17:03 <vmassol> yes most likely
17:03 <vmassol> so could be a HTML syntax bug actually
17:03 <vmassol> checking that
17:04 <mflorea> but it's strange that doesn't complain
17:05 <vmassol> it would be strange that we have this bug since forever...
17:10 <vmassol> so the code is in XHTMLMacroRenderer
17:10 <vmassol> and then we call printXMLComment() which may contain the bug
17:10 <vmassol> checking more
17:10 <acotiuga> has quit
17:11 <vmassol> haha this cals XMLUtils.escapeXMLComment()
17:11 <vmassol> checking there now
17:13 <vmassol> indeed it doesn't escape the <
17:13 <vmassol> now I need to find the HTML spec to see if we need to escape < in html comments or not
17:17 <vmassol> well
17:17 <vmassol> still need to find the answer but AFAIr it's always been accepted to have < in comments....
17:18 <vmassol> reading
17:20 <vmassol> yep it's valid
17:20 <vmassol> mflorea: so XHTMLMacroRenderer is doing the right thing apparently and it shouldn't be the problem
17:21 <mflorea> yes, I don't think the problem is on the server side, it must be on the client side, but I need to debug the CKEditor code. You should report an issue
17:25 <gdelhumeau> Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [interface org.xwiki.xml.html.filter.HTMLFilter] hint = [link]]
17:26 <gdelhumeau> I'm creating this new component
17:26 <gdelhumeau> declaring it in components.txt
17:26 <gdelhumeau> added @ComponentList({ LinkFilter.class, ...) to my test class
17:26 <gdelhumeau> anyway, the test still claim that my component descriptor does not exist
17:27 <tmortagne> you sure you have @Named("link") ?
17:27 <vmassol> it's probably true :)
17:28 <gdelhumeau> @Component
17:28 <gdelhumeau> @Named("link")
17:28 <gdelhumeau> and:
17:28 <gdelhumeau> @Inject
17:28 <gdelhumeau>     private HTMLFilter linkFilter;
17:29 <vmassol> can you show components.txt?
17:29 <tmortagne> components.txt does not really matter since it's not used here
17:30 <gdelhumeau>
17:30 <tmortagne> what rule are you using ? MockitoComponentMockingRule ?
17:30 <vmassol> mflorea: I've modified your test and built CKeditor app
17:31 <vmassol> mflorea: and it still passes which means either the test is not executed or it's not doing much :)
17:31 <gdelhumeau> MockitoComponentMockingRule<HTMLCleaner> mocker
17:32 <tmortagne> it's public and you have @Rule ?
17:32 <vmassol> mflorea: at line 152, I've replaced [content: '="|-|\\',] with [content: '<="|-|\\',]
17:32 <gdelhumeau> yes
17:32 <gdelhumeau> and it's an old test already
17:32 <gdelhumeau> so it used to work
17:32 <tmortagne> which test is that ?
17:32 <gdelhumeau> the only thing new is the inject I showed you
17:32 <mflorea> vmassol: I tried that myself, it just means the content is lost somewhere else, not when parsing/serializing the  macro call
17:32 <gdelhumeau> DefaultHTMLCleanerTest in commons
17:33 <gdelhumeau> commons-xml
17:33 <vmassol> mflorea: ok I'll raise a jira for you
17:33 <tmortagne> and LinkFilter is in xwiki-commons-xml ?
17:33 <mflorea> it could also be a "feature" of CKEditor, that strips "insecure" content
17:33 <gdelhumeau> I've created near the old filters
17:34 <gdelhumeau> so yes, in the  same module
17:34 <mflorea> vmassol: such as
17:34 <mflorea> (but this is old)
17:34 <vmassol> ok
17:34 <mflorea> I need to debug CK and see what's happening
17:35 <vmassol> good finding Trefex! :)
17:35 <tmortagne> gdelhumeau: I don't really have any other idea than debugging MockitoComponentMockingRule
17:35 <gdelhumeau> the funny thing is that I also have a problem with IDEA
17:37 <gdelhumeau> oh got it
17:37 <gdelhumeau> the error came from an other test class ;-(
17:38 <tmortagne> gdelhumeau: you could start with a breakpoint in org.xwiki.test.internal.ComponentRegistrator#getComponentDeclarationsFromAnnotation
17:39 <vmassol> mflorea:
17:40 <mflorea> ok, thanks
17:42 <vmassol> mflorea:  I think you're right
17:42 <vmassol> changing the issue
17:42 <vmassol> the issue seems to be with the "<?" combination
17:43 <Trefex> vmassol: welcome
17:45 <vmassol> Trefex: seems you have knack for that
17:45 <vmassol> :)
17:45 <vmassol> finding weird situations...
17:45 <Trefex> yeah
17:45 <vmassol> so you resume your test but please don't use the combination "<?" in a macro :)
17:46 <vmassol> s/so you/so you can/
17:46 <vmassol> (when editing in the wysiwyg editor)
17:46 <vmassol> (when using CKeditor)
17:46 <vmassol> Trefex: I'm still interested by reproducing the new lines issue that you got earlier on
17:47 <Trefex> vmassol: just drag a image in with spaces in the name
17:47 <Trefex> save, edit, done
17:47 <vmassol> I've fixed that already
17:47 <vmassol> the image with space in name
17:47 <Trefex> then it should be ok
17:47 <Trefex> no
17:47 <vmassol> ok trying
17:47 <vmassol> without space in name
17:48 <vmassol> works fine for me
17:48 <vmassol> what should it do?
17:48 <Trefex> 1 sec phone
17:49 <Trefex> so, i think because the image had spaces, the rendering got screwed
17:49 <Trefex> and newlines were removed
17:49 <vmassol> trying
17:50 <Trefex> you can see the result here:
17:50 <vmassol> nop
17:50 <vmassol> nope
17:50 <vmassol> doesn't screw up the layout
17:50 <Trefex> this was rendered properly with newlines and image before clicking save
17:50 <vmassol> (there's no reason it should)
17:50 <Trefex> then error, then edit, it looks like this
17:50 <vmassol> it may depend where you dragged the image maybe
17:51 <Trefex> at the end
17:51 <vmassol> ah you
17:51 <vmassol> you got this after editing the second time?
17:51 <vmassol> got it!
17:51 <vmassol> I could reproduce
17:51 <Trefex> create post (add text + images), save, edit
17:51 <Trefex> ok
17:51 <vmassol> the save works
17:51 <vmassol> except for the error
17:51 <Trefex> yep but the edit doesn't
17:51 <vmassol> but then when you edit the second time you get the problem
17:52 <Trefex> ya
17:52 <Trefex> when i test, i TEST :D
17:52 <vmassol> and yes it doesn't reproduce after removing the spaces in the ref
17:52 <vmassol> so that's fixed too
17:52 <vmassol> cool
17:52 Trefex dances
17:53 <vmassol> anything else?
17:53 <vmassol> :)
17:53 <Trefex> mhhhh
17:53 <Trefex> not for now
17:53 <Trefex> waiting for you to release new version, so i can try in jetty
17:53 <Trefex> and THEN I'll test it
17:53 <Trefex> ohhh i'll test it real good
17:53 <vmassol> you can test
17:54 <vmassol> just don't put spaces in image names
17:54 Trefex that sounds weird
17:54 <vmassol> that's all
17:54 <vmassol> don't need to wait
17:54 <Trefex> nah i'll wait
17:54 <Trefex> wanna test the real use case
17:54 <vmassol> I'm not going to release
17:54 <Trefex> also in 4 mins i have to go
17:54 <vmassol> :)
17:54 <vmassol> at every bug fix
17:54 <vmassol> I'd like to gather a few before doing a new release
17:54 <Trefex> fine
17:54 Trefex grumbles
17:54 <vmassol> so it would gelp if you could test a bit more
17:54 <vmassol> :)
17:55 <vmassol> thanks! :)
17:55 <vmassol> have to swtich context too
17:55 <vmassol> since MD shouldn't be my priority at the moment
17:55 <vmassol> ...
17:56 <Trefex> vmassol:
17:56 <Trefex> hehe
17:56 <Trefex> thought you'd like this service :D
17:56 <Trefex>
17:57 <vmassol> sounds funny (even though I don't think I get the joke) :)
17:57 <Trefex> mhhh you have to enact it
17:57 <Trefex> anyhow, there are other more funny ones :P
17:58 <vmassol> hehe
17:58 <vmassol> I just hope you're happy that I spent some time fixing MD stuff in xwiki
17:58 <Trefex> dude, it's epic
17:58 Trefex thanks vmassol warmheartadly
17:59 <vmassol> np, this I understands better :)
17:59 <vmassol> lol
17:59 <Trefex> we use it exclusively to document all our Ops stuff
18:00 <vmassol> that's cool
18:04 <Trefex> vmassol: good evening Vincent. See you tomorrow for updates on the MD front! Thanks for the awesome work and also thanks for fixing things on the lower end of your prio
18:06 <vmassol> good evening Trefex
18:34 <vmassol1> has joined #xwiki
18:40 <tmortagne> has quit
18:47 <mflorea> has quit
18:52 <vmassol1> has quit
18:57 <Pbas> has quit
19:03 <sagarhani> has quit
19:11 <Pbas> has joined #xwiki
19:20 <sagarhani> has joined #xwiki
19:38 <vmassol> has joined #xwiki
19:41 <vmassol> has quit
19:42 <vmassol> has joined #xwiki
19:50 <evalica> has quit
19:50 <Enygma`> has quit
19:52 <vmassol> has quit
21:21 <mflorea> has joined #xwiki
21:28 <mflorea> has quit

Get Connected