Ok, I now have the reverse problem having had this issue fixed.
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?
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:
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.
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.
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.
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.
@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.
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!