Drag'n'drop in the back end

[leofeyer]

Make trees sortable and update all JavaScript wizards.

Download the attachments Related issues: #2058, #3375

--- Originally created on July 12th, 2009, at 12:49pm (ID 874)

[leofeyer]

Unfortunately, it seems impossible to accomplish sortable page and file trees. Although there is a script that supports sortable nested lists (=trees), there are a lot of additional things like pagemounts, access permissions and circular references that it does not cover (of course, because they are TYPOlight specific). After two days of trial and error (mainly error), I am finally giving up.

I am going to leave the ticket open in case someone else wants to take care of it.

--- Originally created on October 18th, 2009, at 09:28pm

[leofeyer]

A MooTools tree script is availble here: http://cpojer.net/page/Scripts

--- Originally created on October 20th, 2009, at 06:45pm

[ghost]

here too : http://mifjs.net/tree/

--- Originally created by cyril on February 6th, 2010, at 10:44pm

[leofeyer]

@andreas.schempp: How do I get your patch to work? It looks promising, but it does not do anything :)

--- Originally created on August 26th, 2011, at 03:55pm

[leofeyer]

I see, currently only working in Safari/Chrome :)

--- Originally created on August 26th, 2011, at 04:15pm

[leofeyer]

Andreas, which (version of the) JavaScript have you used? I have compared your changes to http://cpojer.net/MooTools/tree/Demos/, however there are differences. Also, where are Class.Binds and Class.Singleton from?

--- Originally created on October 26th, 2011, at 04:24pm

[ghost]

Class.Binds is from mootools more.

--- Originally created by backbone on October 26th, 2011, at 04:57pm

[aschempp]

Class.Singleton is from PowerTools, as the tree class is. As far as I can remember, I had to adjust the script to work as required, like preventing first level items to be reordered as subitems.

--- Originally created on October 27th, 2011, at 08:23pm

[leofeyer]

Any chance that you can create a patch using the latest version of the tree script? And please provide the copyright notices of any script that you use, otherwise I cannot add it.

--- Originally created on November 8th, 2011, at 07:52pm

[aschempp]

I will look into it, but probably not before the Camp...

--- Originally created on November 8th, 2011, at 08:57pm

[aschempp]

Maybe you can assign the ticket to me?

--- Originally created on November 8th, 2011, at 08:57pm

[aschempp]

I just merged the latest tree script, but it is 99% the same. The major changes are from me, I had to adjust it to work with Contao. In Contao backend, the tree is not like the frontend navigation (subitems inside li element), but there is a second li element for subitems. The original script did not support that.

Anyway, are you aware the script is not tested / does not work with Mode 6 (article) trees?

PS: I've also merged Contao 2.11 into the ticket branch, because afaik the feature should become available then.

--- Originally created on November 18th, 2011, at 12:32am

[leofeyer]

How about this issue? Any progress or pull requests?

[aschempp]

You know there is a branch in the old SVN? It's all in there you should need...?

[aschempp]

I'll look into the whole pull request fun ;-)

[aschempp]

See pull request #3685

[leofeyer]

I have added your changes, however it does not work :(

Also, you have messed up the code indentation in the JavaScript file. I had to correct it manually.

Does your code work on your installation?

[leofeyer]

I'm afraid I have to move this ticket to a later release. It does not work at all in Firefox and only with a single item in Safari. If you want to move a second item, you have to reload the page first.

[aschempp]

I agree... I told you it's not done ;-)

[leofeyer]

Once it is, it will be cool though ;)

[AgentCT]

Have you found another idea to realise it?

[may17]

I am working on a own drag and drop solution for listing tree`s. There are a lot of pitfalls when you working on this features. The feature is part of my "Backend Tools for contao" project and would release anyway as modul. Maybe i could create a pre release only for the drag and drop tree feature?

You can take a look on how it works in this video: http://may17.de/dandd.mp4

[AgentCT]

That looks very good. Do you have a version for tests?

[HellPat]

that looks really nice. Have you done it for the page-tree, too?

[may17]

@psren At the moment the solution works only with tl_article but the page tree would be supported too. It`s a own mootools drag and drop class, specially written for contao so everything could be optimized individual.

@AgentCT I work on a beta solution and hope to release it soon on github.

[aschempp]

Do you want to assign this to me, or @contao/workgroup-core ?

[may17]

hi andreas, for sure. I will contact you via skype in the next days to explain the trouble spots.

[Ruudt]

may17, May I suggest that the moveable cross icon be removed and the blue arrow be the item that moves the row? After drag cancel the onclick.

Would be cool to have for pages. I had not thought it was this hard to implement into Contao x-browser though!

[leofeyer]

@may17 Do I remember correctly, that we talked about this issue recently? You told me it would be a lot easier to accomplish if we made some markup changes, but I don't remember if you also told me what changes would have to be made :)

[aschempp]

I guess the child list elements should be inside the parent list elements...

[may17]

@leofeyer the tree widget should be a nested list. The most drag and drop solutions are using this construct.

[discordier]

@may17 Could you provide a p.o.c. for the DCG tree template?

[aschempp]

Theoretically, it will also work with the non-nested list, but as @may17 we would need to heavily modify the existing JS libraries. I did something years ago, see https://github.com/aschempp/contao-core/tree/pagetree-drag%26drop

@discordier it should simply look like the regular navigation template. However, I remember there were reasons for the non-nested version, something related to the open/collapse operations.

[may17]

@discordier yes we should talk in the next days about it.

@aschempp I've created a own script for drag and drop in the contao backend but there are a couple of troubleshoots. Maybe it's a good idea to have a mumble call?

[leofeyer]

I've tried to adjust the markup today, which is easy for the back end navigation and the site structure, but nearly impossible for the article tree. I'm not even sure how the markup should look like:

<ul>
  <li>Music Academy
    <ul>
      <li>The academy (Seite)
        <!-- One UL for the articles -->
        <ul>
          <li>The academy (Artikel)</li>
        </ul>
        <!-- One UL for the subpages -->
        <ul>
          <li>News (Seite)
            <ul>
              <li>News (Artikel)</li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
</ul>

Or one combined list for articles and subpages:

<ul>
  <li>Music Academy
    <ul>
      <li>The academy (Seite)
        <!-- One UL for the articles and subpages -->
        <ul>
          <li>The academy (Artikel)</li>
          <li>News (Seite)
            <ul>
              <li>News (Artikel)</li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
</ul>

@frontendschlampe /cc

[Aybee]

I think we have to use version 2. I never saw two ULs inside one LI. http://www.w3.org/wiki/HTML_lists The contextual meaning should be nearly the same - one parent with two childs

• The academy (Seite)
  • The academy (Artikel)
  • News (Seite)

Although the second child is from another type here.

[leofeyer]

Just because you have never seen it before does not mean its wrong :) Actually, there will be a lot more inside the list elements:

<ul>
  <li>
    <div class="tl_left"></div>
    <div class="tl_right"></div>
    <div class="clear"></div>
    <ul>
      <!-- Articles -->
    </ul>
    <ul>
      <!-- Child nodes -->
    </ul>
  </li>
</ul>

[Ruudt]

@Aybee The validator at w3.org passes that as correct HTML4 and HTML5. So I think it will be ok for now.

I have another idea (that also passed the validator). Pages are unambiguously ordered in the site structure. The articles order is arbitrary (it mixes articles possibly in different sections). So it wouldn't be outside of semantics to display the site structure as an ordered list and the articles as an unordered list. This gives a mixed result in the articles view that might solve the problem?

<ol>
  <li>Music Academy
    <ol>
      <li>The academy (Seite)
        <!-- One UL for the articles -->
        <ul>
          <li>The academy (Artikel)</li>
        </ul>
        <!-- One UL for the subpages -->
        <ol>
          <li>News (Seite)
            <ul>
              <li>News (Artikel)</li>
            </ul>
          </li>
        </ol>
      </li>
    </ol>
  </li>
</ol>

[Aybee]

@leofeyer Just because you have never seen it before does not mean its wrong :)

Ah, I see, you prefer version 1 ;). Yes you're right it does not mean that it's wrong. But I would not recommend version 1 as I nowhere can find an example of using two ULs as direct child of one LI and so to prevent unwanted bad effects. The relationship of those LIs is somehow unclear I think.

<!-- v1 -->
<ul>
  <li>1
    <ul>
      <li>1-1
        <ul>
          <li>1-1-1
        </ul>
        <ul>
          <li>1-1-1
            <ul>
              <li>1-1-1-1
<!-- v2 -->
<ul>
  <li>1
    <ul>
      <li>1-1
        <ul>
          <li>1-1-1
          <li>1-1-2
            <ul>
              <li>1-1-2-1

Furthermore v1 has more DOM nodes, and also in version 2 you can put some DIVs into a LI element.

@Ruudt This is sematically incorrect using an OL for pages and a UL for articles. If at all, then Articles should be listed numbered, as they apear in this order in a layout section in front end. And this only if all articles get included into only one section.

[Ruudt]

@leofeyer Would using ol & ul solve the problem at all?

@Aybee You name the main reason why I think articles should be ul.

But there is reason to my ol/ul madness, let me explain! In the frontend the meaning of the pages mostly requires them displayed as unordered lists. (Though in rare cases ol could be correct; instructions for example usualy are in order.) But in the backend the meaning of the page name can become less important. The site structure and article structure are meant to indicate at which point certain information must be displayed. This makes the order more important and justifies use of ol for pages. Pages are always displayed in that order. But for articles the order displayed is arbitrary, so ul can be used.

You can also reverse the logic like you say and decide you don't see order in pages but you do think articles are in correct order. So you'd use ul/ol instead. Would stil "work" and if asked can be explained. On May 5, 2015 1:38 AM, "Andreas Burg" notifications@github.com wrote:

@leofeyer https://github.com/leofeyer Just because you have never seen it before does not mean its wrong :)

Ah, I see, you prefer version 1 ;). Yes you're right it does not mean that it's wrong. But I would not recommend version 1 as I nowhere can find an example of using two ULs as direct child of one LI and so to prevent unwanted bad effects. The relationship of those LIs is somehow unclear I think.

• 1
  • 1-1
    • 1-1-1
    ```
    • 1-1-1
      • 1-1-1-1 ```
        • 1
          • 1-1
            • 1-1-1
            • 1-1-2
              • 1-1-2-1 Furthermore v1 has more DOM nodes, and also in version 2 you can put some DIVs into a LI element. @Ruudt https://github.com/Ruudt This is sematically incorrect using an OL for pages and a UL for articles. If at all, then Articles should be listed numbered, as they apear in this order in a layout section in front end. And this only if all articles get included into only one section. — Reply to this email directly or view it on GitHub https://github.com/contao/core/issues/874#issuecomment-98885064.

[leofeyer]

Ah, I see, you prefer version 1 ;)

@Aybee No, I just pointed out that using two ULs is not wrong.

[aschempp]

Just to be clear on a few things here:

• Technically, it is totally irrelevant if we use ul, ol, divs or anything else.
• As a comparison, in the current implementation, the elements are not nested at all.

If we are going to use a third-party script for the drag&drop functionality (which is pretty likely in my opinion), we should adjust our markup to match what the script needs…

[leofeyer]

in the current implementation, the elements are not nested at all

Which pretty much is the initial problem :)

If we are going to use a third-party script for the drag&drop functionality (which is pretty likely in my opinion), we should adjust our markup to match what the script needs…

@may17 actually wanted to look into this but he told me that we first need a real nested list, because all scripts require this. That's why I'm trying to change the markup.

[may17]

a real nested list makes more sense and the most tree extensions are build up on them. For sure it`s possible to build an own solution (thats what i already tested).

perhaps we should mumble tomorrow or on friday @leofeyer ?

[may17]

I`ve created an proof of concept for the article list drag and drop without any template changes.

Check it out under https://github.com/may17/contao-dragAndDropArticlePoc

The ajax implementation is not included but i think this should be an good example how to implement drag and drop without template edits.

[leofeyer]

@ausi has implemented drag and drop for the file manager in https://github.com/contao/core-bundle/pull/1394 and https://github.com/contao/core-bundle/pull/1386. Maybe this can be used as template for the site structure and the article tree?

[may17]

I could check this but isn`t it time to replace all the mootools stuff with preact or vue components for the next major release?

[leofeyer]

Yes, but I was hoping we could implement drag and drop in the next minor version.

[may17]

Ok i will check that but i have to figure out how to work on contao 4.x core-bundle. Atm i`ve only had an docker image for extension development. Any suggestions? How did you core dev guys that?

[may17]

With a little bit help from @Toflar (thanks a lot dude!) i`ve found a solution for core development for me. Is contao/core the right place for this ticket? Imho it should be placed to the core-bundle repo.