Leaderboard

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.

RockAwesome ProcessWire Fieldtype to easily choose FontAwesome Icons Usage Install the module. Set paths in the Inputfield's settings page. Add a RockAwesome field to any template (or change an existing TEXT field). Preview https://modules.processwire.com/modules/fieldtype-rock-awesome/ https://github.com/BernhardBaumrock/RockAwesome

New Version 1.0.5 - Fixes empty value bug for FieldtypePage and FieldtypePage::derefAsPageOrFalse setting. @dragan I was trying to reproduce your bug but encountered different one which is also related to FieldtypePage. This probably not related to your bug but try it anyway when you have time.

Hi @VeiJari Thanks! ? It seems that my "fix" to support german umlauts in meta tags breaks letters in other languages. ? Can you change the code according to this issue? https://github.com/wanze/SeoMaestro/issues/15 I'll release a version 1.0.1 which fixes this as soon as possible. Cheers

Cool. Sounds like you are sorted. On the node / npm front, I think the easiest way to wrap your head around using node for build systems is to skip the bundlers and task runners and just use npm scripts. The benefits of this are you are using the cli's of each library you install directly, and not interacting with wrappers and plugins build upon these. This makes things easier to debug / easier to reason about. Here are some blog posts on this topic: https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ https://deliciousbrains.com/npm-build-script/ https://scotch.io/tutorials/using-npm-as-a-build-tool For browsersync in particular, the below cli commands are all you will ever need to know: # static site browser-sync start --server 'public' --files 'public' --browser 'Google Chrome' --no-notify # php site with local domain using eg dnsmasq browser-sync start --proxy 'localdomain.test' --watch --files public/site/templates --browser 'Google Chrome' --no-notify After years of npm scripts I now use https://github.com/sezna/nps and https://github.com/kentcdodds/nps-utils for cross platform builds. Here's an example package-scripts.js: /* global require */ /* global module */ const { series, concurrent } = require("nps-utils"); module.exports = { scripts: { css: { dev: "gulp cssDev", build: "gulp cssBuild" }, js: { dev: "rollup -c rollup.config.dev.js" build: "rollup -c rollup.config.prod.js" }, server: { start: "browser-sync start " + "--no-inject-changes " + "--proxy 'localdomain.test' " + "--watch --files public/site/templates public/static " + "--browser 'Google Chrome' " + "--no-notify " }, watch: { css: "chokidar 'src/stylus/**/*' -c 'nps css.dev'", js: "chokidar 'src/js/**/*' -c 'nps js.dev'" }, dev: { pre: series.nps("css.dev", "js.dev"), main: concurrent.nps( "watch.css", "watch.js", "server.start"), default: series.nps("dev.pre", "dev.main") }, build: series.nps("css.build", "js.build") } }; Then in package json you just have: { ... "scripts": { "dev": "nps dev", "build": "nps build" }, ... } Cd to your projects and: # run dev w/ livereload npm run dev # run your build (minification etc) npm run build # test individual nps commands npx nps server.start I'm using gulp for css since I use stylus and gulp is the easiest way to run stylus through a bunch of postcss transforms. Rollup is by far the easiest way to bundle js in my opinion. Here's my rollup build file pretty much for every project. The dev version doesn't include terser and sets source maps to true. /*jshint esversion: 6 */ import resolve from "rollup-plugin-node-resolve"; import commonjs from "rollup-plugin-commonjs"; import buble from "rollup-plugin-buble"; import { terser } from "rollup-plugin-terser"; export default { input: "src/js/main.js", plugins: [ resolve({ mainFields: ["module", "main"] }), commonjs({ include: ["node_modules/**"], sourceMap: false }), buble(), terser({ compress: { drop_console: true } }) ], output: { file: "public/site/templates/assets/main.js", format: "iife", sourcemap: false } };

Try: https://processwire.com/api/ref/page/get-field/ $page->getField('Formattext01')->id

Hi @formulate - I'm using the module, without any problems, from Outlook and other email clients. So I'm not sure it's anything about Outlook per se. Have you checked what are the restrictions on sending addresses?

That's fine. You should set it under legalFields config. The legalPageFields is for built-in fields like name, id, path, url, created and etc. I'm still not sure how this could be happening. You're the second person with this problem but I can't reproduce it. Page reference fields have title and I can query them on my installations. Is there any chance that you can reproduce this in any of the Site Profiles? Then you can export it with Site Profile Exporter and share with me. I will continue trying to reproduce it but it'll go faster if you help me with it.

No, it's not. The title field can be removed from the page. so it's not included by default. In your graphql documentation, does your page reference fields has a title field in them?

When you create a FieldtypePage field it can store a reference to any page. Which means the module cannot know which template those pages have upfront, which in turn means we cannot know which fields those pages will have when we generate the schema (except built in fields like id, name, url and etc). But if you set a particular template for selectable pages for that field, then it will detect it and additional template fields for your page references will be available. So my guess would be that your page reference field does not have a template assigned to it. Is that your case?

It could be. When some field is empty it should return null or empty array. Somewhere in the code it might be trying to return a value instead. I'm looking into FieldtypeInteger and can't quite figure out yet what I missed.

Yes. In debug mode it will return very verbose error messages. But ideally it should not return any errors. All my success tests check if the response has data in it and does not assert that there are no errors. So it might be that I have those errors as well, just didn't catch them. I'll try to reproduce your case and fix it. What type of field your budget field is? I assume integer, but want to be certain.

@Wanze – congratulations for version 1.0.0 and a big thank you! @adrian: i've got it working now to correctly display the og:image in admin view – below the hook with inheritance mode as follows: if page og:image is empty, travel up tree until there is one at closest parent, use this. If no og:image found until home use default og:image from settings-page (a special page for sitewide settings). should go @ready.php /** * In addition to module SeoMaestro * if page has no og:image set, inherit from closest parent with given og:image * if no og:image is set in branch until home -> fallback to default og:image @settings-page */ $this->addHookAfter('SeoMaestro::renderSeoDataValue', function (HookEvent $event) { $group = $event->arguments(0); $name = $event->arguments(1); $value = $event->arguments(2); $isAdmin = ($this->page->rootParent->id == 2); if ($isAdmin) { $page = wire('pages')->get(wire('input')->get->id); } else { $page = $event->wire('page'); } $field = "og_image"; // used field for og:image // @config: one element or NULL if empty // no default output if empty $configpage = "1049"; // holding site-wide default og:image (og_image here set as required) if ($group === 'opengraph' && $name === 'image') { bd('og image is: '.$value); bd('page is: '.$page->id); // do nothing if page has og:image if ($value !== "") return; $sitedefaultimage = wire('pages')->get($configpage)->getFormatted('og_image'); //scenario 1: fetch default image assigned in field-settings (get formatted) // config field settings @og_image accordingly, what page to use if empty //scenario 2: inherit from next upper parent-page in tree with assigned image // @config @og_image: no setting for default value $selector = "og_image.count>'0'"; $option = $page->parent($selector); if ($option->id) { $value = $option->getFormatted($field); $src = $option->title; } else { $value = $sitedefaultimage; $src = "site-settings"; } $value = $value->httpUrl; bd("og:image inherited from: {$src}\n{$value}"); $event->return = $value; } }); I corrected $value = $value->url; to $value = $value->httpUrl;

The solution mentioned above does not use any hooks. ? I did not test it, but I'm positive that the image pulled from the home page appears in the preview.

Many ISPs throttle email delivery. I've had emails take up to a day to be delivered. There isn't anything you can do about their setup. This could be your email system or your client's email system or both causing the problem. You could possibly eliminate your provider by using a reputable provider, such as gmail, mailgun, etc. to send emails. You will still be at the mercy of the client provider though.

@JeevanisM Have you tried to install WireMailSmtp or WireMailGmail? I have never used Login\Register module, but from code, I don't see some predefined function for disabling Link Sending feature. One thing that you can do is to hook and replace ___processRegisterForm method. https://processwire.com/docs/modules/hooks/#how-can-my-hook-replace-another-method-entirely

Design: polimorf.de Development: muskaat.de They team up for tasks like that and I'm also part of Muskaat. ? So feel free to take a look at the references there. Located in Neumünster - close enough to Hamburg for meetings.

There are a few videos by Soma dedicated to plugins. But I also try to notice a bit of a master's backend organisation while he is clicking through the admin. Here is the link.

ProcessWire is actually the first iteration of this CMS that doesn't rely on a template engine. And Dictator CMS (the grandaddy of ProcessWire) was entirely template engine based, with no PHP API or PHP support at all. I'm no stranger to template engines. While there are benefits to template engines, my own experience has been that the benefits are largely perceived rather than experienced. There are also some tangible benefits too. But how many of those tangible benefits apply varies greatly from system to system. ProcessWire has a nice API, but most CMSs do not. For many of those CMSs, the template engine is what makes the system accessible (or at least, more accessible). Expression Engine is an example. In those systems, template engines are providing a huge benefit by isolating the developer from having to use a complex or crappy API. Nobody would use these systems without the template engine. But in a system like ProcessWire, a template engine is redundant, less capable, and ultimately more complex layer of overhead. Most of the time, we do not want that kind of extra overhead in ProcessWire. In our context, the only real benefits of a template engine are if you have some kind of syntax preferences (PHP is not always the prettiest syntax) or if you want to have a jail. There are some valid reasons to have a jail, as pointed out earlier… but I prefer education to jail. Still, I understand the reasoning and can't say it's always wrong. Just that it's wrong for a core default. There's also that benefit of perception. If one perceives there are some other benefits to a template engine, they will seek out systems that have them, even if perception isn't always reality. I believe strongly in the benefits of our current approach and API. I feel these benefits are far greater than what comes from any template engine. And I've discussed them at length many times in many places, so I won't rehash that all here. But I've always wanted ProcessWire to support template engines, just not to require one. So I like what I see with the Twig and Smarty modules. Actually, the Smarty module seems like it would be especially simple to work with, since it bolts in so quickly and easily. I hope to see more in this area and am always willing to do whatever it takes to support add-on template engines (we even added a hook or two to support the Twig module). While I personally don't need these template engines and sometimes question their value, I also very much support them in ProcessWire as modules. Perception is powerful, and we're trying to grow our audience. Likewise, there may be some that have template engine preferences beyond just perception. Anything that opens a door for more people is a good thing. While ProcessWire's core isn't and won't be built around a template engine dependency, we fully support use and implementation of them as modules. And I'm also willing to add any new core hooks or capabilities necessary to support the development of such modules.

The problem here is that resizeThumb()'s implementation assumes that one can construct the server path to the file from the URL (see the first line in that function). But the URL and disk path can be very different things. You may be able to fix it by replacing the first line in that function with this: $thumb_path = $field->path() . basename($thumb_url);