All Activity

@mel47, currently the PW core does not support showIf or requiredIf in custom fields for files/images. See this issue: https://github.com/processwire/processwire-issues/issues/1889 And even if that issue is resolved, the way the core is handling showIf/requiredIf at the moment means that it will only evaluate the showIf/requiredIf based on values of other custom fields for the image/file item, not fields in the page that is open in Page Edit. But I've just updated the CustomInputfieldDependencies module so that it should handle your case. Please update the module to v0.3.0 and test it again.

And all I can think is: "Wow... that's a super nice and clean backend he build there!" But yes. It can be confusing to see how simple (as in clean and streamlined) things can be.

You maybe remember my question regarding a "Headless ProcessWire" quite a few months back. The endresult with either GraphQL, JSON, RestApi, and any other solution based on ProcessWire looked almost exactly like that when I wanted to use that data in either 11ty or Astro - which I used a lot back then. So... yes, in plain ProcessWire this is a super simple no-brainer with 1 to 3 lines of minimal PHP. Yet, when using anything else as the frontend, aka JS Framework (React, Svelte, Astro, 11ty) we still would have to go that route in some way or another. Even with Hygraph, Payload, Directurs, and whatever Headless CMS out there - it would look like that. The part you attribute to Strapi here is not really about Strapi. It's more about the used frontend. So... a bit off. Probably more interesting and more comparable would be Laravel with Inertia JS (on the JS side of things) or Laravel with Livewire (on the side or similar to PW of things, from the creator of AlpineJS). For that matter I really enjoy those Laravel-related videos from Aaron Francis (the PHP is cool again - guy) and the 30 days to learn Laravel Workshop. Besides that we might want to ask better questions like: Why use a (static) JS Frontend? How to make PW more compatible with JS Frontend Frameworks?

Hello, That was my first guest, but it didn't work. However it finds the good page. But then, the field is not appearing. Image from page 1042 is without publication_date field : I'm not sure if I don't have the good syntax or if it's a limitation? Thanks.

Hello, I'm stuck since way too much time for something probably easy... I have those pages and (templates) -Home -> Existing page on website --About us (section) ---Committees (basic-page) -> Existing page on website ----Executive (section-admin) -----Member 1 (member) ---Awards (basic-page) -> Existing page on website ----Prize X (section-admin) -----Awardee 1 (awardee) I have main.php and basic-page using regions, it works. However I fight on how listing members on basic-page. Do I should use the member/awardee template and render in basic-page? Or you I should use section-admin template and then, by children type, do some different markup? Thanks

@flydev Oh sorry, I got it now. 🙏🤦‍♂️ I followed the Readme without thinking. To call the module on all templates I have added it to the _init.php. Now it is working as expected. Ryans Prod module looks like a good alternative. For now, I do prefer the Blackhole module. It is lightweight, quick and easy to implement.

This week the core dev branch version remains at 3.0.239 but relative to last week, it contains several optimizations and improvements. Details can be found in the dev branch commit log. I've also moved two Textformatter modules out of ProFields and into GitHub and the modules directory. These include: Auto Links This Textformatter module automatically links your specified phrases/words to your specified URLs. This is a potential SEO and accessibility tool for creating automatic contextual links with little effort. If there are pages that you commonly link to in your site from your textarea/rich text fields, then this Textformatter can save you some effort, automatically linking to those URLs. Text Blocks This Textformatter module enables you to assign a name to any block/region of text in a Textarea field. They are defined by typing start_name where you want the block to start, and stop_name where you want the block to stop. The block(s) of text can then be shown in any other Textarea field at runtime (site-wide) simply by typing the block name on its own line in the format show_name. Note that the word "name" in all of these examples would be whatever you've decided to name the block. Both modules have been updated just for public release with a new version. Both are considered Stable, as they have both been running without incident for several years. These modules were moved from ProFields to the public modules directory for three reasons. First is that they don't consume hardly any support resources, so they don't need to be commercially supported modules anymore. Second is that I'd like to keep ProFields focused more on field related modules (Fieldtype, Inputfield, and related) rather than Textformatter modules. Though admittedly the TextBlocks module does blur the line a bit, as it promotes potential greater reusability with existing Textarea/TinyMCE/CKEditor fields. Third is that there's already a lot in ProFields and I wanted to make room for new modules, such as the recently added PageEditChildren, which is part of ProFields at least in the short term. The FunctionalFields module may come out of ProFields well, as it hasn't required much in terms of support resources recently, though it is a useful Fieldtype/Inputfield module that is very much in keeping with the theme of ProFields, so I'm still debating on that one. Thanks for reading and have a great weekend!

Multi field support The latest version adds support for multiple PAGEGRID fields per page. This makes PAGEGRID more flexible when you want editors to control only some parts of the layout. Each field can use its own block templates: If you want to render more than one PAGEGRID field per page, you can call the render function for a specific field like this (assuming you added the fields named “mygrid” and “mygrid2” to your page template): <!-- render markup for field mygrid --> <?= $page->mygrid; ?> <!-- render markup for field mygrid2 --> <?= $page->mygrid2; ?> The old render function $pagegrid->renderGrid($page) still works, but it will always render the first field it finds. You can use $pagegrid->renderGrid($page, $field) or $page->fieldName to render a specific field. Custom code and markup You don’t have to write complicated foreach statements, PAGEGRID takes care of rendering clean markup. PAGEGRID wraps each item in a wrapper element. You can change the tag name or add custom classes to it easily. The rest of the markup is inside your block templates. Nice and clean. Add this function at the top of your block template file to change the wrapper element: <?php //The wrapper element of this block template uses the section tag and some custom classes $pagegrid->renderOptions(['page' => $page, 'tag' => 'section', 'classes' => 'my-class my-class-2 foo-class']); //Here goes your markup ?> CSS code It’s also easy to control the behavior of the grid using only CSS code (If you prefer to write your own CSS code or include a CSS framework, you can disable PAGEGRID‘s style panel): /* overwrite PAGEGRID defaults */ /* wrapper */ /* Use 6 equally sized grid columns */ .pg { grid-template-columns: repeat(6, 1fr); } /* items */ /* set both properties to auto */ /* let grid items take the available space */ .pg .pg-item { grid-row-start: auto; grid-column-start: auto; } /* or set only grid-row-start to auto */ /* items can still be positioned freely on the columns */ .pg .pg-item { grid-row-start: auto; } /* new items */ /* you can use this class to set the defaults for new items */ /* here we are overwriting the default size of grid items */ /* using this class makes sure you can still resize items with the PAGEGRID field */ .pg .pg-item-added { grid-column-end: span 3; /* let new grid items span 3 columns */ grid-row-start: auto; /* you can also change the placement here */ } You don't even have to use grid, flexbox or block also works. PAGEGRID makes no assumptions about your CSS code. Just make sure to call your stylesheet after you render the styles from PAGEGRID, so you can overwrite the defaults. Item Placement As a default dragged items will be placed manually on the grid. Manually placed items can overlap themselves. Here is a quick example, how the CSS properties grid-row-start: auto; and grid-column-start: auto; effect the dragging of grid items: Backend/Frontend PAGEGRID renders the same template in the backend (iframe) and frontend so the design will look the same. If you want to render only some parts in the backend you can use this check: <?php if( $pagegrid->isBackend() ) { // render things only for the backend } else { // render things only for the frontend } ?> For more examples check out the docs 🤓

Thanks @howdytom! I just answered on your github issue. Just in case you are not aware of, you can also find a Pro module made by @ryan that use mainly htaccess to kill bad bots. The Pros of RequestBlocker that is a Cons in Blackhole is the fact that agressive bots could degrade the server resources. sort of denial of service. Anyway, when used for example, behind a well configured reverse proxy or a service like cloudflare, the cons is really mitiged.

If you prefer one-liners: <?php // https://processwire.com/api/ref/wire-array/each/ echo $pages->find('template=faq')->each("<div><h2>{question}</h2>{answer}</div>\n"); 😁

Didn't you feel like you were reading a comic book, because it looked so easy and the code is so well written/commented? Ryan is so skilled you quickly realize that the tool is robust lol Just played with a chatbot that will be soon publicly available (need to ask ryan and mods) with some @MarkE text chunk from this thread :

@adrian @Robin S I didn't know about these features yet – many thanks!

If the developer of your website hasn't implemented such a feature, you won't be able to find it. ProcessWire will only let you do things that the developer thought were a good idea. And many developers will probably think that letting the client insert untrusted code is not a good idea... You'll find the code of the website on the server. Usually you can connect via FTP or some hosting providers have web based file management tools. From there it should be quite easy to find the file to put the code into. Usually it will be in the /site/templates folder. If you have a _main.php file there this will most likely hold the main markup of your website that all pages use. If not you can open /site/templates/home.php or /site/templates/basic-page.php and inspect the code there. If those files all have something like <?= include('sections/footer.php') ?> you'd put your markup in one of the included files that get's included by all templates.

Hey @JCVinso, Your admin looks perfectly normal. You see all the pages of the website. From there, you can edit them (hover → edit button). Can you explain what do you want to achieve? What can of options do you expect to see in the admin?

Hi, I have found myself updating a website for someone that uses processwire. never heard of it before. Used wordpress, shopify understand basic coding.. I can't for the life of me figure out how to even find the code or where to place it. This is what my admin looks like and I get nothing in way of pasting code.. ? https://photos.onedrive.com/share/77A3951E7273EC5A!102840?cid=77A3951E7273EC5A&resId=77A3951E7273EC5A!102840&authkey=!AKeXJ6fhXR4par8&ithint=photo&e=JqfLN3 Literally no options in the admin section, am I running a basic version or what is going on ? any help would be great.

Hey ProcessWire friends! @protro asked something about Strapi in another thread, so I did a quick research on how to build a basic frontend for content stored in Strapi and found this 20+ video on youtube: Now, don't get me wrong, Strapi is cool and all and the video is really great, but I couldn't help but chuckle thinking about how we do basically the same in ProcessWire. Here's our "epic" version: <?php foreach($pages->find('template=faq') as $faq) { echo "<div><h2>{$faq->question}</h2>{$faq->answer}</div>"; } Boom! Done in a few lines. No need for popcorn or a comfy chair. 😂 Cheers to simplicity and efficiency! 🍻 #ProcessWireFTW #KeepItSimple #LessIsMore

@teppo Thank you. This is fantastic.

As the error message says, check site/templates/_uikit.php on line 830. This file calls for data you've removed, therefore the error.

There's no such thing as an ignorant question, but in this case I would probably lean towards "unnecessary headache" 🙂 If ithe goal is to use some data from Strapi and combine that with some content produced in ProcessWire, this might make sense. E.g. the data from Strapi would only cover part of the project. But if the client wants to continue to manage all their content in Strapi and you'd just be using ProcessWire for the front-end, this would mean that you'd be mitigating much of what ProcessWire has to offer. Not to mention that it might be a bit of work to make the systems run smoothly together, and when things inevitably change in the future, you'd be doing every update to the content structure twice: once in Strapi, and again in ProcessWire. I'm not familiar with Strapi, but I'm pretty sure they have a decent API already (considering that it's a headless CMS that's kind of their bread and butter) so personally I'd consider building the front-end using something else. Laravel might be a decent PHP choice, but there are many other solutions as well. Most commonly folks seem to combine Strapi and similar headless systems with some JS framework, e.g. https://strapi.io/integrations/vuejs-cms. Anyway, that's just my opinion 🤷‍♂️

Hi PW forums This might me an ignorant question, but if the client has already built out their data backend using the headless CMS Strapi, could that data be fetched and used within ProcessWire on the frontend, or would this simply be an unnecessary headache ? My cursory understanding is that it would be possible, but would it be advised ? Thanks for your input.

Reactions is a module that collects reactions for pages from site users/visitors based on a click of a reaction button. It's basically the same thing as those "did you find the information you were looking for" thingies you see on some sites. An example of what the buttons might look like: There is also a very simple process module that displays pages along with their reaction counts for each enabled reaction type. GitHub repository: https://github.com/teppokoivula/reactions Modules directory: https://processwire.com/modules/reactions/ Needed this for a project and was kind of in a hurry, so it's not super polished, but seems to work well for basic use cases. One thing that's kind of fun (or scary) about this module is that it modifies the structure of the reactions database table automatically based on active buttons; this is done using ProcessWire's built-in features 🙂 Getting started You can install the module the usual way; clone or download the code, or install via admin. Or via Composer: composer require teppokoivula/reactions The easiest way to define available buttons is via site config: $config->reactions = [ 'reaction_types' => [ 'like' => [ 'title' => 'Like it', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="M720-120H280v-520l280-280 50 50q7 7 11.5 19t4.5 23v14l-44 174h258q32 0 56 24t24 56v80q0 7-2 15t-4 15L794-168q-9 20-30 34t-44 14Zm-360-80h360l120-280v-80H480l54-220-174 174v406Zm0-406v406-406Zm-80-34v80H160v360h120v80H80v-520h200Z"/></svg>', // optional attributes, either as an associative array or as a string, e.g.: // 'attrs' => [ // 'data-some-attr' => 'value', // ], // 'attrs' => 'data-attr="value"', ], 'love' => [ 'title' => 'Love it', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="m480-120-58-52q-101-91-167-157T150-447.5Q111-500 95.5-544T80-634q0-94 63-157t157-63q52 0 99 22t81 62q34-40 81-62t99-22q94 0 157 63t63 157q0 46-15.5 90T810-447.5Q771-395 705-329T538-172l-58 52Zm0-108q96-86 158-147.5t98-107q36-45.5 50-81t14-70.5q0-60-40-100t-100-40q-47 0-87 26.5T518-680h-76q-15-41-55-67.5T300-774q-60 0-100 40t-40 100q0 35 14 70.5t50 81q36 45.5 98 107T480-228Zm0-273Z"/></svg>', ], 'haha' => [ 'title' => 'Haha!', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="M480-260q68 0 123.5-38.5T684-400H276q25 63 80.5 101.5T480-260ZM312-520l44-42 42 42 42-42-84-86-86 86 42 42Zm250 0 42-42 44 42 42-42-86-86-84 86 42 42ZM480-80q-83 0-156-31.5T197-197q-54-54-85.5-127T80-480q0-83 31.5-156T197-763q54-54 127-85.5T480-880q83 0 156 31.5T763-763q54 54 85.5 127T880-480q0 83-31.5 156T763-197q-54 54-127 85.5T480-80Zm0-400Zm0 320q134 0 227-93t93-227q0-134-93-227t-227-93q-134 0-227 93t-93 227q0 134 93 227t227 93Z"/></svg>', ], ], ]; ... though you could also add them programmatically, e.g. if you wanted to manage them via admin: $wire->addHookBefore('Reactions::setReactionTypes', function(HookEvent $event) { $reaction_buttons = $event->wire()->pages->get(1)->reaction_buttons; if ($reaction_buttons->count()) { $reaction_types = []; foreach ($reaction_buttons as $reaction_button) { if (!$reaction_button->title) continue; $reaction_types[$reaction_button->name] = [ 'title' => $reaction_button->title, 'icon' => $reaction_button->icon && $reaction_button->icon instanceof Pageimage ? $reaction_button->icon->filename : null, ]; } if (!empty($reaction_types)) { $event->arguments(0, $reaction_types); } } }); The module has basic styles and scripts bundled in, though you'll have to load them yourself: <link rel="stylesheet" href="<?= $config->urls->Reactions ?>styles/reaction-buttons.css"> <script src="<?= $config->urls->Reactions ?>scripts/reaction-buttons.js"></script> ... and then call the render method to render the buttons in your template file(s): <?= $modules->get('Reactions')->renderReactionButtons() ?> For those interested in doing stuff like displaying something based on the answer, bundled JS triggers an event that you can listen to: document.dispatchEvent(new CustomEvent('reactions-updated', { detail: { pageID: pageID, reaction: reaction, }, }, { bubbles: true }));

There are also the new URL/path hooks: https://processwire.com/blog/posts/pw-3.0.173/

If the file vendor/autoload.php exists, it will be called automatically by ProcessWire's index.php. No need to call it manually.

Hi, We have a vendor folder in our project root directory. However, when we try to call the vendor/autoload.php file from the template file, we encounter the following error on the site: PHP Fatal error: Cannot declare class ComposerAutoloaderInit9249ca7144adea638e43f1ea4a5d11c5, because the name is already in use in C:\wamp64\www\ticf\site\assets\cache\FileCompiler\vendor\composer\autoload_real.php on line 5 please suggest how to fix this

Hey @netcarver and @gebeer great news for you (and all RockFrontend users) I've fixed an issue with ajax endpoints not replacing ALFRED markup (thx for the report @gebeer) and while working on that I got quite a lot of errors in the console about the livereload stream having a wrong mimetype, which has also been observed and reported by @netcarver some time ago. So I fixed that as well 🙂 Please try the latest version on the dev branch, which will be merged to master in some days. LiveReload only reloads the visible tab. This is to avoid endless loops where one window reload causes the other one to reload as well and vice versa. In older versions you had to reload the tab manually once you switched back to it. In the latest version it will wait and as soon as you switch back to the tab it will be reloaded automatically if a file changed in the meantime 🚀