8.4.0 attribute sets get installed under one category instead of each in its own

Permalink
I'm trying to install 2 sets in 2 attribute categories each in its own. But what I find is that only the very first set is installed under the specified correct category, all other sets get installed under the same first category. If I swap the categories order in code, the same happens. Something's weird happening. Anyone noticed that?

So for example I want a Car Options set under a Car category, and a Location Options set under a Location category. What happens is that both the Car Options and Location Options get installed under the Car category, the Location category is empty.

Then I can find my car options attribute in the Car Options set in the Car category AND the Location Options set in the same Car category but without the location options attribute - I can't find it anywhere. See pics attached.

Why do they both get installed under the same category?

See the attached code. And if I swap the order of saving the sets to save location first and then car, it does the same thing but now the Location category has both sets and the Car is empty.

4 Attachments

 
linuxoid replied on at Permalink Reply
linuxoid
I tried with loading a content.xml during install and it really does that - it installs 2 attributes belonging to different sets and categories into the same set:
<?xml version="1.0" encoding="UTF-8"?>
<concrete5-cif version="1.0">
    <attributecategories>
        <category package="my_package" handle="car" name="Car" allow-sets="1" ></category>
        <category package="my_package" handle="location" name="Location" allow-sets="1" ></category>
    </attributecategories>
    <attributekeys>
        <attributekey handle="gear_box" name="Gear Box" package="my_package" searchable="1" indexed="1" type="select" category="car">
            <type allow-multiple-values="0" display-order="asc">
                <options>
                    <option value="Manual" ></option>
                    <option value="Auto" ></option>
                </options>
            </type>
        </attributekey>

Is this a bug or what's wrong with the code or xml?

Another thought - could it be that once I had the attributes installed incorrectly (I've installed and reinstalled the package million times during debugging), they remain incorrectly assigned in the database even after uninstalling the package and clearing cache? So even if I made changes they don't have any effect as the old versions in the DB don't get overridden.

Thank you.
linuxoid replied on at Permalink Reply
linuxoid
Re. "Another thought" - nope, tried on a fresh install - same thing, 2 attributes in the same set