Module installation: Fieldset Tabs

[aComAdi]

Hi,

We are currently developing several modules for our client base which will help us scale production of sites with Processwire. All is going well so far with great information around. But now we came across an issue, which we are stuck with.

One modules installs several fields (successfully), which we want to organize into Fieldset Tabs. And that's where we're currently stuck. Despite trying our own methods and searching in existing modules for references.

Here the field creation code during the module install:

  public static $fieldsArray = array(
			'strasse' => array('name'=>'WebKitEinstellungenStrasse', 'type'=>'FieldtypeText', 'label'=>'Strasse', 'columnwidth'=>50,'collapsed'=>0),
      'plz' => array('name'=>'WebKitEinstellungenPLZ', 'type'=>'FieldtypeText', 'label'=>'Postleitzahl', 'columnwidth'=>15,'collapsed'=>0),
      'ort' => array('name'=>'WebKitEinstellungenOrt', 'type'=>'FieldtypeText', 'label'=>'Ort', 'columnwidth'=>35,'collapsed'=>0),
      'tel1' => array('name'=>'WebKitEinstellungenTelefonnummer1', 'type'=>'FieldtypeText', 'label'=>'Telefonnummer', 'columnwidth'=>50,'collapsed'=>0),
      'tel2' => array('name'=>'WebKitEinstellungenTelefonnummer2', 'type'=>'FieldtypeText', 'label'=>'Telefonnummer 2', 'columnwidth'=>50,'collapsed'=>0),
      'email1' => array('name'=>'WebKitEinstellungenEmail1', 'type'=>'FieldtypeText', 'label'=>'E-Mailadresse', 'columnwidth'=>50,'collapsed'=>0),
      'email2' => array('name'=>'WebKitEinstellungenEmail2', 'type'=>'FieldtypeText', 'label'=>'E-Mailadresse 2', 'columnwidth'=>50,'collapsed'=>0),
      'garagenid' => array('name'=>'WebKitEinstellungenGaragenId', 'type'=>'FieldtypeText', 'label'=>'a-Commerce Nummer', 'columnwidth'=>50,'collapsed'=>0,'description'=>'Benötigt für Fahrzeugmodule. Nur unter Anweisung löschen oder ändern.'),
      'fb' => array('name'=>'WebKitEinstellungenFacebook', 'type'=>'FieldtypeText', 'label'=>'Facebook Page URL', 'columnwidth'=>50,'collapsed'=>0),
      'insta' => array('name'=>'WebKitEinstellungenInstagram', 'type'=>'FieldtypeText', 'label'=>'Instagramm URL', 'columnwidth'=>50,'collapsed'=>0),
      'yt' => array('name'=>'WebKitEinstellungenYouTube', 'type'=>'FieldtypeText', 'label'=>'YouTube URL', 'columnwidth'=>50,'collapsed'=>0),
      'footertext' => array('name'=>'WebKitEinstellungenFooterText', 'type'=>'FieldtypeTextarea', 'label'=>'Footer Text', 'columnwidth'=>50,'collapsed'=>0),
      'bildertabopen' => array('name'=>'WebKitEinstellungenBilderTabOpen', 'type'=>'FieldtypeFieldsetTabOpen', 'label'=>'Standardbilder','collapsed'=>0,'modal'=>''),
      'bilderheader' => array('name'=>'WebKitEinstellungenStandardbilderHeader', 'type'=>'FieldtypeImage', 'label'=>'Standardbild Page Header', 'columnwidth'=>50,'collapsed'=>0,'description'=>'Verwendet, falls bei einer Seite kein spezifisches Kopfbild definiert wird.','entityencodedesc'=>1,'extensions'=>'gif jpg jpeg png','adminThumbs'=>1),
      'bildernews' => array('name'=>'WebKitEinstellungenStandardbilderNews', 'type'=>'FieldtypeImage', 'label'=>'Standardbild Neuigkeit', 'columnwidth'=>50,'collapsed'=>0,'description'=>'Verwendet, falls bei einem Newseintrag kein spezifisches Kopfbild definiert wird.','entityencodedesc'=>1,'extensions'=>'gif jpg jpeg png','adminThumbs'=>1),
      'bilderfzg' => array('name'=>'WebKitEinstellungenStandardbilderFahrzeuge', 'type'=>'FieldtypeImage', 'label'=>'Standardbild Fahrzeug', 'columnwidth'=>50,'collapsed'=>0,'description'=>'Verwendet, falls ein Fahrzeug kein Bild hat.','entityencodedesc'=>1,'extensions'=>'gif jpg jpeg png','adminThumbs'=>1),
      'bildertabclose' => array('name'=>'WebKitEinstellungenBilderTabClose', 'type'=>'FieldtypeFieldsetClose', 'label'=>'Standardbilder Tab Geschlossen','collapsed'=>0,'modal'=>''),
      'googlega' => array('name'=>'WebKitEinstellungenGoogleGA', 'type'=>'FieldtypeText', 'label'=>'Google Analytics Konto', 'columnwidth'=>50,'collapsed'=>0,'description'=>'Beispiel: UA-123456-78'),
      'googlemaps' => array('name'=>'WebKitEinstellungenGoogleMaps', 'type'=>'FieldtypeTextarea', 'label'=>'Google Maps Code', 'columnwidth'=>50,'collapsed'=>0),
		);

private function installFields($templateId){
      // Get Fieldgroup
      $t = $this->wire('templates')->get($templateId);
      $fg = $this->wire('fieldgroups')->get($t->fieldgroup);

      // Felder hinzufügen
      foreach(static::$fieldsArray as $feld) {
        if(!$this->fields->get($feld['name'])){
          $f = new Field();
          $f->type = $this->modules->get($feld['type']);
          $f->name = $feld['name'];
          $f->label = $feld['label'];
          if (isset($feld['columnwidth'])) $f->columnwidth = $feld['columnwidth'];
          $f->collapsed = $feld['collapsed'];
          if (isset($feld['description'])) $f->description = $feld['description'];
          if (isset($feld['extensions'])) $f->extensions = $feld['extensions'];
          if (isset($feld['adminThumbs'])) $f->adminThumbs = $feld['adminThumbs'];
          if (isset($feld['modal'])) $f->modal = $feld['modal'];
          $f->save(); //
          // Feld zur Feldgruppe hinzufügen
          $fg->add($f);
        }

      }
      // Feldgruppe speichern
      $fg->save();
      return $fg;

This adds the tab 'WebKitEinstellungenBilderTabOpen' which is also visible in the template and page. The fields within the open and close tab fields are missing in the basic tab and nothing happens on click on WebKitEinstellungenBilderTabOpen.

Using the Field Exporter we realized that the openFieldID, closeFieldID values were missing. So, after not finding direct references, we did some, uhm, creative workaround by looping through a field tab definition array

public static $tabsArray = array(
      'bildertabopen' => array('name'=>'WebKitEinstellungenBilderTabOpen', 'type'=>'FieldtypeFieldsetTabOpen','tabref'=>'WebKitEinstellungenBilderTabClose'),
      'bildertabclose' => array('name'=>'WebKitEinstellungenBilderTabClose','type'=>'FieldtypeFieldsetClose','tabref'=>'WebKitEinstellungenBilderTabOpen'),
    );

// Tabgruppen zuweisen
      foreach(static::$tabsArray as $feld) {
        // Feld in Processwire beziehen
        if($tab = $this->fields->get($feld['name'])){
          // Referenz Tab laden
          if($tabref = $this->fields->get($feld['tabref'])){
            // Referenz schreiben
            if($feld['type'] == 'FieldtypeFieldsetTabOpen') {
              $tab->closeFieldID = $tabref->id;
              $tab->save();
            } else {
              $tab->openFieldID = $tabref->id;
              $tab->save();
            }
          }
        }
      }

This works as far as the setting of the openFieldID, closeFieldId is concerned:

{
    "WebKitEinstellungenBilderTabOpen": {
        "id": 521,
        "type": "FieldtypeFieldsetTabOpen",
        "flags": 0,
        "name": "WebKitEinstellungenBilderTabOpen",
        "label": "Standardbilder",
        "closeFieldID": 525,
        "modal": "",
        "collapsed": 0
    }
}

{
    "WebKitEinstellungenBilderTabClose": {
        "id": 525,
        "type": "FieldtypeFieldsetClose",
        "flags": 0,
        "name": "WebKitEinstellungenBilderTabClose",
        "label": "Standardbilder Tab Geschlossen",
        "openFieldID": 521
    }
}

But in the Admin, the field are still not grouped into the tab.

Now we're stuck and hope someone can help us.

Here some screenshots:

 

 

[bernhard]

Did you have a look at RockMigrations? Seems that we are having similar goals... And I've added Fieldset support lately - maybe you can get some inspiration there:

https://github.com/BernhardBaumrock/RockMigrations/commit/8417b2b33422e741eeb7f84a5320c249b73d18c9

[aComAdi]

Hi Bernhard,

I have migrated what we had so far to RockMigrations. I like the approach for the same reasons you do.

I have three issues/questions.

1. FieldtypeOptions

Does RockMigrations support this field type fully? Adding the field itself is obviously easy. I did not manage to pass the selectable options on to the field though. If it does support it, I would appreciate a code example.

2. Viewable Templates

We intend to install viewable templates, either as shells containing functionality only or as full HTML layouts. As far as I can tell, RockMigrations does not support this. We started in our standalone module by providing the file in an asset folder of the module and copying it into the templates folder after creating the tempalte:

if($t->id) {
          $src = __DIR__ . "/assets/WebKitModelleAuto.php";
          $dest = $this->removeLastDir(__DIR__,2) . "/templates/webkitModelleAuto.php";
          $copy = copy($src, $dest);
          return $t->id;
        }

Obviously we can still do it this way if nothing like this is planned in future versions of RockMigrations

3. Module Version

It's fully possible, that I did something wrong...but the module version numbers are not updating after migrations. Both these modules have been migrated successfully to versions 0.1.0.

We created a shell module based on yours:

https://github.com/BernhardBaumrock/RockMigrationsDemo/archive/master.zip

If it is a 'bug' then it would be great to update it as this may be somewhat confusing to staff less familiar with migrations but tasked to upgrade modules (which will be the case in our situation). A luxury update would be, if the RockModuleCreator would also let the user set the summary of the module. But...luxury.

Anyway, I hope you don't feel that I am trashing your work. I think it's great. It's just situations I came across during evaluation. Some might be my own inexperience with ProcessWire syntax. It's a great module.

[bernhard]

44 minutes ago, aComAdi said:

Does RockMigrations support this field type fully? Adding the field itself is obviously easy. I did not manage to pass the selectable options on to the field though. If it does support it, I would appreciate a code example.

Yes, it does. Intellisense helps a lot working with RockMigrations:

48 minutes ago, aComAdi said:

We intend to install viewable templates, either as shells containing functionality only or as full HTML layouts. As far as I can tell, RockMigrations does not support this. We started in our standalone module by providing the file in an asset folder of the module and copying it into the templates folder after creating the tempalte:

if($t->id) {
          $src = __DIR__ . "/assets/WebKitModelleAuto.php";
          $dest = $this->removeLastDir(__DIR__,2) . "/templates/webkitModelleAuto.php";
          $copy = copy($src, $dest);
          return $t->id;
        }

Obviously we can still do it this way if nothing like this is planned in future versions of RockMigrations

Hm... I don't understand why that would be helpful. RockMigrations was built for all non-code-related stuff. Meaning everything that's going on in the database. Everything else is in my case under control of GIT. So the idea is to create a new template php file in my dev environment, then create the new fields in a rockmigration, push everything to git, pull it to the live server, refresh the modules cache and everything is done. Does that make sense? Why would you need your approach?

51 minutes ago, aComAdi said:

It's fully possible, that I did something wrong...but the module version numbers are not updating after migrations. Both these modules have been migrated successfully to versions 0.1.0.

How did you do that? I don't understand. The module should show the version that is defined in it's module config and that has nothing to do with RockMigrations ? 

[aComAdi]

12 hours ago, bernhard said:

Yes, it does. Intellisense helps a lot working with RockMigrations: 

Thanks.
(Can't get it to run with my Atom installation.)

12 hours ago, bernhard said:

Why would you need your approach?

Because we are a team of eleven and only three of us are devs. The idea is, that we can prepare PW modules for our various client types based on our 20 years of exprience in this particlular industry. After selling, a non-dev PM can select the required modules, install them and essentially have a working site. Al that needs to be done at this point is some templating.

Never mind. We'll work around it or write our own extension to RockMigrations.

12 hours ago, bernhard said:

The module should show the version that is defined in it's module config and that has nothing to do with RockMigrations

We will definitely extend this. Again: non-dev's invovled. They need to see on the modules page which version is currently installed without having to dig in the files.

Thanks for your help. All we need to work out now is testing a FieldTypeRepeaterMatrix and we'r good to go.

[bernhard]

1 hour ago, aComAdi said:

Never mind. We'll work around it or write our own extension to RockMigrations.

I'm happy to accept PRs ?

1 hour ago, aComAdi said:

We will definitely extend this. Again: non-dev's invovled. They need to see on the modules page which version is currently installed without having to dig in the files.

I'd like to have a dashboard for RockMigrations that makes it easy to see which Migrations where run when, which versions are currently installed etc., but I have not enough time for that at the moment and it could be a lot easier when RockTabulator is ready ?