Leaderboard

There hasn't been a lot of activity on the core this week, as I've been wrapped up in a ProcessWire-based client project (same one as last week). I'd like to put in a few more updates before bumping the version number, which will likely be next week. This week I also released a new module to accommodate a feature that had been requested more than once, but since it's not that commonly needed, I thought it was better to put it in a module rather than the core: Custom Inputfield Attributes for ProcessWire This module enhances both the interactive and API configurability of fields in ProcessWire (both admin and front-end). It can add custom attributes to Inputfields in ProcessWire, FormBuilder, or other Inputfield forms. Custom attributes can be configured interactively in the admin, or they can be added via this module’s API method. Custom attributes can be added to the <input> element of an Inputfield or they can be added to the wrapping .Inputfield element. You can add any attribute that you want (with a few exceptions), whether replacing or appending existing attributes, adding data-* attributes or any other named attribute. This module is available for download now on GitHub with more details on the module info page. Thanks for reading and have a great weekend!

@MarkE The general problem in page builders is what frontend framework support they offer. Does the frontend framework support they provide align with your design, or do you need to learn and adapt to this frontend framework? The same problem exists in ProcessWire as well. When we want to use the fields on the frontend, we often need to make numerous modifications to achieve the desired results. I also have my own page builder structure created using the PageTable module, and I've been using this structure for about six years, continuously updating it on my end. The primary reason for creating the Mystique module is to dynamically create custom fields within the page builder and manage them as I like. My custom page builder is built on the Uikit 3 framework, but when I want to use Tailwind CSS or Bootstrap in the frontend, the current system doesn't support this. One of the reasons is that I primarily use the Component module and have created a separate module called UikitComponent to configure Uikit components within this module. I aim to apply this for Bootstrap, Tailwind CSS, or any other frontend framework or design. In addition to this, another fundamental reason for writing the Component module is to be able to provide readable and understandable outputs for the requests sent to the page in the HTMX module that I am preparing for publication. In the project I'm working on, I'm using the HTMX, Component, and Mystique modules together. I created a component called 'product-list' and added extra settings to this component, including 'element' => true and 'fields' => array(). In the 'fields' section, I added configuration settings for the Mystique module. I added the 'element' => true setting to use this component in my page builder, making it accessible both in the code and through the admin panel. This way, the component can be used on the code side and added to the desired location by the administrator through the admin panel. Also you can check a javascript solution: https://github.com/codex-team/editor.js I wrote a module and have some experience with this. Output is clean json data Ekran Kaydı 2023-10-12 13.33.49.mov

@MarkE Thanks for your interest. Choosing the right tool always depens on the job and personal preferences. And of cause I am a bit biased, so choose what ever works for you and your clients. You can use PAGEGRID with a CSS framework if you like. You just have to include the css file in your template. Then it's just a matter of adding the right classes, either in the block template files via code or via the style panel. You can even add multiple classes, e.g. utility classes from tailwind throught the style panel. A Component in PAGEGRID would be a block. So you can create a block template and use any combination of fields in it (similar to how Repeater Matrix or PageTable work). You can also add a custom css and/or javascript file that will get loaded with your block template (e.g. myBlock.php, myBlock.css, myBlock.js).

@da² - unless I am misunderstanding you, the PW Upgrades module doesn't do anything to upgrade the DB. There are almost never changes to the PW DB schema, but if they are required, then it is handled automatically the first time PW loads after the contents of the wire folder are updated with the new version.

Thx for your interest. I'm sorry that it takes longer than expected. The module is ready to be used and it has been developed for something around 3 years. It works great and I think it is a great tool for developing websites. Anybody interested doesn't need to wait and can send me a PM and buy a copy right away. Unfortunately we don't have any infrastructure for selling commercial modules. So anybody who wants to sell modules needs to build one on its own. That is not trivial and takes time. And unfortunately there are other things that kick in from time to time (client work and life...). I do my best to release it soon ?

Hi, This question is not about the custom CSS styles that we can add to TinyMCE that end up showing up in the Format drop-down menu. This is about the TinyMCE-generated classes. For example, if you select a text and go to Format -> Align -> Left, the editor will output the text with a "aling_left" class. My confusion is here. Is there a way to modify that? So, instead of output "align_left", it would output "uk-text-left". Any help will be appreciated!

Thanks! Custom JSON is the way to go!

I guess to rename the default classes you have to use custom JSON settings: https://processwire.com/blog/posts/using-tinymce-6-in-processwire/#using-custom-json-settings https://www.tiny.cloud/docs/configure/content-formatting/ But maybe @ryan knows an easier way. ?

Hi @AndZyk, Thanks, that it is what I'm doing now. However, I would like to see TinyMCE generating the uk-text-left class, instead the align_left one.

@wbmnfktr thanks for your support! Feel free to ask any questions in the forum if you need help with it.

Hi Ryan, Would it be possible to create a more streamlined way for your 1st party commercial modules to be downloaded? I have licenses for most of them and grabbing them all one-by-one through the respective forum threads is less than ideal. Too much friction. Ideally, if they could be upgraded via ProcessWireUpgrades module (although I think I understand your hesitation doing it that way), or if there were some sort central control panel on processwire.com/talk/ (or just processwire.com), that would be a nice upgrade.

After some tedious experiments, I finally managed to switch my site's default language from English to German both in frontend and backend. I am reliefed but not satisfied because it was a terrible hack: Starting with @mscore's SQL script, I added a condition to make sure that field texts are only swapped if a translation exists SET s1.data = s1.data123, s1.data123 = s2.data WHERE s1.pages_id = s2.pages_id AND s1.data1019 != ''; Especially important for backend field without translation, otherwise the backend text will get broken. Then, I added some lines in order to update the option names for FieldtypeOptions: UPDATE fieldtype_options s1, fieldtype_options s2 SET s1.title = s1.title123, s1.title123 = s2.title, s1.value = s1.value123, s1.value123 = s2.value WHERE s1.fields_id = s2.fields_id and s1.option_id = s2.option_id; The following statements are necessary for keeping the correct translation files for both languages (let 124 be the page id of the default language): update field_language_files set pages_id = 123 where pages_id = 124; update field_language_files_site set pages_id = 123 where pages_id = 124; Unfortunately, since translation files are stored in the assets, it is also necessary to swap the corresponding asset directory names: files/123 to files/124. The final step is changing the title of the new non-default language ("deutsch" to "english") and the language names respective. I can't understand why there's still no out-of-the-box solution for this use-case, which is IMHO not so unusual. I also would prefer a PW API solution like @gebeer's one, but I couldnt' find out how to iterate over really all stuff I need (including backend) ...

Many thanks for this, @Mats var request = new Request(url, { headers: new Headers({ 'X-Requested-With': 'XMLHttpRequest' }) }); fetch(request) .then(response => response.text()) .then(data => { console.log(data); });

Check this:

@Jonathan Claeys Please provide an example of the code you are using to try and get your media image URL. I haven't used Media Manager, but looking at the documentation for outputting to the front-end there are a couple of things to be aware of: 1. A Media Manager field returns an array (specifically a 'MediaManagerArray') so you need to treat it as such in your template even if it contains only a single media item. The docs suggest looping over it, but if a MediaManagerArray is also a WireArray (the docs aren't specific about that) then you could use other API methods to get items such as first() or get($key). 2. The media itself (an image in your case) is contained in the media property of an individual MediaManager object. So you need to use methods like url or size() on the media property and not on the MediaManager object. Assuming that a MediaManagerArray is a WireArray and that your Media Manager field is called my_media_field: $media_manager_array = $page->my_media_field; $media_manager_object = $media_manager_array->first(); $image_object = $media_manager_object->media; $url = $image_object->url; echo "<img src='$url'>"; This is just to give you the idea, and is more verbose than necessary.

yeah but a little api magic can cure that.. open up your tools or api playground and: $pp = $pages->get(1234); // page you're adding the children to the page table foreach($pp->children as $child) { $pp->page_table_field->add($child); }

Hello, PageTable is described as a leaner way to enter large amount of repeatable data into the admin backend, possibly with different sets of fields (think different templates). The main advantages compared to the Repeater are: 1. PageTable can save new pages where you tell it to. Repeaters are saved deep down the Admin pages and are given cryptic names. 2. One PageTable field can make use of several different templates. Repeaters play according to the "One repeater = one template" rule (roughly put). PageTable is a PageArray, so relevant methods are applicable. For example, here is how to add and remove items from a PageTable field using the PW API: // create a new page // IMPORTANT: your PageTable field must be configured to use template 'basic-page' in the field Setup tab $newpage = $pages->add('basic-page', '/about/', 'address', array('title' => 'Write to us')); $page->of(false); // add the newly created page to 'pt' which is a PageTable field $page->pt->add($newpage); $page->save(); Here is how to remove the first item from a PageTable field: $page->of(false); // 'pt' is a field of type PageTable $page->pt->get(0)->delete(); $page->save(); That's a quick overview of this new field type. Give it a bit of your attention, it's quite promising. Cheers, Valery.