Jump to content

Recommended Posts

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):

  1. Make fieldset four_columns
  2. ProcessWire generates four_columns_END
  3. Clone four_columns fieldset, as three_columns
  4. (currently) DONE!
  5. 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!

Share this post


Link to post
Share on other sites

I think that it's normal behavior as fieldset and fieldset_end are separate fields, so you have to clone each of them. 

Share this post


Link to post
Share on other sites
19 hours ago, matjazp said:

Not directly related, just in case if you rename the fieldset: https://github.com/ryancramerdesign/ProcessWire/issues/1854

Thanks for the heads-up @matjazp  :) Didn't rename any yet, so good timing there!

 

19 hours ago, Zeka said:

I think that it's normal behavior as fieldset and fieldset_end are separate fields, so you have to clone each of them. 

@Zeka : that seems fair enough, wishful thinking on my part perhaps that because the _end is generated by ProcessWire on creating the fieldset, I was hoping it would also do that on cloning....laziness on my part there:-[
 

Share this post


Link to post
Share on other sites

Thank you for setting this up @BitPoet!!
I myself don't completely understand the internal processes of ProcessWire yet – but I'm happy others do and can write this up :) cheers!

Share this post


Link to post
Share on other sites

@ryan just commited my fix with a little type checking added, so the latest dev version from GitHub will behave nicely and clone _END fields to.

:)

  • Like 2

Share this post


Link to post
Share on other sites
Just now, BitPoet said:

@ryan just commited my fix with a little type checking added, so the latest dev version from GitHub will behave nicely and clone _END fields to.

:)

Awesome. Thanks for this @BitPoet :) 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By David Karich
      ProcessWire InputfieldRepeaterMatrixDuplicate
      Thanks to the great ProModule "RepeaterMatrix" I have the possibility to create complex repeater items. With it I have created a quite powerful page builder. Many different content modules, with many more possible design options. The RepeaterMatrix module supports the cloning of items, but only within the same page. Now I often have the case that very design-intensive pages and items are created. If you want to use a content module on a different page (e.g. in the same design), you have to rebuild each item manually every time.
      This module extends the commercial ProModule "RepeaterMatrix" by the function to duplicate repeater items from one page to another page. The condition is that the target field is the same matrix field from which the item is duplicated. This module is currently understood as proof of concept. There are a few limitations that need to be considered. The intention of the module is that this functionality is integrated into the core of RepeaterMatrix and does not require an extra module.
      Check out the screencast
      What the module can do
      Duplicate a repeater item from one page to another No matter how complex the item is Full support for file and image fields Multilingual support Support of Min and Max settings Live synchronization of clipboard between multiple browser tabs. Copy an item and simply switch the browser tab to the target page and you will immediately see the past button Support of multiple RepeaterMatrix fields on one page Configurable which roles and fields are excluded Duplicated items are automatically pasted to the end of the target field and set to hidden status so that changes are not directly published Automatic clipboard update when other items are picked Automatically removes old clipboard data if it is not pasted within 6 hours Delete clipboard itself by clicking the selected item again Benefit: unbelievably fast workflow and content replication What the module can't do
      Before an item can be duplicated in its current version, the source page must be saved. This means that if you make changes to an item and copy this, the old saved state will be duplicated Dynamic loading is currently not possible. Means no AJAX. When pasting, the target page is saved completely No support for nested repeater items. Currently only first level items can be duplicated. Means a repeater field in a repeater field cannot be duplicated. Workaround: simply duplicate the parent item Dynamic reloading and adding of repeater items cannot be registered. Several interfaces and events from the core are missing. The initialization occurs only once after the page load event Changelog
      1.0.4
      Bug fix: Various bug fixes and improvements in live synchronization Bug fix: Items are no longer inserted when the normal save button is clicked. Only when the past button is explicitly clicked Feature: Support of multiple repeater fields in one page Feature: Support of repeater Min/Max settings Feature: Configurable roles and fields Enhancement: Improved clipboard management Enhancement: Documentation improvement Enhancement: Corrected few typos #1 1.0.3
      Feature: Live synchronization Enhancement: Load the module only in the backend Enhancement: Documentation improvement 1.0.2
      Bug fix: Various bug fixes and improvements in JS functions Enhancement: Documentation improvement Enhancement: Corrected few typos 1.0.1
      Bug fix: Various bug fixes and improvements in the duplication process 1.0.0
      Initial release Support this module
      If this module is useful for you, I am very thankful for your small donation: Donate 5,- Euro (via PayPal – or an amount of your choice. Thank you!)
      Download this module
      > Github: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate
      > PW module directory: https://modules.processwire.com/modules/inputfield-repeater-matrix-duplicate/
    • By hellomoto
      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.
    • By Ben
      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.

    • By NooseLadder
      I have created custom tabs on some templates using FiledsetOpen/FieldsetClose fields.
      Is it possible to hide the dropdown by default as currently they open when you edit a page?
×
×
  • Create New...