Klenkes

You have to put the <tr> inside the foreach loop! Try this: <?php $countymatch = $pages->find("template=county-match-result, year={$page->id} "); ?> <tbody> <?php foreach($countymatch as $match){ ?> <tr> <td><?php echo "<a href='$match->url'> $match->title - {$match->title}</a>"; ?></td> <td> <?php if ($match->home_away->title == 'Home'){ echo $match->home_match_venue->title("<a href='{url}'>{title}</a>"); } else{ echo $match->away_match_venue; }; ?> </td> <td><?php echo $match->cheshire_points; ?></td> <td><?php echo $match->opponent_points; ?></td> <td><?php echo $match->match_result->title; ?></td> </tr> <?php } ?> </tbody> </table>

It certainly works in all my TinyMCE fields. Something else must interfere!

Solved it for now. If it happened once, it could happen again. Or maybe not. Sometimes it's not worth wondering why things happen... Thanks!

This is weird... I created a new block "Angebot" and migrated the fields through Angebot.php. Then I added a block Angebot and noticed that I can rearrange the block on the page, but the position is not saved. Sorting/moving in the PW backend is works. In the PW backend I saw that the block/page is set to hidden 😗 Although the block is visible to the guest. Since there is no TAB Settings I don't know how make it visible. A second new block "Angebot" is just fine! This means it only happened after creating the block... How can this happen? And is there a way to set it to unhide(without the API, didn't try) Did something like this happened to someone else?

Sorry @bernhard that I wasn't very clear in my explanations. @Stefanowitsch did a better job! I will check, although I had surgery on my left hand yesterday(not fun) and I am still on painkillers(still not fun) and the blood bottle and tube is hindering everything 😢(no fun at all)

That's my point! You won't find that in your code base, but in mine, and others. Bit of background here I just don't think it's a good idea to assume a certain workflow. This is why I asked for a setting. It could be 16 by default for most people, or be as a $config->remBase = 'value'; setting.

Mhh... I'm not sure I can, and step by step, oh my god... It's just that RockFrondend assumes sizing by a value of 16. Why? In my case it would be 10. I don't want to adjust all my CSS I worked out for years. I have to think about it...

I would kindly ask you @bernhard to consider making the setting for remBase a config setting. Background: Not all people use a framework like Uikit for their frontend output when it comes to CSS. I adopted a best practice from Css-Tricks(RIP 😢) a few years ago and still roll with it. Font-sizes are easier to spot You note in your CSS: html {font-size: 62.5%;}/* set scale for the document */ body {font-size:1.6rem;} /* this makes 1.6rem 16px, 2rem 20px, and so on... rem sizes are easier to read that way */ But... that doesn't play well with the fixed setting in RockFrontend.module.php (line 165) $this->remBase = 16; // default base for px-->rem conversion When working with rfGrow all values are now way to small, like 80px are calculated as 50px... In order for me to work I had to edit the value to 10. What do you think?

Thanks for the quick answer. No IDE. I am old, and too old for that 😟 Works now!

I tried to put some default settings in ready.php, like shown in the docs. When editing a block I get a Fatal Error: Uncaught TypeError: ProcessWire::{closure}(): Argument #1 ($settings) must be of type BlockSettingsArray, RockPageBuilder\BlockSettingsArray given in... The part of the ready.php $rpb = $this->wire->modules->get('RockPageBuilder'); $rpb->defaultSettings( function (BlockSettingsArray $settings, RockFieldsField $field, Block $block) { $settings->add([ 'name' => 'bg', 'label' => 'Hintergrund', 'value' => $field->input('bg', 'select', [ '1' => 'Hellgrau', '2' => 'Mittelgrau', '3' => 'Dunkelgrau', '4' => 'Farbe', '5' => 'Nur Trennzeile oben', '6' => 'Nur Trennzeile unten', '7' => 'Trennzeile oben + unten', '10' => 'Foto als Hintergrund', ]), ]); }); Full stack trace: PW 3.0.226 RPB 4.7.0 PHP 8.2

That's weird... This is $block->button_style: $block->button_style->title returns "Über uns" aka the page title, where it should be: schwarz. (Same happens to the other Select in the block $button_size) Is there a dependency for the fieldtype like for textareas? The underscore in the name? ...grasping at straws...

Hey! Seems to work fine now. RPB version ist now downgraded to 4.7.0. Is that okay?

You are absolutely correct. It works in a separate window and on the frontend with Alfred. The not working frontend I probably imagined... Okay, I can live with that. That leaves me with the other problem with selects. How to access the more speaking title of an option in my blockname.view.php: // Options: 1=blue 2=black // Outside RPB this works as expected // Inside RPB this results in the PW Pagetitle instead of blue // $block->button_style gives me only the ID $some_var = $block->button_style->title;

Hi Bernhard. No rush! I have no current project 😟 and just checking the module out. So far I like it and will use it if a fitting project comes up. Then of course I will purchase the next bigger licence.

Two fields of type TinyMCE called blocktext_text_1 and blocktext_text_2 blocktext_text_2 should inherit its settings from blocktext_text_1. Now... Editing the page under RockPageBuilderBlocks it works Editing the block in the frontend modal it works. Editing the PW page(in backend like About Us) I get a fatal error. If it helps... the migration code of blocktext_text_1 PW 3.0.226 | RPB 4.8.0

Finally I got some time to check out RockPageBuilder. I have great hopes! I got 2 fields that depend on the the state of a SELECT as radio buttons called button_linktype: The selectable options: 1=interne Seite 2=externe Website Outside of RPB I am able to do Show this field only if button_linktype=1 or button_linktype=2 to show or hide the depending field. In a RPB block this doesn't work! Neither PW backend nor frontend edit. I suspect this has something to do with the problem that I also cannot access a select option(->title) in my viewfile of a block: // 1=blue 2=black // Outside RPB this works as expected // Inside RPB this results in the PW Pagetitle instead of blue $some_var = $block->button_style->title; Tracy shows that all vars are there. It's a problem of accessing them. PW 3.0.226 | RPB 4.8.0

Oh, sorry, I must have missed that part... Unfortunately I don't know anything about the ProcessExportProfile module. Webserver and browser sometimes cache stuff in a hysterical manner. If the file is gone, it is gone! Somebody got it in the cache. I'm sorry, I am of no help 😢

This is just a warning that the memory limit is to low. The site should run fine. A client of mine has the same warning with his shared hosting and doesn‘t want to upgrade. Just check your image fields that images are resized during upload through the browser. I usually resize images to 2000px width or height, and 64Mb memory will be enough. No need to go through the installer again!

Most of the time I use Combo for settings in my MatrixFields to build sections of content. Like this: Or like that: All the fields are in one place and showif works great within Combo. Not so great if you have a dependancy in a parent field.

@fruidShort question: What fieldtype should stack_prices be?

You are executing infiniteScroll in the HEAD before you load Jquery(bottom of page)

Thank you again for this great module. It's a huge time saver. No website of mine without it! V 0.2.0 seems to work fine!

The warning banner seems to be gone now. The cut off iframe results from iframeSizer.contentWindow.min.js not being loaded by Fathom. I hope they are aware and working on it.

@CraigHave you noticed recently that Fathom inserts a warning banner if Fathom is embedded via your module? And the iframe is cut off at the bottom. Screenshot: I couldn't figure out what to do.

Don't get me wrong, but these hours would have been better spent on 74€ for a single licence of FormBuilder. No coding required. I own a DEV licence since 2016 and I never think twice about the yearly payment, not even a second! FormBuilder slogan should be: Forms made easy!