BrendonKoz

I feel bad bumping this topic, but I think some people might've missed, or misunderstood the importance of the reasoning for looking towards moving away from CKE4. The codebase of CKE version 4 will essentially be abandoned as of sometime in 2023 by the organization that maintains it. Considering the large amount of security issues that are consistently discovered in heavily used input/output handling JavaScript packages (whether due to custom add-ons or its core), and the fact that Ryan strives for a very secure system... The need to provide an alternative WYSIWYG module is evident. CKE5 seems like the least intrusive option (for users/clients). It appears as though he hopes to make it fairly seamless for site administrators and developers, but the integration changes aren't a 1:1 swap, so he'll have quite a bit to consider. It's likely that you'd still be able to use CKE4 as a module, just like you could continue using TinyMCE when it was removed from core -- as a separately installable module. If you wish to use standard textarea fields or Markdown-powered fields, there are add-ons for those too (already). You will still have choice, and that's one of the excellent things about ProcessWire. The only issue here is that Ryan wants to make sure that you and your clients have a stable, secure, and usable system. As always, you will still have control over your own system(s). ♥

I don't suppose there's any chance of getting these juicy forum board solutions added to related module documentation as Examples, could we? These are great starting points to common scenarios! The downside would be maintaining them for compatibility, but perhaps explicit notices with dates that the examples were created? So often I end up searching the website for answers to questions, but they're all over the place - the blog, documentation, api, forum (and not always the module forum). 😉 Just a thought. That said, loving these examples you're providing from actual client work you're doing. Thanks, Ryan!

Ah, that's more than I knew. In that case this is good for me to know about too! Thanks for that, and for your module solution!

A very nice and clean solution! Should your needs grow from this, you might enjoy one of the following options as well: Field Descriptions Extended Process Documentation

Although you can no longer signup for a new account to use the embedded Google Translate widget, you can still take advantage of it. I'll provide my solution should it be useful to anyone else. Having multiple options, depending on need, can be useful. <div id="google_translate_element"></div> <!-- Google Translate --> <script type="text/javascript"> function googleTranslateElementInit() { new google.translate.TranslateElement({pageLanguage: 'en'}, 'google_translate_element'); } </script> <script type="text/javascript" src="//translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"></script> I've used this CSS to style it from its default, while still providing the (likely) required credit to its tool. #google_translate_element .skiptranslate { visibility:collapse; text-align:center; position:absolute; width:100%; width:calc(100% - 4rem); top:0; } #google_translate_element .skiptranslate * { margin:0 auto; display:block; } #google_translate_element .skiptranslate [id*=targetLanguage] { visibility: visible; } #google_translate_element .skiptranslate [id*=targetLanguage] select { border:1px solid rgba(0,0,0,.2); background-color:#F4F6F7; color:rgba(0,0,0,.7); } #google_translate_element .skiptranslate [id*=targetLanguage] select option { background-color:transparent; } #google_translate_element [id*=targetLanguage]::after { content:'Powered by Google Translate'; display:block; text-align:center; line-height:1; color:rgba(0,0,0,.6); } @media(max-width:575px){ #google_translate_element .skiptranslate { width:calc(100% - 2rem); } }

In the InputfieldEvents.module file's ___processInput method, there's an Exception exclaiming, "This inputfield requires that you set valid 'page' and 'field' properties to it." In what instances do inputfields (or any type of module) require page and field properties? I notice that many do not require this, but am not sure of the circumstances when they are required. So far I've just been copying/pasting from similar modules without truly understanding why.

Nevermind! 😄

Going through this topic, I am hopeful the Intellisense after setting up VSCode will help me discover more in the core that's difficult to learn from external documentation. As much as I loved Atom and its graphical project viewer extension, the IDE capabilities are unfortunately problematic in my experiences. So here I am, giving VSCode another shot. Oh yes, since going through this topic, some have added extensions to their projects that VSCode has since added to the core editor, so some of you might be able to reduce the count of some of your extensions. Thanks to everyone for providing their findings (and snippets) so far! Color-coded bracket matching: Now in a core setting called Editor > Bracket Pair Colorization Renaming of matching HTML tags is part of the core via the rename ability (place cursor in/on tag name, press F2), though it currently doesn't work in PHP files (work in progress, I guess?) - alternatively, for simple matching replacements, you can double-click on the element name and press CTRL+D (or CMD+D on Mac) for automatic multi-select, then type the new tag name. These all have issues, so tag-rename or auto-rename-tag might still be preferred. Reformatting/Beautifying: SHIFT+ALT+F will automatically reformat the code of the file in focus, or currently highlighted code; also available from the right-click context menu (not yet sure how to define different formatting rules). URLs typed in the editor will be openable by default via CTRL+Click via Editor > Links. Not sure if people know, but it also offers code folding: CTRL+SHIFT+[ to fold/collapse, CTRL+SHIFT+] to unfold/open...or just use the caret symbols next to the text editor's line numbers. I think everything else (questioned raised) has been covered, or not yet able to be solved.

Thanks for the feedback, Rick! In this case, I'm planning on allowing tags on every page that contains content. Although education-related, we're a public library, so we don't actually teach per-se, but the actual content has no limit. I hadn't yet attempted implementation yet so I wasn't aware ProcessWire doesn't allow multi-word tags, but that could potentially be solved with hyphenation. I'm mostly wondering what people have come up with in terms of rules or procedures on best-case scenarios for instructing users on how to take advantage of tags. I do realize, however, that this may be dependent upon implementation, though I'm curious of first-hand scenarios of others, to maybe apply to my own. (You kind of touched on an idea with the course category subset.) 🙂 Thank you!

So, just like naming variables, trying to come up with how to properly create tags that would be understandable, usable, and not "one unique tag per every item", how do you all go about creating your tagging system(s)? Do you give access to creating tags for your customers? If so, have you come up with instructions or ways to help them satisfy their desires without overloading the website visitors with unusable overabundance of named tags? I'm reviewing a secondary site for my current employer that I have not had control over, and with free reign, there are over 800 tags on about 200 pages (and many pages don't even have any tags assigned). Some tags are full sentences. I'll obviously need to describe what a tag is to my coworkers, but even I'm having a hard time coming up with proper ideas for tags, and how best to determine what would be good and what wouldn't. (We're a library and therefore deal in education, so topics can be extremely wide-ranging on any number of subject areas.)

I had quite a bit of fun watching the intro video. It didn't really seem to (for me) add anything of value in terms of purpose or content, but it was fun - and different. If all websites started doing this I'd definitely be turned off, but in a case where it's a unique scenario and having some free time, it worked well. I'd be curious - if you're willing - to hear more about how you're handling the cookie consent to only allow scripts if/when a user allows it? It sounds like it's a fairly simple, yet robust solution, and since there are many various solutions to this, I'd be curious to hear yours (again, if you're willing to share). A well done, clean design overall! I might pop a link to this over to Jack McDade (yes, Statamic's Jack McDade) since he loves 80's/90's style designs, though his are more in the pop-fashion that SciFi, he does love everything from that decade genre.

Out of curiosity, for file/image fields, are the copied values going to point to the originating pagefile URL, or is it creating a completely new physical copy of the source items on the page where the repeater is pasted?

Wow. That's embarrassing. You are 100% correct. 🤦‍♂️ Can't believe I didn't notice that after staring at it over multiple days. Thank you!!

After your suggestion (thank you!) I did try the <!--PW-REGION-DEBUG--> tool from the primary template file (auto-append from site config), but unfortunately that seemed to render exactly what was expected: the one switch that was made indeed got switched. I made one error in my description of this problem, however: A die() statement inside the IF statement of the policy.php file does not render the content. The content is rendered if a die() statement is made within the callout.php field template, however.

I'm having a strange issue that hopefully some more seasoned PW users would have some insight on. I have enabled the Functions API, Markup Regions, and am appending a primary template file (of which I currently only have one markup region defined). All secondary major page template files insert their content into that markup region. In one particular page template file, I am attempting to render a field template ("callout.php") if it has content. For whatever reason, it is not rendering. If I insert a <?php die(); ?> within the field template, the output from the template is visible. If I move that <?php die(); ?> statement to outside the IF/ELSE block that tests whether the field has a value, the content from the field's template is no longer rendered. Oddly enough, the RepeaterMatrix field's template immediately preceeding this particular field's template is rendered. Within /site/templates/policy.php, the following excerpt (for the callout field) is the troublesome code. <?php namespace Processwire; ?> [...] <section class="main-content" id="content-skip"> <h1><?= page()->title; ?></h1> <span class="policy-status">Last updated: Month, Year</span> <section class="policy-document"> <?= page()->render('content_body'); ?> </section> <?php if (page()->callout) { page()->render('callout'); } ?> </section> Within /site/templates/fields/callout.php I have the following: <?php namespace Processwire; ?> <div class="card border-<?= $value->callout_type->value; ?> mb-3 card-note"> <div class="card-header"></div> <div class="card-body"> <div class="card-text"><?= $value->content; ?></div> </div> </div> Regardless of whether the variables are correct or not (based on the die() statements, they are), I would expect the HTML to be rendered. Like stated, if I place a <?php die(); ?> statement inside (at the end) of the callout.php template file, I can see the expected PHP/HTML get output. If I instead place it after the IF statement in the policy.php template file, the HTML output from the callout.php file does not exist. I'm not sure if it's my mixing of output methods during implementation, or something else entirely. I tried passing an $options array value to prevent caching through page()->render('callout', ['allowCache' => false]); to see if it would make a difference. It did not.

Hi Ben, This took me a bit to understand, but I think you're looking to generate an OpenGraph image similar to how GitHub's OG images appear to almost be an HTML page converted to an image? (At first I thought you just wanted to use a template to assign a specific page image and generate the meta text...) Chris Coyier at CSS-Tricks wrote up an overview of a couple different ways to produce something like this. His platform is WordPress using GD, but it could just as easily be applied to ProcessWire and IMagick. There are also services out there to help with this as well. See the comments for even more info. https://css-tricks.com/auto-generated-social-media-images/ I'm in the middle of cleaning, patching/repairing walls, and repainting my guest room after a "friend" destroyed it on me, otherwise I'd offer to get a quick example going for you over the weekend. However, your needs are likely custom to your project and there are any number of various ways to produce this, so hopefully the overview linked will give you a good head start! 🙂

I know I'm super late to this party, but since I've been away for quite some time - but absolutely love ProcessWire - and Ryan mentioned that this roadmap could extend beyond 2021, I thought this was the most appropriate place to comment. Thanks to @teppo's PW Weekly I've been able to, mostly, recount (in summarized form) multiple years of development (with plenty of tangential links, often reading the full blog posts by Ryan) both of PW and in 3rd party development efforts, so I don't feel too terribly left behind. Something a little different not yet discussed: Zooming out and looking at the bigger picture, within regards to the CMS/CMF landscape, I think an area that PW lacks is in marketing of itself, and I don't mean this as a knock on ProcessWire - the product speaks for itself and word of mouth is awesome, and marketing efforts can oftentimes detract from active development time. Marketing isn't exactly a "core feature" of the codebase, but it is something that I think can be code-adjacent. ProcessWire is capable of so, so much, but from just looking at it, or installing it from source, it's hard to see that from the eyes of a first-time user. ProcessWire doesn't use templates like WordPress, but templates are a big business with WordPress. Although some WordPress templates come bundled with custom plugins which starts skirting the line of what ProcessWire does (site profiles), there's a plethora of ready-to-go, custom designed websites with a only the simple task, after installing, of adding content. ProcessWire is more developer focused (which I personally love), but that doesn't mean we can't, or shouldn't, also cater to an audience that may want to see what designs or functionality can be made (almost) immediately available after install. As a simplistic first step here: currently Site Profiles are listed under Modules as its own category, but that's not too intuitive for findability - if this were to have its own landing page and higher level navigation, with feel good images based on the profile (for those that provide them), I think it might help to attract more potential users. On the topic of Site Profiles, since ProcessWire is capable of so much (that many of us aren't even entirely aware of), having some custom built, premium Site Profiles built as premium starter kits (kind of like what my buddy Jack McDade is doing with Statamic) it might be another boon, and additional income source. He's also considering selling branded merchandise, which I think we'd tried before and it didn't take off, but it's easy to do (via something like CafePress) and every little bit helps I suppose? On these notes, should there be - or has there been thought to - an official marketplace via the ProcessWire website for things like these (with a percentage going back to PW)? Pro Module Thoughts: 1. Search: I remember a mention of the front-end search functionality of the current version of the PW website potentially being packaged up into a Pro Module. What's the status on that? I think that - if it could be packaged into a pro module - it would be a fairly popular one. I realize that language issues would be a hurdle and there were strides made towards that endeavor such as with WireWordTools but don't know if the feasibility was broken down once multi-language was considered or if it's still able to be worked on and released. 2. Recurring Dates / RRule I too would have a use for this. Realistically, most businesses could if they want to attempt to accurately list their open hours when they celebrate holidays, as holidays have recurrence, and can have annoying recurrence (like the American Thanksgiving) which is the 4th Thursday of November. API-based things might have a need/want to integrate LazyCron into a non-standard recurrence. My personal usage would be for events - honestly I'm surprised the school websites Ryan's worked on haven't had a need for this. Reporting to Google for JSON-LD on its recurrence may also be helpful to have an API-level access to it as well (I'm not familiar enough to know for sure though). The largest difficulties in handling recurring events is exception management. There are usually two ways to generate recurrence - tie them to a single entry and assign a recurrence rule and extrapolate from that dynamically on call, or use the recurrence rule to generate the actual entries, individually (and usually have them tied to an original). How would exceptions be handled if a single date, or time, needed an adjustment? If one or more were cancelled? If one or more were to be added? If editing the primary edits them all, does it overwrite all others even if individual changes were made? Whether convention or configuration, these are just some potential issues with recurrence. 🙂 Image Reference Field and/or Central Image Manager: It's certainly not necessary to a website being used, created, or maintained - but it would certainly be helpful if it was part of the core, whether optionally (in page settings) or statically (as a field/input setting). Teppo did a great job illustrating why: I'm essentially a technician (title is Web Administrator, but 85% of my job's time is help desk / support), professionally I'm a programmer/web developer, but the business I've worked for has 100+ people who are extremely varied in their technical expertise. 40 or so of them will be expected to have access to the administrative back-end for the primary website I'm (finally) redoing in one way or another, as they will be the content authors/maintainers (I work for a public library, so these are city-level librarians). They would not take the time to find a reference to an image already in the system when they could more easily just upload another completely brand new copy of the same image (let's say it's a 200MB file) multiple times, and resize it to a 240px width. I know that I could create a page that contained a "shared" image repository, or use one of the various modules, but the fact is that it can be very useful for various reasons. Layout Tool / Editor: From my own personal experience, I would agree with bernhard here. I think, based on the 5th time I've read through this topic, that it's been decided that Editor.js, specifically, is not a good fit, but continuing on... I'd done some testing of my own, like bernhard, and found limitations and issues with it. I'd also tried showing it to some basic-skilled coworkers with minimal (but enough) instruction and they struggled, hard. Showing them a CKeditor field (without instruction), however, they were able to do what they wanted and although were confused with certain things, weren't struggling. That said, from what I've seen of Bard and Editor.js, a similar approach can be managed using styling and JS adjustments with the RepeaterMatrix fieldtype, even if it's apparently overkill where storage needs come in. I do like that individual fields are still independently searchable within RepeaterMatrix though, which I think wouldn't be the case with an Editor.js fieldtype solution. How is RepeaterMatrix similar to Editor.js with style and JS changes? Robin S. and monollonom essentially had similar ideas - that the layout is different for Editorjs/Bard type fields, they're more compact and seemingly integrated. From the observation of the front-end GUI interface of Editor.js and Bard, it's doing something fairly similar to what RepeaterMatrix currently does - you create a new item (or start of a block of items) from a predetermined set of options. It's just that the interface of the other two has a different "wow" factor. Click a hoverable + button, choose from the available options, and then go about adding the related content. So if a fieldtype was created that's similar to RepeaterMatrix but stored data in a more efficient way, and was intended to be a more concise and (for lack of a better word) all-enclosed field, I would think using similar markup to RepeaterMatrix with a much more visually minified styling could help here. I'd love to understand more about how the $page-meta() can be used to integrate non-field stored data like bernhard was asking about, because that could be a way for developers to setup layout-like interfaces within custom-made template builders. Actual Page Builder - an Alternative: Fieldtype There are a few open source visual page builders for email templates (ex: GrapeJS). These are well-tested and I'm thinking that for the purposes of single page instances or landing pages, something like that could be used and created into a fieldtype of its own. Remove all of the markup from it afterSave to get only the text content, and place that content in a separate data field in the DB to make it searchable and it's now capable of being a standard page/template in PW. It would be up to the developer to place appropriate limits on it, but beyond that... Just a thought. I ♥ ProcessWire. (I also love all of the work that's been done since this topic was created, too!)

Although slow and impractical to show all 100 images on a single page in a gallery, would it be as slow and impractical if you used the JS-based lazy-loading for images (don't forget to force container size on the image so there's no re-flow issues during rendering -- ex: https://css-tricks.com/preventing-content-reflow-from-lazy-loaded-images/). It's not necessarily a better solution, just an alternative.

The ProcessWire modules directory link for Fieldtype Leaflet Map Marker is pointing to the master branch's ZIP archive which is the 2.8.1 version. I'm assuming that needs to be updated to point to the proper Github location.

It appears that the issue I'm having with the CSS layout is because I wasn't using AJAX to load a pre-existing template/form, there is no wrapping form field. Even if your module uses InputfieldForm to wrap/render your module's inputs, the form itself is stripped in the page edit admin so that the page template only contains a single form. So...I either need to dynamically wrap my content in a form (with class "InputfieldForm"), or create a template and use AJAX load with the panel. I'm not sure which is simpler. Probably the AJAX for less future maintenance...in which case, I now need to figure out how to have an external template with my module as I can't think of any public modules that do that to study from.

That second bit with the hook is extremely useful - just not in this instance: if the field is included, it's going to be used on the page, and therefore the JS will be required no matter what. However, I'm going to save that bit away for later!!! Thank you! Your function format (and find() call) apparently was what I needed. Using that worked. jQuery(document).on('pw-panel-opened', function (eventData, panelNode) { The iframe, in my case, was not going to work since the form actually exists on the current page. (A semi-unknown/unused aspect of the panel is that you can load content that already exists on the current page using data-panel-id: $button->attr('data-panel-id', 'module-fieldtype-container'); ... when using this method, however, there's no iframe.) Thank you!!!!!!

I think my issue with the columns may be because I'm using the panel to load a form that exists (but is hidden via CSS) on the page-edit screen. Essentially my custom Fieldtype is large enough that it made sense to load the add/edit form somewhere else (modal/panel). It's likely that I'm not wrapping the form that I've created on the page (and grabbing via JS using $button->attr('data-panel-id', 'fieldtype-form');) in a particular class, though I've not yet figured out what that class is. I believe most people that use the panel are targeting an AJAX load to another file/form external from the currently edited page. As for the JS, I'm still trying to figure out how to target only the panel that I just opened and not any panel on the page (i.e.: Page Edit screen's "View" -> "Panel"). I thought I had figured it out with the following, but it only ever runs the ELSE loop. From the panels.js code, it looks like the classes should exist before the custom event trigger is registered, so I'm not sure what's going on. $(document).ready(function() { $(document).on("pw-panel-opened", function(e) { if ($('*[data-panel-id="fieldtype-form"]').hasClass('pw-panel-container-open')) { console.log('book add opened'); } else { console.log('panel opened'); } }); }); Running that test ([data-panel-id="fieldtype-form"]) from the browser's console while open or closed manually gives me the result I expect.

Hi @Zeka, yes I'm developing (or trying to anyway 😆) a Fieldtype/Inputtype. I'll have to do some more testing with the columns to see what might be the issue I'm having (thanks for showing me your example). I'm also going to upgrade from Master to Dev to see if it makes a difference. I tried your version of the jQuery call and it worked - the first time the panel opened. Successive opens were not getting logged. So it seems I'm targetting the wrong element in my call (as your code example will run any time any panel is activated), but why it doesn't seem to run on all of the actual events is strange. (Edit: Firefox was kindly aggregating similar console.log results for me and I didn't notice.) Hopefully the Dev version will show further success. 😉

I tried taking advantage of the panel.js in the "dev" branch and using an "on" method for "pw-panel-opened" in my module but it also failed. $(document).ready(function() { $(document).on("pw-panel-opened", ".InputfieldBooksAddPanel", function(e) { alert('It is open!'); // This never shows up $('#isbn').focus(); // This never receives focus }); }); Also, unrelated, but can panels take advantage of the admin theme's columnWidth for rendering core elements? It doesn't seem to behave the way I'd expect (ex: I can get 50% width for the inputs within the panel, but there is never more than a single column).

Hello all! Has anyone with more JavaScript abilities been able to hook into ProcessWire's jQueryUI Panel functionality in order to handle onload events of the panel itself? I'm trying to simply set focus to the first input element of the form after clicking the button that activates the panel, but my click event does not run (I think due to the return false; in the panel.js as shown below). .../wire/modules/Jquery/JqueryUI/panel.js: // delegate events from toggler to pw-panel-button $toggler.click(function() { $btn.click(); return false; }).on('mouseover', function() { $btn.mouseover(); }).on('mouseout', function() { $btn.mouseout(); });