Dropzones Showing Up When They Shouldn't?

Ok, I now have the reverse problem having had this issue fixed. :slightly_smiling_face:

I am using @commands to determine what should be displayed in the Editor and Node Browser list. It seems that checking for Edit is being honoured but not other variables being true | false? :thinking:

There should only be one dropzone shown (Format A Dropzone -1) in this case but there are another eight listed in the node browser that shouldn’t be. The Editor is behaving itself and only showing one.

Here is a section of code that determines what should be shown / used:

@if(format_c_other)
  @if(edit)
    @if(!hideFormatC2)
      <!--- <P>FORMAT C - EDITOR</P>  -->
      @dropzone("format_c_other", title: "Format C Dropzone - 17")
    @endif
  @else
    <!--- <P>FORMAT C</P>  -->
    @dropzone("format_c_other", title: "Format C Dropzone - 18")
  @endif
@endif

The variable format_c_other is false.

I have just added the numbers (e.g. 17) to the dropzone titles to aid debugging.

The existing files I sent you should show this happening as I haven’t changed the code. :slightly_smiling_face:

Hey @logrunner,

I noticed this when I was fixing the dropzone issue and had a feeling you may report it. It’s relatively easy to conditionally show dropzones in the editor, however, this is not the case for the node browser - and arguably nodes in the browser shouldn’t be hidden. It would be tricky when trying to locate a specific component, having to toggle settings to change its visibility.

The good news is that I think we can solve your problem and simplify your code at the same time. A general rule of thumb is to keep the template files as simple as possible, moving complex logic to the hooks file - it’s a lot easier to maintain there.

Something else to note about the dropzones, the first parameter is the unique name for the dropzone. It helps to think of it like a named bucket. It’s ok to have more than one dropzone statement point to the same bucket like you have, but care should be taken to make sure only one is rendered at a time - using conditional code. The title parameter is a friendly name to be shown in the node browser. In the case of multiple dropzones, the title used is random. To save any confusion, the titles should just match on all dropzones pointing to the same bucket.

So to simplify things, I think it would be much easier to lift out the logic to the hooks file and use a simple flag in the template to show the dropzone. So your template might have a simple show_format_c_other check like this.

@if(show_format_c_other)
    <!--- <P>FORMAT C</P>  -->
    @dropzone("format_c_other", title: "Format C Dropzone")
@endif

Then in the hooks like you can perform the conditional logic like this

rw.setProps({
    show_format_c_other: format_c_other && (rw.project.mode !== "edit" || !hideFormatC2),
    
    // Other properties
})

Let’s pull that statement apart.

Doing this tidies up the logic, the templates and eliminates the multiple dropzones from the node browser. It’ll also reduce the complexity and chance of any bugs appearing.

Hi @tpbradley

Thanks for the very detailed reply and suggestion as to how to proceed. I will try that out now and report back.

btw - I appreciate that the Titles for uniquely named dropzones should be the same. The only reason, I made them different was so that I could see what was happening when they were all dumped out in the Node Browser. So that was actually a debugging code change as such. :slight_smile:

1 Like

Hi @tpbradley

I have done the changes as you suggested to simplify the code, so the code looks more like this [snippet]:

hooks.js

show_format_c_other: format_c_other && (rw.project.mode !== "edit" || !hideFormatC2),

show_dropzones_in_editor: showDropzones  && rw.project.mode === "edit",

.
PHP code

@if(edit)
  <!------------------------- FORMAT C [OTHER] ------------------------->
@endif

@if(!edit)
  @if(format_c_other)
    <?php
    function format_c_other() {
    $format_c_other = <<<HTML
  @endif
@endif

@if(show_format_c_other)
  @if(show_dropzones_in_editor)
    <div class="bg-slate-300  border-2 border-slate-600 m-2 text-center p-2 text-3xl">FORMAT C2 [OTHER] DROPZONE</div>
    <div class="bg-slate-300 border-2 border-slate-600 m-2 p-2 w-1/3">
  @endif
  @dropzone("format_c_other", title: "Format C2 Dropzone - Other")
  @if(show_dropzones_in_editor)
    </div>
  @endif
@endif
@if(!edit)
  @if(format_c_other)
HTML;
    return $format_c_other;
    }
    ?>
  @endif
@endif

It doesn’t appear to be working as show_format_c_other is false and that dropzone is still showing in the node browser, although there are a lot less of them now, following the code changes.

Format A Dropzone - All is true and is shown in the Editor and that should be the only one shown in the Node Browser? :thinking:

@logrunner Sorry for the delay in getting back to you!

Well done on getting this solution working. I’m afraid it’s not possible to show or hide dropzones in the node browser, so I think this is working as expected. You can also see this on our menu component. All of the dropzones are visible in the node browser regardless of the settings.

@tpbradley

That’s disappointing :disappointed_face:

I misunderstood your previous answer and thought If I did the changes you suggested it would work.

It is going to be somewhat confusing to be able to drag components onto nodes that exist in the browser and aren’t shown in the Editor.

It somewhat reduces the power of the Elements language if it only half works (Editor only).

Maybe I could request this as an enhancement request, unless it is architecturally impossible to do?

It’s a tricky one because you could end up in a situation where you’ve lost a bunch of nodes on the page - you can’t find them because a dropzone is completely hidden. You’d have to go through all components on the page, toggling different settings to check each dropzone.

I think it could work if we added the ability to force show all dropzones in the node browser. And we do have a feedback mechanism from the template processor, so technically we could determine which dropzones are visible but it might take a bit of work get it in.

It’s certainly something we can look at in the future!