Leaderboard

As i mentioned before; I started my own e-commerce project and had to say i was afraid at beginning. This is my first OOP project, so i spent some time to find my way. But i am very happy when i see my progress and the results step by step... It will surely not as future rich as Padloper but my clients do not use many futures anyway. Mainly the general things.... Hope to present my first Ecommerce project on PW here soon....

A FieldsetPage field is a kind of Repeater, and conditionally setting the required status of inputfields within a Repeater is difficult. AFAIK you can't do this from a ProcessPageEdit::buildForm hook. And what's worse is that you'd need to hook one method to conditionally show the required asterisk in Page Edit and a different method to actually enforce the required status when the input is processed for each inputfield type within the FieldsetPage. So you'd end up needing to apply your logic in three different places. Long story short, you'll make things much simpler if you have Profields and can change your FieldsetPage to a FieldsetGroup, or failing that a standard Fieldset.

The naming convention is actually the page ID, so 1234 in your example is the page whose id is 1234.

Only if you use Option D for front-end editing in a dialog. Hanna Code Dialog works by hooking ProcessPageEdit::execute and this method isn't called when using inline front-end editing. PageFrontEdit doesn't even have any hookable methods so there's really no scope for the kind of customisation done by Hanna Code Dialog.

Didn't want to imply your module needs anything or that it is "missing" something or that I was asking for a feature, I apologize if that's how it came out! Just wanted to give an example of an exception to the norm in case anyone finds this thread and of course, I agree it's the mission of all of us to contribute to open source and I must say this community has inspired me a lot to thrive into that direction rather than just consuming the work of others but also contributing, first step is to solve the very serious personal time management issues I have and just force me to do get open source done lol. So basically how it's useful for me is that, I keep a bunch of sites on one server and they all share template files and fields configuration. I keep files in sync using git and git worktrees, and with a shell script I make merges from the dev branch into the rest of the branches, including the migration files (each site is a branch). Then, if I need to make an update that involves any adding/removing fields I also have another shell script that goes on every site directory and runs a specific migration. It saves me a lot of time to run this for the 50+ sites I manage, I can very easily see if an error occurred, if migration was already run, if it didn't exist (then it means that site is now correctly wired up to the git repo), etc. Probably this is the least likely scenario of most PW users lol, as I have the feeling that most of PW users build heavily customized sites, for very specific requirements.

Good day, @Robin S! I've just read through the whole forum thread and found out a lot of great things about this module. It is great and way more powerful than I could imagine! But the issue I was hoping to resolve wasn't there. I am trying to use the module in a frontend-edit context, but it doesn't seem to work. The Insert Hanna Code button isn't even in the toolbox. What am I doing wrong? Can I make it work here?

Please check PM. Thanks.

Thank you for you insightful reply @Robin S! I've decided to step away from the FieldstePage method, and just creating simple fields with longer names. Takes some time to copy over all existing data, but it makes it all a lot simpler to deal with.

Love the way @bernhard has integrated PW selectors/way-of-doing-things in RF3. The doco is really good too. Got the basics no problem. I'm sure I'll figure it out eventually but any tips welcome for this scenario: Client hires out equipment and needs to know 'last and next booking date' for an item and ensure that new bookings don't clash. Simplified template structure is: Booking with: - Event date(s) - Booking items (repeater field) that calls on a list (page reference field) of bookable items Report needs to show (filterable): Item (multiple defined template names) Last booking date Next booking date = availability for a given proposed booking event date Any pointers on how I can achieve this RF3?

Guess you’ll want to hook FormBuilderProcessor::savePageDone if FormBuilder hasn’t changed since the beta versions. #24 is the latest one I could dig up, personally. That’s from 2014. But like I said, these are questions for the FormBuilder forum.

I've added support for an "integer" inputfield type in v0.3.3. Technically it was already supported via a HannaCodeDialog::buildForm hook which is the approach I would generally recommend to power users. Once you start going beyond the basics I think it's easier and more powerful to build your dialog forms via that hook.

Right now only the default values can be overwritten via language translation files. But good hint - I'll add multi-language support for the config fields as well.

Yes, the legal situation in Germany / Europe is getting harder. I'm also still struggling with a good solution. Our wordpress developer uses https://borlabs.io/ which is a quite complete solution for cookie management (and external scripts / media blocker). Thanks for the links to klaro & oil.js - both are looking really promising. I'll definetely take a deeper look. I'm still behind my updates of the fork but was thinking about extending the features (as our german customers are asking for features as choosing the cookie groups, blocking external scripts, if not opted in ...). Maybe it'll also be a complete rewrite, as the intended use changes. Edit: My current draft work of a rewrite you'll find here: https://github.com/blaueQuelle/privacywire/tree/dev

v0.2.1 released. This is a fairly major update in that there has been quite a bit of refactoring. Please be alert for and report any issues. ProcessWire >= v3.0.0 is now required. This release adds a new hookable HannaCodeDialog::buildForm() method that lets you build the dialog form in the hook rather than setting inputfield options as pseudo-attributes in the Hanna Code tag settings. From the readme... Build entire dialog form in a hook You can hook after HannaCodeDialog::buildForm to add inputfields to the dialog form. You can define options for the inputfields when you add them. Using a hook like this can be useful if you prefer to configure inputfield type/options/descriptions/notes in your IDE rather than as extra attributes in the Hanna tag settings. It's also useful if you want to use inputfield settings such as showIf. When you add the inputfields you must set both the name and the id of the inputfield to match the attribute name. You only need to set an inputfield value in the hook if you want to force the value - otherwise the current values from the tag are automatically applied. To use this hook you only have to define the essential attributes (the "fields" for the tag) in the Hanna Code settings and then all the other inputfield settings can be set in the hook. Example buildForm() hook The Hanna Code attributes defined for tag "meal" (a default value is defined for "vegetables"): vegetables=Carrot meat cooking_style comments The hook code in /site/ready.php: $wire->addHookAfter('HannaCodeDialog::buildForm', function(HookEvent $event) { // The Hanna tag that is being opened in the dialog $tag_name = $event->arguments(0); // Other arguments if you need them /* @var Page $edited_page */ $edited_page = $event->arguments(1); // The page open in Page Edit $current_attributes = $event->arguments(2); // The current attribute values $default_attributes = $event->arguments(3); // The default attribute values // The form rendered in the dialog /* @var InputfieldForm $form */ $form = $event->return; if($tag_name === 'meal') { $modules = $event->wire('modules'); /* @var InputfieldCheckboxes $f */ $f = $modules->InputfieldCheckboxes; $f->name = 'vegetables'; // Set name to match attribute $f->id = 'vegetables'; // Set id to match attribute $f->label = 'Vegetables'; $f->description = 'Please select some vegetables.'; $f->notes = "If you don't eat your vegetables you can't have any pudding."; $f->addOptions(['Carrot', 'Cabbage', 'Celery'], false); $form->add($f); /* @var InputfieldRadios $f */ $f = $modules->InputfieldRadios; $f->name = 'meat'; $f->id = 'meat'; $f->label = 'Meat'; $f->addOptions(['Pork', 'Beef', 'Chicken', 'Lamb'], false); $form->add($f); /* @var InputfieldSelect $f */ $f = $modules->InputfieldSelect; $f->name = 'cooking_style'; $f->id = 'cooking_style'; $f->label = 'How would you like it cooked?'; $f->addOptions(['Fried', 'Boiled', 'Baked'], false); $form->add($f); /* @var InputfieldText $f */ $f = $modules->InputfieldText; $f->name = 'comments'; $f->id = 'comments'; $f->label = 'Comments for the chef'; $f->showIf = 'cooking_style=Fried'; $form->add($f); } });

As per my previous reply and the module readme there are config options for dialog width and height. Or maybe I don't understand your question.

Holy shit! That was fast. Thank you very much, Robin!

I've added support for CKEditor within a Table field in v0.1.10.

@adrian, I just pushed another update in v0.1.5 that will allow the dropdown label in the toolbar to adapt its width to the length of the text (in the case that it is translated).

You would need to install the LanguageSupport module but I don't think there's any inefficiency in doing that. You don't need to actually create any additional languages - you just edit the default language to override whatever strings you want. I believe that's the standard PW way for customising strings so I wouldn't want to reinvent the wheel and create configurable fields for every string.

To my way of thinking, numeric IDs are the worst case in terms of being editor friendly. I see HannaCodeDialog as being a kind of progressive enhancement of Hanna Code, such that in the future you could uninstall HannaCodeDialog and still have tags that an editor can understand and use. But with numeric IDs you'll have tags along the lines of... [[my_tag file="34784" options="4745|9748|8985"]] And that seems contrary to the whole idea of Hanna Code, which is about giving editors easy to understand options while you the developer do the heavy lifting (be it matching editor-friendly names to IDs or whatever) behind the scenes in the tag code. Having said that, I'd like the module to be flexible and let devs decide for themselves how they want to use it. So happy to announce... HannaCodeDialog v0.1.2 Inserting a tag from the dropdown no longer opens the dialog if the tag has no editable options. A new method prepareOptions() can be hooked in order to define or manipulate the options that can be selected for a tag attribute. See the module readme for more. @LMD, you can hook this new method to set separate value and label as per your proposal: $wire->addHookAfter('HannaCodeDialog::prepareOptions', function($event) { $options = $event->return; $new_options = array(); foreach($options as $option) { if(strpos($option, '@@') !== false) { list($value, $label) = explode('@@', $option); $new_options[$value] = $label; } else { $new_options[$option] = $option; } } $event->return = $new_options; });

Can't you just make a regular fieldset tab and put them in there, i have sometimes 2-3 content tabs, and there is no reason to make a module. also on that example posted, the solution provided is only for outputting markup, like some instructions, or like a training video etc. AFAIK you cannot add a tab to page edit and expect those fields to automagically save to the database b/c the fields need to exist in the database to save to.

Got it. It's working great!

@thetuningspoon, I just pushed another small change in v0.1.1 to remove any manual line breaks that a user might insert inside a textarea. Manual line breaks cannot be supported because they break the CKEditor tag widget.

I had thought it would be nicer if the module decided automatically based on the length of the attribute value you give it, but now that you mention this I can see that my idea won't work very well when inserting a new tag, where the length will be zero until it is populated. So in v0.0.9 I have removed that breakpoint idea and now you can manually specify the textarea inputfield type for an attribute, e.g. myattribute__type=textarea

@Robin S Great, I'll try it out. Does this also mean that textareas are a configurable input type now? That was a feature I was going to request.

@thetuningspoon, thanks, I couldn't reproduce the issue exactly as you're seeing it but I think I have found the source of the problem. For some reason I didn't anticipate using long strings of text for attribute values. So I've added support for that in v0.0.8 and now if the length of a value is greater than 50 characters a textarea is used in the dialog instead of a text input. The breakpoint at which a textarea is used is configurable in the module settings. Please let me know if this doesn't fix the issue for you.

The close button is working now, but opening an existing code now shows a completely blank iframe in the popup. PW version is 3.0.40. Hanna code is 0.2.0 Edit: No console errors, either.

That's a bug, sorry. I missed something in the JS in a recent update. Should be fixed now in v0.0.7. Yes, the module should work for existing Hanna codes. I can't reproduce that issue here. If the v0.0.7 update doesn't fix things for you could you give me some more info: any JS console errors, the PW version, TextformatterHannaCode version, and an export of a Hanna code that you see the issue with? Edit: also please let me know how the Hanna tag looks in your CKEditor field - i.e. are the attribute values inside quotes, single or double?

Well it wasn't something I tested for specifically, but it was pretty easy to add support for ProFields Textareas so I have done that in v0.0.6.

In v0.0.2 I have added a hookable method that supplies the array of tag names for the dropdown menu. You can use an 'after' hook to control what appears in the dropdown. A couple of examples... Define the tags for a given template: $this->addHookAfter('HannaCodeDialog::getDropdownTags', function($event) { $page = $event->arguments('page'); // Show only these tags on pages using the 'basic_page' template if($page->template == 'basic_page') { $event->return = ['some_tag', 'another_tag']; } }); Remove certain tags for a given template: $this->addHookAfter('HannaCodeDialog::getDropdownTags', function($event) { $page = $event->arguments('page'); $tags = $event->return; // Remove these tags on pages using the 'basic_page' template if($page->template == 'basic_page') { $filtered_tags = array_filter($tags, function($tag) { return !in_array($tag, ['some_tag', 'another_tag']); }); $event->return = array_values($filtered_tags); } });

Because i really wanna use the Menu Builder, a friend of mine helped me to build a working solution. ​ We're using the above mentioned solution from @Webrocker as a basis. Maybe it's helpful for others who wanna use the Menu Builder and the UIKit Navbar and so i post the code here: <nav class="uk-navbar"> <?php $mainmenu_items_json = $pages->get('name=main-menu')->menu_items; // this is the menu page in menu builder, could also be fetched with the ID $mainmenu_items = json_decode($mainmenu_items_json, true); if( count($mainmenu_items) > 0 ){ $out = '<ul class="uk-navbar-nav">'; foreach($mainmenu_items as $id => $item){ $isCurrentPage = ($item['pages_id'] == $page->id || ($page->parent_id != 1 && $item['pages_id'] == $page->parent_id)); $subs = false; if(!isset($item['parent_id'])) { $url = ($item['url']) ? $item['url'] : $pages->get($item['pages_id'])->url; $target = (1 == $item['newtab']) ? 'target="_blank"':''; foreach($mainmenu_items as $sub_id => $sub_item){ if(isset($sub_item['parent_id']) && $sub_item['parent_id'] == $id) { $subs = true; break; } } $class = 'class="'.($subs ? 'uk-parent ' : '').($isCurrentPage ? 'current uk-active' : '').'"'; $out .= '<li '.$class.($subs ? ' data-uk-dropdown="" aria-haspopup="true" aria-expanded="'.($isCurrentPage ? 'true' : 'false').'"' : '').'><a href="' . $url . '" class="" ' . $target . '>' . $item['title'] . '</a>'; if($subs) { $out .= '<div class="uk-dropdown uk-dropdown-navbar uk-dropdown-bottom"><ul class="uk-nav uk-nav-navbar">'; } foreach($mainmenu_items as $sub_id => $sub_item){ if(isset($sub_item['parent_id']) && $sub_item['parent_id'] == $id) { $url = ($sub_item['url']) ? $sub_item['url'] : $pages->get($sub_item['pages_id'])->url; $target = (1 == $sub_item['newtab']) ? 'target="_blank"':''; $out .= '<li><a href="'.$url.'" class="'.$target.'">'.$sub_item['title'].'</a></li>'; } } if($subs) { $out .= '</ul></div>'; } $out .= '</li>'; } } $out .= '</ul>'; echo $out; } ?> </nav> It's like @Webrocker says: The best of both worlds! And as a side note: My friend didn't know anything about PW before. After 15 min. he had that solution ready. I think that says everything about the flexibility and the possibilities of PW. Thanks for that CMS and the really great community here! Mario

Hello, and welcome to what I though was either my client being silly and changing things, or some evil doer. Turns out its reproducible and therefore something in Proceswire (I checked my templates and modules but couldnt find anything that would be doing this...). So what is it doing? Check out the video for evidence. A repeater field is interacting with a page template and another repeater field somehow to swap the fields in the template and repeater over... I have a template called team, and a repeater field called team_repeater with label Team. Some how and for some reason, when I change my fields on repeater called main_menu_links my team template gets those fields and when I try and revert the team template fields to the fields it should have, they get given to the repeater main_menu_links. Also this to say HELP!!!!! video: https://www.dropbox.com/s/exkdhc6n7x0xpsa/strange-repeater-PW-mega-bug.mov?dl=0