Leaderboard

Hi everybody, I want to share what I came up with. Background: The goal was to get a color-accent to every headline on my new project. First thought was to use CSS-only with ::before pseudo element, but the problem is, that the headline is a either a block element (then position absolute left 0 leads to the accent being on the very left even for text-align:center headlines). Or if the headline is inline-block I had some other weird problem that I can't remember right now. Also multiline headlines where tricky. That's why I wanted to add a real element at the beginning of every headline. Wrapping the first word was actually not necessary. I'm adding an empty <i></i> now right behind the opening <h2> or <h3> tag, so the regex get's even simpler. Here's the result: Here's the LESS if someone is interested: // apply style to all elements with tm-fancy attribute // this attribute is added to all h2+h3 via textformatter *[tm-fancy] { font-family: @tm-font-fancy; i:first-of-type { position: relative; } i:first-of-type::before { content: ''; position: absolute; left: -15px; bottom: 5px; width: 120px; height: 20px; background: @tm-secondary; z-index: -1; border-radius: 2px; } } // adjust width and height for h3 h3[tm-fancy] i:first-of-type::before { width: 100px; height: 15px; } And here's the very simple textformatter that I can apply now an every textarea field: <?php namespace ProcessWire; class TextformatterFancyHeadlines extends Textformatter { public static function getModuleInfo() { return array( 'title' => 'FancyHeadlines', 'version' => 100, 'summary' => "Add <i></i> to headlines for color accents.", ); } public function format(&$str) { // early exit if there are not h2 or h3 elements if(strpos($str, "<h2") < 0 AND strpos($str, "<h3") <0) return; // add attribute and inline element via regex $re = '~(<h[23][^>]*)(>)~ism'; $str = preg_replace($re, "$1 tm-fancy$2<i></i>", $str); } } Thx for your help ? PS: If anybody knows a better solution please share it ? Maybe there's a CSS-only way of doing that?

@Ivan Gretsky and @szabesz - new version adds a new "Bar Position" module setting that lets you choose between bottom left and bottom right. Let me know if you notice any problems.

ProcessWire 3.0.123 and PHP 7.2 play really nice together out of the box. An update or upgrade of ProcessWire therefore isn't needed actually. The downtime you experience might be another issue... either cached pages, a bunch of cached compiled files and modules... are there any errors in the frontend or in the logs (Setup > Logs) you could share with us? Is only the frontend or even the backend/admin area affected by those issues? Or maybe even better a link to your site. Oh... welcome to the best community in the world. ?

New version v2.1.2 is out on github. This version fixes a problem with images inside a folder that have names not conform with file naming conventions. When the module loads images from a folder, it converts them to Pageimage objects. When images are added to a Pageimages object file names get sanitized automatically by PW. In my case this resulted in different file names inside the Pageimage object and on disk. Consequently, thumbnails and previews for those images could not be loaded. I fixed this by automatically renaming all folder images to match the sanitized name versions inside a Pagimage object. This version also adds the ability to set values to this field via API. You can now do something like this to set a Pageimage object as new value to this fieldtype via API $p = $pages->get(1001); $image = $p->image; // returns a Pageimage object $p->of(false); $p->set('imagereference', $image); // sets the Pageimage object to the ImageReference field. This gets converted to a JSON string internally for storage $p->save();

I hope that you all have had a great week! I’ve got several commits to the core on the dev branch this week, with both improvements and fixes. I’m going to save the version bump to 3.0.150 till likely next week, when there should be more to write about. In addition to working on and supporting the core and modules here, I’ve been collaborating with Pete (forum admin) on a client project in ProcessWire. It’s keeping us both pretty busy, but I really value and enjoy the opportunity to develop sites in ProcessWire—it’s always a nice change of pace to develop something using ProcessWire, in addition to developing it. And it’s also a real pleasure to collaborate with Pete, he does amazing work. While working on this project, I’m still very much focused on core and module updates, but emphasizing smaller core updates like fixing issues and making incremental improvements to existing parts of the core (like in this week’s commits). Once we finish the first phase of this project (mid February), then I’ll be focusing on some larger updates and additions (and the related blog posts). Thanks have a great weekend!

Yeah, sorry about that - the Tracy core just uses PHP's mail() and I wasn't sure how to hook into the send process so I could implement wireMail - of course it turned out to be easy, but it wasn't documented so had to dig a little.

In most cases... everything but /wire/.

Another new version which takes care of an issue that has been lingering from the very first version ? The option to send error messages to your email address when in Production mode now supports wireMail() so it will use whatever wireMail module you are using. There is also a new module setting for defining the "from email" address, as well as the old "to email" option. Remember that messages are only sent if the output mode in settings is set to Production and also note that you will only get one email - all subsequent errors will be logged in the Tracy logs files but won't be emailed until you clear the "sent email" flag. It's sure nice to have this working as a way to track errors that occur on a production site during regular use. Let me know if you find any problems.

here's a quick try: https://codepen.io/dragan1700/pen/bGNZBEK?editors=1100 Whatever you do: don't ever try to do stuff like "underline only the last line of a text block": it's a major cause of migraine. Without using JS this can't be done (yet) only with CSS alone. (Well - not unless you do PDFs, of course, or don't have to make stuff responsive...). A client recently came up with BS like that (which was designed by another agency), and we had a hard time explaining why this was not a good idea.

Thank you for explaning these details and your plans. If you'd like any help testing, I'd be happy to do what I can; this module is a great asset for PW develoment.

Hello all, sharing my new module FieldtypeImageReference. It provides a configurable input field for choosing any type of image from selectable sources. Sources can be: a predefined folder in site/templates/ and/or a page (and optionally its children) and/or the page being edited and/or any page on the site CAUTION: this module is under development and not quite yet in a production-ready state. So please test it carefully. UPDATE: the new version v2.0.0 introduces a breaking change due to renaming the module. If you have an older version already installed, you need to uninstall it and install the latest master version. Module and full description can be found on github https://github.com/gebeer/FieldtypeImageReference Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Read on for features and use cases. Features Images can be loaded from a folder inside site/templates/ or site/assets Images in that folder can be uploaded and deleted from within the inputfield Images can be loaded from other pages defined in the field settings Images can be organized into categories. Child pages of the main 'image source page' serve as categories mages can be loaded from any page on the site From the API side, images can be manipulated like native ProcessWire images (resizing, cropping etc.), even the images from a folder Image thumbnails are loaded into inputfield by ajax on demand Source images on other pages can be edited from within this field. Markup of SVG images can be rendered inline with `echo $image->svgcontent` Image names are fully searchable through the API $pages->find('fieldname.filename=xyz.png'); $pages->find('fieldname.filename%=xy.png'); Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message with links to help you edit those pages and remove references there before you can finally delete the image. This field type can be used with marcrura's Settings Factory module to store images on settings pages, which was not possible with other image field types When to use ? If you want to let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site (e.g. icons, but not limited to that). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images that live on other pages or inside a folder are stored. This has several advantages: one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Installation and setup instructions can be found on github. Here's how the input field looks like in the page editor: If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Eventually this will go in the module directory, too. But it needs some more testing before I submit it. So I'd really appreciate your assistance. Thanks to all who contributed their feedback and suggestions which made this module what it is now.

Wouldn’t it be cool to have whole repeater items (or even repeater matrix items) language-specific. Some of my clients do have pages that are 90% identical in German and English, but there are some sections that should not appear in one or another language. I attached a concept screenshot. Would something like this be possible with some simple backend hooks and "hidden checkbox fields"? Or is it way more complicated?

Now I know why those emails often ended up in the spam folder... Thanks for the improvement!

Actually, the .gitignore in PW root is a nice starting point already. Some of the things I would probably add: *.notes *.sql *.zip site/assets/cache/* site/assets/ProCache* site/assets/pwpc/ site/assets/sessions/ wire/ .sql + .zip are most likely local backups, so I def. don't want them included site/assets/... stuff depends - cache (regular + ProCache) stuff + sessions I'd also not want to carry over. wire/ should certainly not be part of a repo. btw: .notes is just how I store login details; Apache blocks web-access to any files starting with a dot anyway, but you don't want to take chances, so I added this to .gitignore too.

Hi @adrian, Apologies for the lack of response - been fairly in the thick of a project since being back to work after the new year. Hoping to get this looked at soon. Chris

I do the same as wbmnfktr. I also include a github action that auto ftp/pushes the updated files to a directory on my server that can be found here: https://github.com/SamKirkland/FTP-Deploy-Action

And of course... always a fresh DB dump.

@Haagje R. as dragan said, first setup ftp or shell access to the root of PW installation and then remove/rename install.php. I don't get it how the site was working with install.php present. Then, as Bitpoet said, replace ProcessWireUpgrade module with the new one, as this is the problem. I use PW on WIndows/IIS and not on Linux/Apache but I can help using Teamviewer. PM me if needed.

@Haagje R. I assume you have FTP-access? The error screenshot you posted says that your PW installation still has the install.php in root. That should have been removed right after the initial installation (removing that file - and others - is actually part of PW's installation routine). If that install.php still exists on the server, simply delete it, and try again. PS Checking https://www.neuro-insight.de/install.php throws an error about your 404 page not being viewable by guests (guest user = not logged in). So there might be more strange things to check...

Or it might be sufficient to replace the module in question (ProcessWire Upgrade) in site/modules with the recent one which doesn't have that issue.

Hi @bernhard Can you try @next branch https://github.com/trk/Mystique/tree/next, this will be next version.

I think there will be cases where custom fields will differ by product template, so the order might not be guaranteed and it's probably better to name them after their content (custom_field_size instead of custom_field_1). But how do you determine the option n° for Snipcart — if you move around the field in the template, should it keep its ID to keep order records consistent, or does that not matter as long as it's named properly? That's what I've done in the past: create an order template with fields that I map to custom options. Also good to have the consent text editable by site editors.

Custom product and order fields are in the works! I am just not sure yet how to make this feature configurable via module config.

Check x-requested-with here: https://en.m.wikipedia.org/wiki/XMLHttpRequest

quick, dirty & ready ? $this->addHookAfter('Page::render', function ($event) { if ($this->page->template != 'admin') { // just an example I use in almost every PW site: add responsive wrappers around iFrames: if (strpos($event->return, 'videoWrapper') === false) { $event->return = str_replace("<iframe", "\n<div class='videoWrapper'><iframe", $event->return); $event->return = str_replace("</iframe>", "</iframe></div>", $event->return); } // another example I use in almost every PW site: add responsive wrappers around tables: if (strpos($event->return, 'scrollTable') === false) { $event->return = str_replace("<table", "\n<div class='scrollTable'><table", $event->return); $event->return = str_replace("</table>", "</table></div>", $event->return); } $cleaned = preg_replace('~(<h[23]\\b.*?>(?:<[a-z][^>]*>)*)(\w+)~ism', '$1<span>$2</span>', $event->return); // BitPoet's regex magic $event->return = preg_replace('/<p>\\s*?(<a .*?><img.*?><\\/a>|<img.*?>)?\\s*<\\/p>/s', '\1', $cleaned); // remove default paragraphs around images in CKE } });

preg_replace('~(<h[23]\\b.*?>(?:<[a-z][^>]*>)*)(\w+)~ism', '$1<span>$2</span>', $headline); quick&dirty in PHP

Hi Adrian, I would be happy to hear that you give another chance of the possibility to move the bar to the bottom left corner, optionally. Dragging it around is kinda pointless, at least in my point of view, but as I already explained it in the past, the bottom right corner can sometimes be problematic when Tracy interferes with something, and covering an interactive part of the site is not really a solution. However, it is very rare that both bottom corners contain interactive elements, so being able to pick which corner to cover would suffice most situations, I think.

Hi @Ivan Gretsky - the core Tracy package comes with the ability to drag the bar but I disabled it long ago because it was causing too many problems and I didn't really see many advantages. Perhaps you can solve the issue you are having with the "Starting z-index for panels" option in the module settings. If that doesn't work for you, let me know and we'll figure something else out.

I understand why you are asking for this feature. You're not the first one. But it's not as obvious as it seems. The 'title' field is not the same as all other built-in fields. You can't modify the behavior of the built-in fields per template basis. Which means they all behave the same no matter what template the page has. That's why we have a generic type 'Page' that has all the built-in fields. No matter what template the page we can confidently serve those fields for every page. The 'title' field's behavior could change depending on the template. I understand that it is almost never the case, but semantically it is. For example, you can set different access settings for 'title' field depending on the template. You make it that user can view the 'title' on one template and not on the other. You can change the description of the field for each template and it will appear in the GraphQL documentation. You can also make 'title' field 'not required' for one template and 'required' for others. So, including 'title' field into the Page type will break the semantics. I understand that 'title' field is almost always treated as a built-in field but I just can't overcome this feeling that it is the 'wrong' way to do it. I would like do it only the 'right' way. And the right way brings us to your second question. If we implement it properly and add the ability to get the values of the template fields for generic Page types, then 'title' field should also be solved. For this we will be adding interfaces. It will allow you to get template fields for Page types by providing a template. It will look something like this. { city{ list{ children{ # <== let's say children are the pages with template skyscraper and architect list{ id name ... on SkyscraperPage { # <== you basically say: "for skyscraper pages give me these fields" title images{ url width height } } ... on ArchitectPage { # <== "and for architect pages give me these fields" born email resume{ url filesize } } } } } } } this way you can fetch values for all template fields on Page types. This will work with everything that returns a Page type. Including 'child', 'children', 'parent', 'parents' and Page Reference fields too. And the best part is, it will be semantically correct! ?

on a side note, I was able to create dependent selects using 2 selectize fields, where the options available in the 2nd select dynamically changed based on the selection in the first field. Maybe this topic is relevant...

It does, it's just not documented unfortunately. I linked to information about it in my earlier post above. Here is a demo... Page structure: Field settings for subcategory field: "page.category" will be replaced with the ID of the page selected in the Category inputfield in Page Edit, whenever that field changes. The "has_parent" part is just to avoid unwanted pages appearing in the Subcategory inputfield if the Category inputfield is changed to empty (no page selected). Result:

Here's an example that works without having to first save & re-load the page you're editing. The setup: In my page tree somewhere (usually under a parent I call "meta", "settings" or similar), I have main and sub-categories as pages: The sub category pages have template "empty" with just the title field and nothing else - not even a physical template.php file. The main category pages have tpl "maincat", which holds an addtl. field "main2sub", which is a page reference field. Here you map your sub-categories to each main category. My (simplified) product tpl has two fields: maincat -> page reference field single. Parent = main cat / 1366 select_categories -> page reference field multiple / output as checkboxes. No configuration set in field settings "selectable pages". So far, so boring. I need JS + PHP for the auto-switch to happen. I created site/templates/admin/admin.js In order for PW to even load it, I edited site/templates/admin.php: $config->scripts->add($config->urls->templates . "admin/admin.js"); require($config->paths->adminTemplates . 'controller.php'); // this must stay as the last line admin.js looks like this: It's written in plain JS (ES6). With jQuery it would have been a bit shorter, no doubt, but I got into the habit of using as much vanilla JS as possible. If you need to support older browsers, you'd need to run it through something like Babel. In nearly every PW installation, I create a dedicated template + page that acts as an API / AJAX endpoint. Create a new template "api", enable URL-segments, create a file "api.php" in site/templates/, and finally create a hidden page somewhere that uses this template. Use the option "must have trailing slashes" (check yes). The api.php looks something like this: Basically, what happens, is: On page load and on main-category-dropdown change, I send an AJAX request to my API script with the page ID I'm currently editing and the main category page id. The API script then sends back the matching sub-categories as JSON. JS again then loops through all checkboxes, and de-activates and hides all non-matching choices. It works, but it's not perfect*. I wish PW had an in-built way to handle such scenarios. As always, YMMV. * There's a split second on page load where you see all sub-categories. And also, when you select again the same main-category (without having saved the page), if you made selections previously, they're being erased. The first (minor) issue could probably easy be prevented if you set your subcat field to closed. You could first do your JS-syncing and at the end make them visible with Inputfields.open. Speaking of Inputfields JS API... I found that Inputfields.reload() didn't work here in my example (I tried several types of fields). Pity - would have made such a thing much easier...

@sodesign Ok, I think I found the problem. I was able to get the same error as yours and patched the module to fix it, just now. Try the latest version and let me know if the issue is resolved for you. New Release 1.1.4 - Fix FieldtypePage bug when FieldtypePage:derefAsPageOrNullPage option is enabled.

@sodesign First, I want to clarify some stuff. You are saying that you want to create a page and using a mutation field "createConfiguratorQuote" but supplying it with "ConfiguratorQuoteUpdateInput" which is an incorrect input type. You should supply "ConfiguratorQuoteCreateInput" for creating and "ConfiguratorQuoteUpdateInput" for updating a page. The "add" and "remove" for page references always expects an array of ids. So your latest format for variables is correct for creating a page. Just change UpdateInput type to CreateInput type. But, if you're trying to update a page then "page" input variable should include "id" field. It should look like this... variables: { "page": { "id" : 11111, // <=== you should tell which page you're trying to update. "name": "test-quote", "title": "Test Quote", "parent": "22905", "colour": { "add": [10392] } } } Let me know if I'm missing something.

Hello @Brett. Thank you for your feedback! I was able to reproduce your issue and hopefully tracked down the bug. Please, install the latest version and give it a try. Let me know if the issue is resolved for you. New Release 1.1.3 - Fixed bug with FieldtypePage returning only single value.

I just installed v1.0.0 on PW 3.0.142 and seeing a problem with german umlauts in The Google preview and inherited title. The site has Language Support installed, just to have the backend translated to German. No additional languages. Field title is of type Page Title with textformatter HTML Entity Encoder (standard setting). umlauts.mp4 The title is saved in DB field_title as 'Über uns'. Removing the Entity Encoder Textformatter doesn't help. EDIT: page title is also rendered in the wrong format: Can anyone reproduce this issue? A fix would be greatly appreciated. EDIT: This solution from github issues fixed it for me.

The children results only have with built-in page fields. They don't have template fields. You have to make sure the field title exists in GraphiQL before querying it. When you go to Setup -> GraphQL and enter the above query it will tell you that there is no "title" field for children list. If the field is not in your GraphQL schema you cannot query it. If you want to query your task pages with template fields like title, you can set them as a Page field like you do with your job_client field. That way your tasks will have all the template fields you enabled.

It mostly doesn't matter, you get the same API variables independent of the method. That said, I would suggest the following for readability: $this: Use only inside of classes extending \ProcessWire\Wire. It appears that $this is also available in template files as a reference to the current wire instance, but as you said, this is a somewhat confusing and unconventional usage given that you're not actually inside a class. $wire: Use inside regular PHP template files (or if you want to use a different API variable like $page, $pages, $input, et c. use that one directly). wire(): Use inside functions (not class methods) so you don't have to pass $wire or $this to the closure.

Thanks ^^ I enjoy writing tutorials, I find it helps to consolidate the experience from my projects into organized knowledge. Most of the time I come across some areas where I'm not sure how something works, so I can look it up and further my own understanding (it's also great to improve my English as a non-native speaker). I think writing this stuff down helps bring out the core ideas or the important takeaways; before I started writing this one, I hadn't really considered the part about semantic/intuitive options, I mostly realized during writing that this was the crux of the matter. So yeah, I write for my own benefit as much as everyone else's ?