Search the Community
Showing results for tags 'Fieldset'.
Found 4 results
-
Hello, for a project I have pages with different “content areas“ that can be edited only by specific user roles. In the past I setup a fieldset (tab) containing all the fields that should be available to only one specific group of users and set the fields' view and edit permissions (in the Access tab) accordingly. The result was as expected: Users assigned to the specific role could see the tab, click on it, edit content, users without the role could not see the tab. After updating this installation to 3.0.148 yesterday I wanted to setup another tab following the same principle, but I have no "Access" tab for the fieldset to limit access to the specific role. I even tried cloning an existing (and still working) fieldset. The existing fieldset has some template overrides (screenshot attached) that lead to the desired behaviour, but I am not able to reproduce these settings because there is not "Access" tab for my fieldset in template context either. Is this a bug in 3.0.148? Has the fieldset fieldtype changed? Am I missing anything here? I am glad to hear from you guys. Cheers, Flo
-
Hi All, perhaps I'm missing something obvious, but I've been working with the Fieldset a while now (and loving the combination with repeater-fields ), but yesterday I stumbled upon the following; When creating a fieldset, ProcessWire automatically generates and _END field as well, right? As I wanted to have to fieldsets in tabs, but with similar content, I decided to clone the fieldset. Doing so DID create a new fieldset, but NOT an additional fieldset_END for this fieldset. Additionally , it looks like the cloned fieldset is also linked to the previously created fieldset_END of the initially created one. Practical example (my steps in this case): Make fieldset four_columns ProcessWire generates four_columns_END Clone four_columns fieldset, as three_columns (currently) DONE! Leaves me with four_columns, four_columns_END and three_columns (but no three_columns_END) Is there another way I should go about doing this? Or am I missing some setting? Or is this something in ProcessWire? Looking forward to see reactions! Cheers all!
-
I have a fieldsettab I want to populate with two collapsable fields that are for display not input. One will display data directly from an extra MySQL table (corresponding with PW pages) and the other will list certain PW pages. How do I go about this? I wanted to lay them out using Dynatable, one per each field. Thanks.
-
Would be great to see a new form of field-grouping in the template setup, one that conceals the inner workings of open and close fieldsets. The field nesting could use a UI similar to page listings where a field can sit under (indented below, draggable) a fieldgroup. Basically, this would make it idiot-proof. This comes out of an upgrade from 2.3 to 2.5. I was confused as all my fieldgroup tabs either broke (wouldn't open) or didn't display during page editing. It turns out that when I set up the site (originally 2.2), I was a little obsessive about keeping the field-names snake_case. I came up with an alternative convention to the groupname/groupname_END because it didn't look right to my eyes. I know, I know.. but it worked from 2.2 to 2.3. It took a while to track down what was going down. But the _END convention became enforced somewhere between 2.4 and 2.5. While I'm certainly a edge case, the convention can cause strange behavior as there's no way to know of the constraint until something goes wrong. Concealing the formbuilding mechanics would both eliminate the potential for misconfiguration and make field grouping more intiutive. *********************** Edit 9/26: I think my initial post was confusing. After using the new default admin in 2.5, the indented presentation already exists. I hadn't seen that before writing the above, which I think contributed to a poor presentation of my case. Were I to boil down the suggestion to its core, it's that the underpinnings of the FieldsetTabOpen are being surfaced unnecessarilly in the admin. The site administrator doesn't need to know of the <fieldgroup>_END. Better to conceal it from the front-end, or remove it altogether.
