Leaderboard

This is just one of the things I love about PW, everyone is alway so helpful! Thank you.

https://bluefox.studio/ What makes this project cool: We rebranded the clients logo, turning it into a 3D, Three.JS intro presentation The client can mange all aspects of the site via ProcessWire populating their impressive showcase Custom front-end design and UI and full content management across evey aspect of the site. Modular system for page content providing maximum flexibility on page construction. SEO module with global editing section across all pages. Global shared content modules.

No readme yet but could do exactly what you need: Upload images in one central place and then pick one of them on the related page: https://github.com/baumrock/RockImagePicker If you have any questions or find issues let me know. If you find time to write some instructions / screenshots for the readme that would be great ?

There is also this module by @Robin S Lots of options to choose from ? (though @bernhard’s might be more suitable as it allows to select only one image)

Hi everyone, Introducing my first module https://github.com/christophengelmayer/StaticWire It's a simple way to convert your ProcessWire site to static HTML files via CLI or the admin interface. Useful in CI/CD scripts or to use ProcessWire as a simple static site generator.

PageMjmlToHtml Github: https://github.com/eprcstudio/PageMjmlToHtml Modules directory: https://processwire.com/modules/page-mjml-to-html/ A module allowing you to write your Processwire template using MJML and get a converted HTML output using MJML API. About Created by Mailjet, MJML is a markup language making it a breeze to create newsletters displayed consistently across all email clients. Write your template using MJML combined with Processwire’s API and this module will automatically convert your code into a working newsletter thanks to their free-to-use Rest API. Prerequisite For this module to work you will need to get an API key and paste it in the module’s configuration. Usage Once your credentials are validated, select the template(s) in which you’re using the MJML syntax, save and go visualize your page(s) to see if everything’s good. You will either get error/warning messages or your email properly formatted and ready-to-go. From there you can copy/paste the raw generated code in an external mailing service or distribute your newsletter using ProMailer. Features The MJML output is cached to avoid repetitive API calls Not cached if there are errors/warnings Cleared if the page is saved Cleared if the template file has been modified A simple (dumb?) code viewer highlights lines with errors/warnings A button is added to quickly copy the raw code of the generated newsletter Not added if the page is rendered outside of a PageView Only visible to users with the page’s edit permission A shortcut is also added under “View” in the edit page to open the raw code in a new tab Multi-languages support Notes The code viewer is only shown to superusers. If there’s an error the page will display: Only its title for guests Its title and a message inviting to contact the administrator for editors If you are using the markup regions output strategy, it might be best to not append files to preserve your MJML markup before calling the MJML API. This option is available in the module’s settings. If your layout looks weird somehow, try disabling the minification in the options.

This week I've been working on something a little different: developing a new site profile in ProcessWire. Actually, I should probably call it an application profile rather than a site profile, as it's not a website profile. Instead it's a profile for an invoicing application in ProcessWire. Though you would install and run it on a web server, but it would be an independent application rather than part of a website... perhaps something you run in a subdirectory, subdomain, or even localhost. This is something I've been wanting to build for awhile—ever since the invoice service I use raised their rates beyond my budget. So I thought I'd build a replacement that I could use, as well as share for others that might have a similar need. I think it might also be a pretty decent PW profile example in general, too. I'd originally considered building it as a Process module but decided not to for a few reasons. Though the biggest one is that a site profile enables the greatest potential for customization and expansion according to each person's needs. Since you can expand upon it by adding your own fields and templates, or editing existing ones, most can really tailor it to their own needs a lot more easily than they could if it were a Process module. Likewise, since the actual invoices (and invoice emails) are rendered from front-end pages, you can customize the look and feel of them to match your brand very easily. (This is something I always wished I could do with the invoice service I've been using previously) This invoice profile requires nothing other than the ProcessWire core. It has no 3rd party or Pro module dependencies. I've got it largely functional at this stage, though will be putting a couple more weeks work into it before releasing it. I'd like to build in the option for clients to pay an invoice with a credit card (via Stripe) for instance. Below are a few screenshots of the work in progress. First is the page-list which shows the current invoices in the system and their status. (click image to view larger) As you can see, there are also pages for Clients and Settings. The client pages contain all the information about each client that invoices can be created for. The Settings page is where you can edit your own company information, logo and billing preferences. Next is the invoice editor. Here we have a repeater for each line item in the invoice. We also have a repeater for payments. All of the totals add up automatically as you type (Javascript added via hooks). They are also calculated automatically at the server side, so that everything stays consistent whether working with the API or in the page editor. (click image to view larger) At the bottom of the invoice editor you'll see a collapsed input for "Invoice action". This is where you can select actions to apply to the invoice. The two we currently have are "Email invoice to client" and "Email invoice to another address". Next up is what we see when viewing the invoice on the front-end. This is just the output of a template file but it is optimized for printing, saving to PDF and sending through email. I've kept it intentionally simple but of course the logo would be replaced with your own and all markup/styles are fully under your control. (click image to view larger) What I plan to add next are payment options, enabling a client to pay by credit card right from the invoice URL or email. What do you think, is this type of PW profile useful to you or someone you know? I've initially built it towards my own client invoicing needs, but I'm curious what other features you would like it to have? Or do you think it's better to keep it simple so that people can more easily take it in different directions? Thanks for your feedback. Have a great weekend!

Have you tried setting output formatting to true @cosmicsafari?

Robin's module is more flexible but needs more setup. That's why I created my plug&play module. And the UI is a little different.

Hey, You could create settings page and make changes to all the pages at once. Something like admin settings. Read more here: https://processwire.com/talk/topic/17471-change-css-and-images-through-admin-custom-admin-page/?do=findComment&comment=153511

One more option... You could copy MarkupHTMLPurifier from /wire/modules/Markup/ to /site/modules/ and then select it as the copy you want to use. Then edit HTMLPurifier.standalone.php to replace this code with: return '<' . $token->name . ($attr ? ' ' : '') . $attr . '>'; Seems to solve the slash issue without affecting HTML5 elements like <figure>

Will look into this - probably very soon - yet I still very enjoy this very module in my setups for quite some time now. Thanks @monollonom!

I pushed a new version with two additions: the first one adds the ability to select specific roles to bypass the cache and thus convert the MJML code on each page render. I don’t think it will be used much but it’s there in case the cache invalidation when saving the page or updating the template’s file is not enough the second one is more interesting as it adds the ability to generate a unique output per GET variable. Previously a GET variable would just output and save to the page’s cache but now you can specify GET variables (or the wildcard "*") to have a cached version per variable. Please note though that, when rendering, if there are several GET variables only the first one is used. `raw` is ignored as it’s used by the module. My current use-case for this is having a "browser" version (with ?browser) where I can display a newsletter with the right webfont. I also added a small note in the settings regarding TracyDebugger to invite module users to disable the panel bar for the MJML templates. TracyDebugger hooks to `render` as well and thus some of its markup might end up in the converted code when showing the `raw` version. I think by now this can be considered "beta", though please test on your local environment first and let me know if you notice anything.

Super nice site. Just a thing I stumbled across: bluefox.studio/contacts/ results in a 404 (link coming from bluefox.studio/services/post-sound/) And there is this URL: bluefox.studio/SHOWCASE/ which probably should be in lower case like the canonical (incoming links: https://bluefox.studio/our-process/commercial/ & https://bluefox.studio/our-process/documentary/)

three.js is on the rise

@ID Studio Web Agency. Simply breathtaking! Wow!

Hi Robin Cool, this is working ?. Many thanks for taking the time! The only problem now: due to the html4 value other elements are getting converted, for example <figure> gets deleted (what shouldn't happen). Hopefully there will be a HTML.Doctype html5 in the future ?. Have a nice day and Greetings from Switzerland to New Zealand Patrick

This week there have been various small core updates and fixes but the biggest change was to the installer in 3.0.191. Last week we removed all but the site-blank profile from the core, cutting in half the size of the core. And because of this, the installer now needed to provide more direction about downloading and installing other site profiles. So it now does that and it also links to a new page that describes all of the past and current site profiles, along with additional details on how to create and install site profiles. Speaking of creating site profiles, the Profile Exporter module was also updated this week. It is now PW 3.x exclusive and is updated to recognize and work with various aspects and $config properties that are specific to 3.x. ProcessWire 3.0.191+ and the Profile Exporter module now support a custom /site/install/finish.php file which is a template file that is called when installation of a new ProcessWire and site profile has finished, but before it has cleaned up the installer. It is a plain PHP file that has access to PW's API and the installer, so it can do pretty much anything you could do from a regular template file or module. I added this because I noticed a few issue reports for the Profile Exporter module were requesting support of one thing or another, and I found that nearly all of them could be added just by having a profile-specific finishing file, for those that want it. So if you want your site profile to perform any other types of customizations on top of what you can already do with a site profile, this is the place to do it. This is where things are at this week but perhaps we'll continue to go further with the installer in supporting more things too in the new year, as there have been several good ideas. Thanks for reading and I hope that you all have a Merry Christmas and/or Happy Holidays!

Hi, I used this one a lot, but before you go further with it: It has one disadvantage. You have to use one type for all fields (subfields). So, pretty fine to use textarea for text and textarea, but there is already a new fieldtype out that makes the textareas obsolete. It is called Combo and since yesterday available in version v6beta. As you said: So.Many.Options! ? The only part that seems to be different, what I got so far til now, (started exploring / reading with / about COMBO two weeks ago), is a difference with searching / finding results in multi language sites. Whereas all (?) other (text)fields have a sort of scoped language pools where the search engine by default only searches in one language, the current active language, with the Combofield this is not possible. With other fields you can manage from the API site to search in more than one language of course, or in another then the current language. So ATM I stuck at if I should call this an advantage of the Combofield (in some situations) or more a disadvantage. At least, ATM it seems a significant difference that needs attention when planning a sites field setup in multi language sites with FE search functionality. S.M.O!

@ErikMH Great question. I think elabx has pretty much covered the repeater and table options - both of which work really well. So I'll skip these and just mention a couple of other possibilities, both of which I've used in various sites (in addition to the table and repeater fields) Child pages Repeater Matrix Child Pages It might be possible, depending on you application, just to use child pages to house your set of related items. This won't be the case if you intend using the page url structure for something specific on your site, but if you aren't then you can set up a template per type (one each for purls/orcids etc) and use the template family relationship to restrict the parent-child relationship as needed. Thereafter you would just add child pages to each of your organisations. I use this method in my little invoicing system for the payment methods accepted by each of my personas: Output in the API is simple, just iterate over each of your page's children to produce your output: Repeater Matrix If you have access to the ProFields package, this is probably slightly easier than using regular repeaters as you get to specify the allowed "types" of the items when constructing the field. I also find the interface more intuitive than normal repeaters and the rendering is particularly nice as it allows each item's code to be in its own PHP file. In the case you mentioned (Organisation with 0-n links or IDs of vaious types) I would probably go with a repeater matrix or the Table field as mentioned by elabx.

I don't think there is a "best practice" written down somewhere for this sort of scenario. I agree it can be confusing to figure out the "right solution" when there would seem to be so manyw ays to achieve the same. If all the values from the identifier are okay with being a text type value, I would go with a Table field with two columns, a Page Reference that fills its options with the "catalogue" of "possible IDs" and a text field that acts as the field for the actual value, this way you can have whatever fields you want on each organization, and you can do stuff like: $pages_with_purls_identified_orgs = $pages->find('template=organization, ids_table.id_type.name=purls'); This also guarantees you can also add new identifiers in the future very easily and consistently. You could do almost exactly the same with repeaters. Why table and not repeater? I just prefer the interface of the table field, I think it's less clunky visually when few fields are involved and has a more snappy feel. If each identifier would need more data added, I'd go for a repeater, but since it seems it's just an ID name and the actual value, table field seems enough. Repeaters would also have the "overhead" of loading an extra page on memory per repeater, since each repeater item is a processwire page. Although another scneario, what if the value of each identifier is a different type, then the table field would not work as nicely. Say you need DOI to be alphanumeric and ORCids to be integers, maybe for this case a repeater could work, with the same catalogue of identifiers, except that you create two additional fields (one text type, one integer type) and show them conditionally depending on the value of the page reference field where the type of identifier is selected. Please take this idea with a grain of salt, just something I came up with right now. It might be a hassle to manage the relationship of "identifier - type of value" on the actual code, or it might be worth the trouble, or there might be a better solution out there ?

Something I've done that is quite useful is setup a Less parsing library like this one that accepts variables and then I pass the variables on to the rendering pipeline, this keeps my styles files clean from php code: Pardon the dirty code: <?php $variables = array( 'main-color' => $home->main_color , 'body-background' => $home->color_main_background, 'icon-colors' => $home->color_icons, 'menu-icon-color' => $home->color_menu, 'footer-gradient' => $home->color_footer_gradient, 'go-top-gradient' => $home->color_got_top_gradient, 'slide-background-color'=> $home->color_slides_background, 'slide-hover-background-color'=> $home->color_slides_hover_background, 'h2-titles-color'=> $home->color_h2, 'headings-font'=> $home->headings_font, 'footer-background' => $home->color_footer_background ); //Set up main file path and directory of imports. $less_files = array( $mainCssFile => $config->paths->templates . 'css/' ); $options = array( 'cache_dir' => $config->paths->assets . 'cache/less/', 'output' => $config->paths->templates. 'css/build.css', 'relativeUrls' => false, "strictMath" => "on"); try{ $css_file_name = Less_Cache::Get( $less_files, $options, $variables); }catch(Exception $e){ $log->save("less", $e); } ?>

I am glad that I found this thread. BitPoet´s examples of how to use a page for css is working really great. It let´s me change specific css attributes on the fly on any template file. Also another great example of Processwire's flexibility with "everything is a page".

Another thing you might be interested in is using ApiGen to generate docs for core. PW is fairly well documented in code apart from some places, and you'll find most of what you need there.

You might also find this useful: echo $fieldtypes->implode('<br />', 'name'); It will list out the names of all installed fieldtypes, both core and those from site modules that you have installed.

I suggest not extending the User class, and instead plugin to it with a module class UserExtended extends WireData implements Module { public static function getModuleInfo() { /* return your array here */ } public function init() { $this->addHook('User::sendThankYou', $this, 'sendThankYou'); public function sendThankYou($event) { /* do something */ } } The above would add a sendThankYou method to all User instances. Your sendThankYou method can gain access to the $user the method was called on like this: $user = $event->object; Your sendThankYou method can also have one or more arguments if you want it to: $arg = $event->arguments[0]; If you want your sendThankYou method to return a value, do it like this: $event->return = 'value you want to return'; Looks like Antti beat me to it.

The $page->created and $page->modified properties are meant to be internal and consistent with actual page creation and modification dates in PW, so they aren't things that can be modified by the API. While you can go directly in and modify it with SQL, it's better to create your own properties using PW date fields. There's nothing that you can't do with your own fields that you can do with those internal created/modified fields. However, at present, I don't think it does any harm to modify them in SQL, but just saying that it's not a best practice.