Leaderboard

to @Ryan and dev team. It has happened that I've started development of notification system for users and found that there is already SystemNotifications module and related classes in core. Before development of own bicycle I've decided to check if it is required) and/or use a chance to add few wishes at moment when this module is under development. Please could you share thoughts/plans on the following: 1. currently flags in Notification are protected static. It limits possibilities to extend class by adding custom flags and handlers for these flags in FieldtypeNotifications. For example, notification flags for SMS or messengers, like Telegram. They can (and probably should) be handled in FieldtypeNotifications in the same manner as emails. At my site I use both SMS and Telegram notifications. Also, I think preferred notification methods should be set by (or for) user. 2. emails (as well as other "contacts" like cellphone number for SMS, etc) could be taken from different user fields, depending on some condition. In my system for example, sales managers roles need to get internal emails to corporate emails while being users, they get emails from system email field. E.g. "contact fields" should be customizable and/or hookable. 3. currently notifications are removed as soon as user closes them. There could be notifications that require action(s) (e.g. changes at some page); while these actions are not performed, notification should remain. E.g. it is some form of "todo" notification controlled by the system. Also there could be actions which can not be controlled by system, e.g. user should either confirm "done" or "cancel" or "postpone" them manually. Do you consider such "to-do" notifications as something that should be developed separately OR you think that they may be realized in the scope of SystemNotifications? 4. currently at UI level notifications are injected through predefined core js/css and predefined admin DOM structure. This limits possibilities to make notifications UI different. For example, I'd prefer to give my users "Facebook style" icon & attached notifications menu. Is it possible to leave hooks and/or module config params that opens a space for js/css replacement/adjustment and possibly more admin DOM extras (like adding menu items)? Thank you!

Currently we're catering for this need with Markup modules, site profiles, and to some extent Textformatters. In my opinion these are all "easy ways to share design". If these are not enough, you could also share template files and smaller snippets of code, but considering that each site may have different fields in place, that only works as long as you also standardize those fields. There has been some discussion about this too, but more as a community project than something the core should take part in. If you're using the devns branch, there are also field-level template files. These would be much easier to share between different projects, so I'd suggest taking a closer look at them. I've built quite a few sites using ProcessWire, ranging from very simple one-page sites to news and intranet sites with (tens of) thousands of pages. I've never felt that the API "only works for simple websites". Admittedly I've used SQL on some extremely rare occasions, but that has mostly been due to the fact that I've either had a custom database structure too, or I've needed to optimize a potentially slow query for just one very specific task. Assuming that the API is awesome for *at least* 95% of use cases (that's my impression anyway), I don't really think we can state that it's "not good enough". For use cases that a few people here and there might face in some rare situations it's entirely acceptable to figure out a custom solution. Just checking, but you do realize that you could easily add a custom queryArray() method to $pages API var and even publish your solution as a module if you feel that it has potential for wider use, right? That being said, I'm not against this feature per se. It's just that every added feature also adds complexity and the core absolutely shouldn't contain features that are known to be used extremely rarely (not entirely sure if that's the case here, but based on my experience so far it very well might be.)

thats.sound like hole diffrnt cms no ? WirePress why sholud pw main stream ? pw is seaworthy.vessel not canooe for stream

@Horst Thank you for this module. I've hit the anti-aliasing problem in watermarkText() you mentioned back on page 2 of this thread (I'm using PHP7). This fixed the issue for me... if (function_exists('imageantialias')) { @imageantialias($im1, FALSE); }

Hi Pierre-Luc, First of all the module is working great for me at the moment. I haven't pushed it to hard yet but has done everything I've asked of it so far. I have hit a small issue with mailgun and their complaint system and API. If people didn't know. If an email recipient accidentally(or on purpose) clicks the "junk" mail button it sends a complaint to Mailgun and they then block you from sending mail to that address, unless you clear/delete the complaint through the API. As I'm somewhat new to web development, it's hard for me to understand how to even get started. I was wondering if you or anyone had plans to add a way to administer the complaints from this module? or to check for complaints and delete any that are there before sending the email? Cheers

You're welcome! Let me know if you need additional features that would fit into this module.

@joer80, I split your post (and replies to it) into a new thread since it was going off on a tangent in relation to the contents of this thread. The new thread (couldn't find an apt title - feel free to change it) can be found here: https://processwire.com/talk/topic/12765-distinct-pages-api-split-topic/ Let's continue your discussion there.

Our main audience are currently web designers/developers that require a platform that does most of the heavy lifting for them, but allows them to freely modify data structures, markup, and even back-end functionality of their sites. WordPress, on the other hand, is famous for trying to cater for all kinds of users – even those who don't ever want to touch or see any code *or* markup at all. As a result they're not particularly good at anything and just trying to keep their current codebase in good shape seems to be nearly impossible task. I'm not saying that ProcessWire is already as good as it can get – quite the contrary. We've taken huge steps in so many ways in just a few short years and will no doubt continue doing so in the foreseeable future. The point I'm trying to make is that "converting all WordPress websites over" isn't necessarily a goal worth striving for. At the very least that's not what motivates me personally. Correct. Site profiles provide a starting point, and after installing one of those you can customize your site as you see fit. While I have no idea what you mean by "making it custom", the thing is that site profiles in general are not interchangeable like WordPress themes. This is what I was referring to in my previous post: we've had some discussion about agreeing on specific fields, based on which we could develop interchangeable themes. Not entirely sure what's up with that project right now, but it sounds like this might be something you'd be interested in pursuing too. Actually you could make any module output styles, and some modules already do that. Some existing options include using the $config->styles or $config->scripts arrays (though they also need to be included in your markup somewhere), altering generated markup with a page render hook, and simply outputting styles or scripts in the middle of generated markup. I'll have to agree that these may not be exactly clean solutions at all times, but on the other hand, have you ever debugged a WordPress site with a ton of plugins adding their own styles/scripts? Trust me, "clean" is not how one would describe that either In my opinion this is a very cool idea, but absolutely not something the core should do. Without going into specifics, nothing you've mentioned so far can't be done with a third party module. If this is something you feel is missing from ProcessWire, feel free to give it a try. You might even find some like-minded people here who'd be willing to help. In some ways I'll have to agree, but it's really not that simple. WordPress a) was around at the perfect time, b) decided relatively early to cater for the needs of everyone out there, c) doesn't care about how they're perceived by the technically adept audience, and d) doesn't care how much technical debt they amass in the process. I don't think that any platform can really take them head-on when it comes to number of users: at this point their popularity is also their biggest asset (assuming that "being the most popular platform out there at any cost" is really a sensible goal.) Agreed, and we *are* already expanding our audience. You haven't missed the Composer stuff we've been adding lately, have you? It's just that we've been aiming for expanding our audience to a slightly different direction than you had in mind I hate repeating myself, but I'll do it anyway: build a module. Publish it. If it's awesome and a lot of people love it, it has a good chance of becoming a core feature one day.

Extra! I've used a PHP snippet and it works well! Tranks a lot, I even not know this possibility... great I'm always amazed how PW can be customized to match any project!!! And if it can help someone else, the snippet in my case: // Toutes les villes $all=$pages->find("template=ville"); // Conseillers avec 1 ville principale $conseillers_linked=$pages->find("lien_ville_principale.count>0"); // Suppression des villes liées foreach ($conseillers_linked as $item) $all->remove($item->lien_ville_principale); // return villes non liées return $all;

You can use the php selection for the pagefield and remove all cities. which are already linked.

@reno Yep, it also respects the $config->pagefileExtendedPaths setting, e.g. it creates a folder for each page ID or a nested folder structure, if the setting is enabled. Cheers

MediaLibrary Update: MediaLibrary can now be found in the official module list. Out of necessity, I've started to implement a simple media library module. The basic mechanism is that it adds a MediaLibrary template with file and image fields. Pages of this type can be added anywhere in the page tree. The link and image pickers in CKEditor are extended to allow quick selection of library pages from dropdowns. In the link picker this happens in the MediaLibrary tab, where you can also see a preview of the selected image. In the image picker, simply select a library from the dropdown at the top, everything else is handled by standard functionality. I've put the code onto github. This module is compatible with ProcessWire 3. Steps to usage: Download the module's zip from github (switch to the pw3 branche beforehand if you want to test on PW 3.x) and unpack it into site/modules Click "Modules" -> "Refresh" in the admin Click "Install" for MediaLibrary For testing, create a page with the MediaLibrary template under home (give it an expressive title like 'Global Media') and add some images and files Edit a differnt page with a CKEditor field and add a link and an image to see the MediaLibrary features in action (see the screencap for details) Optionally, go into the module settings for MediaLibrary Note: this module is far from being as elaborate as Kongondo's Media Manager (and doesn't plan to be). If you need a feature-rich solution for integrated media management, give it a look. Feel free to change the settings for MediaFiles and MediaImages fields, just keep the type as multiple. There are some not-so-pretty hacks for creating and inserting the correct markup, which could probably be changed to use standard input fields, though I'm a bit at a loss right now how to get it to work. I've also still got to take a look at error handling before I can call it fit for production. All feedback and pointers are appreciated (that's also why I post this in the development section). Edit 09.03.2016 / version 0.0.4: there's now also a "Media" admin page with a shortcut to quickly add a new library. Edit 01.05.2016: Version 0.0.8: - The module now supports nested media libraries (all descendants of eligible media libraries are also selectable in link/image picker). - There's a MediaLibrary::getPageMediaLibraries method you can hook after to modify the array of available libraries. - You can switch between (default) select dropdowns or radio boxes in the module configuration of MediaLIbrary to choose libraries. Edit 10.10.2018: Version 0.1.3: - Dropped compatibility for ProcessWire legacy versions by adding namespaces - Allow deletion of libraries from the Media overview admin page - Added an option to hide media libraries from the page tree (optionally also for superusers)

Media Manager Released 31 March 2016 https://processwireshop.pw/plugins/media-manager/ Documentation http://mediamanager.kongondo.com/ As of 10 May 2019 ProcessWire versions earlier than 3.x are not supported ******************************************************* ORIGINAL POST ******************************************************* API Example (frontend; will be added to documentation site) Accessing and outputting the contents of the MediaManager field(s) in your template is quite simple. The fields are accessed like many other ProcessWire fields. The fields return an array of type MediaManagerArray that need to be looped to output each media within. Assuming you created a field of type MediaManager named 'media', you can loop through it for a given page as shown below. @note: Each MediaManager object has the following 5 basic properties: DATABASE (saved properties) 1. id => pageID of the page where the media lives (hidden in admin and not important to know about) 2. type => integer denoting media type (1=audio; 2=document; 3=image [for variations this will be 3x, where x is the number of the variation of an original image]; 4=video) RUNTIME 3. typeLabel => user friendly string denoting media type (audio, document, image, video) 4. media => a ProcessWire Image/File Object including all their properties (ext, filesizeStr, height, width, description, tags, filename, basename, etc.) 5. title => title of media (@note: this is the title of the page where the media lives; may or may not be the same as the name of the media file itself). This can be used as a user-friendly name for your media $media = $page->media;// returns a MediaManagerArray. Needs to be looped through foreach ($media as $m) { echo $m->id;// e.g. 1234 (hidden page in /admin/media-manager/media-parent/) echo $m->type;// e.g. 3 (a media of type image) OR 1 (a media of type audio) echo $m->typeLabel;// e.g. 'document' (i.e. type would be 2) echo $m->title;// e.g. 'My Nice Trip' (whose media file could be my-nice-trip.mp4) /* @note: - $m->media returns an object; either a ProcessWire Image (for image media) or File object (for audio, document and video media) - This means you have access to all the properties of that object, e.g. ext, tags, description, url, filename, basename, width, height, modified, created, filesize, filesizeStr, etc as well as associated methods, e.g. size() */ echo $m->media->tags; } // only output images foreach ($media as $m) { if($m->typeLabel =='image') { echo "<img src='" . $m->media->size(100,75)->url . "'><br>"; } } // There's also a toString() method so you can do: echo $page->media; /* All your media will be output wrapped in appropriate HTML tags, i.e.: audio: <audio></audio>; document: <a></a>; image: <img>; video: <video></video>; */ ******************************************************* ORIGINAL POST ******************************************************* The topic of a central media manager feature for ProcessWire has come up several times: https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/ https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/?p=42578 https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/?p=42582 https://processwire.com/talk/topic/425-file-manager/ https://processwire.com/talk/topic/425-file-manager/?p=13802 https://processwire.com/talk/topic/425-file-manager/?p=13861 https://processwire.com/talk/topic/10763-asset-manager-asset-selector/ More recently, regarding my Visual Page Selector module, I have been asked several times why the module does not have an in-built feature to upload images. There's two camps on the topic of a central media manager: those who like them (especially those coming in to PW from other CMSes) and those who don't like them (primarily because of the chaotic way some CMSes (dis)organise their media management) . I think that we can have our cake and eat it too! If done the right way, closely following the principles of and harnessing the power of ProcessWire, we can have a well-implemented, organised, feature-rich, site-wide media manager. Introducing Media Manager: (a commercial module) Alongside a number of modules I am currently working on (both free and commercial), I have been developing a centralised Media Manager for ProcessWire. Before you cast the first stone, no, this is not going to be a one-large-media-bucket as in other CMS where it gets very messy very quickly . In the backend things are neatly stored away, yes, in pages. However, those are pages you will not see (just like repeater pages). Before anyone has a go at pages, remember a page is not that thing you see on the ProcessWire Tree (that's just its visual representation); A page is a record/row in the database . For the end-user of Media Manager, all they will see is the 'familiar media bucket' to select their media from. As long as it works efficiently, I don't think they care about the wizardry behind the scenes . The module allows for the comprehensive management of several media types: Audio Video Images Documents Each media type will be handled by its own sub-module so the user can pick and install/choose the type of media management they want. Features include: Access controls Centralized uploads of media Bulk management of media: tag, delete, describe, replace, etc. Bulk upload: zip; scan, single Quick upload in page edit mode Usage stats across pages (maybe?) Etc.. Would love to hear your thoughts and any feature suggestions. I think there's enough demand for such a module. If not, please let me know so that I can instead focus on other things , thanks. How other CMS do it The more efficient (PW) way of doing it

This is a simple module to prevent guest users and search engines from accessing to your site. Primarily it is designed for use during site development. Modules directory: http://modules.processwire.com/modules/protected-mode/ Github: https://github.com/adrianbj/ProtectedMode Install and check the "Protected Mode" checkbox Create a user with only the guest role and give the login details to your clients/testers. Of course existing admin users can use their personal logins still. There are some similarities with Pete's excellent Maintenance Mode module, but the reason I built this, rather than using Maintenance Mode is: I didn't want the "Maintenance Mode" badge showing up on the site since this is for development before a site has ever been live and I didn't want the client seeing that badge. I didn't want users redirected to the PW login page because I didn't want visitors to see the PW login page. I know the module has the option to redirect to a custom page, which you could use to make a front-end login form, but that seemed more complex than I needed (and I think other PW devs might also need). Because of the way this module replaces Page::render with the login form, visitors can be sent to any page on the site, and once they login that page will reload with its full content - no messing around finding the page again, and no need for sending page ids through the login process to redirect back. This module also lets you configure the message that is displayed along with the login form, and also apply some css to style the login form. Hope you guys find it useful.

Support thread for WireMail Mailgun. For bug reports, please use the bug tracker on GitHub. https://github.com/plauclair/WireMailMailgun

A ProcessWire Fieldtype storing files in a customized location, outside the web root. This module is primarily useful if you need to store sensitive data which should not be accessible directly from the web. Normally, ProcessWire stores all files under /site/assets/files. Direct URL access to these files can be restriced by setting $config->pagefileSecure = true. Still you need to make sure that your template permissions are setup correctly. If something goes wrong, those files could be accessed from outside. GitHub: https://github.com/wanze/FieldtypeSecureFile Modules Directory: http://modules.processwire.com/modules/fieldtype-secure-file/ How does it work? After installing this module, you can create a new field of type SecureFile. Enter your configuration under the "Details" section when editing the field: Storage Location Enter a path outside the web root where the files are stored. You need to create the directory manually. Also make sure that the user running the web server has write permission. Roles allowing to download a secure file Users with a role selected here are able to download the files if a download is requested via the API. Allow Download in Admin If checked, users having a role selected above can download the files when editing a page. I needed this functionality for a recent project, so I created this module and thought to share it, mabye this is useful for someone else Consider it beta, I'm using it on one site but I'm sure it could be improved here and there. Feel free to suggest additional features! Cheers

It would be fantastic if we could set different configurations for CKEditor fields based on template or user roles. Like described on https://weekly.pw/issue/14/ under "More CKEditor upgrades", we can use config files in /site/modules/InputfieldCKEditor/ to store settings per field. E.g. for the body field this would be /site/modules/InputfieldCKEditor/config-body.js. Maybe this logic could be extended to something like /site/modules/InputfieldCKEditor/config--field-body--template-home--role-mycustomrole.js. I was coming over from Joomla to PW couple of years ago and there we had an excellent CKEditor integration called JCE where you could define settings per user role etc. Maybe I am wrong but up to now we need to create additional fields if we need editor config settings per template. If there already is a way to do that I'd be happy to know.

hello! I created a new site for my podcast Machines-ethics.net and thought I should create a version for anyone to use. With PW-podcast profile you can create one or more lists of pages with content and create one or more itunes RSS feeds to syndicate your podcast (as well as listening online). There is also a blog section and basic pages for anyother page you need. Check out the example site here: http://pw-podcast.nicegrp.com/ and the github here: https://github.com/benbyford/pw-podcast

I'll have to look into Mailgun's webhooks API, and see if it's possible to get incoming notices from this. The stats sometimes take some time to update, but never really long. If you really want to see what's going on, the Logs tab on Mailgun is much more efficient and is pretty much instant. I would really recommend that you do set your SPF and DKIM, as there are a bunch of penalties on accounts who don't.. https://documentation.mailgun.com/quickstart-sending.html#verify-your-domain

Perfect. I have a few different scenarios right now that need secure files. I think this module will handle at least one of them seamlessly. Much appreciated Wanze!

Just use httpUrl instead of url.

I think this is down to the blog-posts being applied to 2 pages. Both Blog and Posts are using this template so that's my mistake!

Thank you for the good news! (and the fix)

hi kongondo, which version do you use? Try upgrade to 1.1.2: apeisa already solved that bug.

You want something like this?: http://codepen.io/Da-Fecto/pen/aNppXr

Give the footer a position relative and change, on the featured, the negative top to a negative margin. .footer { background: blue; position: relative; top:0; height:200px; } .featured { background: yellow; width:500px; height:420px; margin:-200px auto 0; position: relative; }

Thanks for the ideas. @mr-fan: I think this might be the sort of thing you're hinting at - at the top of the widget templates... <?php if( empty($options['pageStack']) ) throw new Wire404Exception(); ?> Good info in this post from Jonathan Lahijani here and some info on pageStack from Ryan here. I like this solution. @LostKobrakai: Sounds like this would work, but it seems to me there are downsides to using wireRenderFile() over $page->render(). I have a lot of different widget templates and widgets are selected by editors via a page field, so using $page->render() keeps the rendering code really simple and maintenance-free. foreach($page->widgets as $widget) { echo $widget->render(); } But if I use wireRenderFile() I need a whole chain of logic to check the template of each widget and render it with the correct file for that type of widget. Besides avoiding partial pages being directly viewable, are there other benefits of wireRenderFile() that make it preferable to $page->render()?

Yep. It's essentially moving the files folder to a non accessable folder. Everything inside the folder does stay the same.

With Standard Processwire Installation you have the option to configure SetupPageName (childNameFormat) under Tab Family in the Parent Template, which allows you to derive (auto assign) the name from title. Until now this is not possible with id. But you could use the following module which extends the SetupPageName function exactly for your needs. http://modules.processwire.com/modules/process-setup-page-name/ Unfortunately this module doesn't work properly in multilanguage surrounding. If you want to use the Field in multiple pages it might by better to use a Page field instead of PageTable. If you define Parent and Template in the field settings you can add a new Page from the field too. Pages in PageTable Field must be created/ deleted from Field.

If you want to install processwire on cloud server you may simply follow the guideline

Welcome to the forum Atif, thanks for the guideline and thanks again for the nice interview with Ryan.

To not copy my suggestion again: https://processwire.com/talk/topic/12409-prohibit-view-of-pages-with-certain-template/ I'd really refrain from using $page->render() for rendering partials in favor of wireRenderFile().

Pseudocode from my Phone... If page->template = widget Perfom a 404 error Have a search with Google on the forum About 404 errors and hiding Pages in Frontend... Regards mr-fan

"In addition, fields using a type of Repeater or PageTable are not currently supported for drafts (though support is planned). " https://processwire.com/api/modules/prodrafts/#drafts-and-fields

There could be a situation where you want a Page with the following: it's published it's hidden it's template has a php file it SHOULD NOT be available to viewed on the frontend using it's URL Now you might be thinking "Well if you don't want it to be viewable on frontend, then just delete the template php file!"... however the purpose of wanting to have a template file could be for partial/section rendering. This is a pattern that I personally like to use. Here's a perfect example... let's say you have a page called "About Us" and it has 3 sections that make up the page. Based on how you want to structure that page, you decide that those 3 sections will be stored each as a child page of the "About Us" page, but when the "About Us" page is viewed, the page is built based on those 3 child pages (using a simple loop). So, we can give this as an example: /about/ (about.php)/about/philosophy/ (section-type-1.php) /about/mission-statement/ (section-type-2.php) /about/some-other-section/ (section-type-1.php) and in about.php, you might have something like this (using direct output)... <?php foreach($page->children as $section): echo $section->render(['prependFile'=>'']); endforeach; ?> and in section-type-X.php you would have just your partial markup: <section class="section-template-<?php echo $page->template; ?>"> <header> <?php echo $page->title; ?> </header> <?php echo $page->body; ?> <!-- etc... --> </section> So the above works fine, but those child pages can still be accessed if the direct URL is known. The way around this is one of the following: Option 1: In the partial file, detect if the page is being hit directly, as opposed to being rendered from another template like we are doing. If it it being hit directly, then redirect somewhere or throw a 404. You could do that by adding the following to the top of section-type-X.php. <?php // the pagestack is empty, which means the user hit this template file directly. if( empty($options['pageStack']) ): throw new PageNotFoundException(); // show 404 page endif; ?> Option 2: Don't assign an actual template file to the section templates. Instead, use a partial file approach So, you would rename section-type-X.php to _section-type-X.php (notice it starts with an underscore). Then in about.php, you would use wireRenderFile/wireIncludeFile. But now that I think about it, how would you best associate a section page with a template? -- Anyway, hopefully the scenario I outlined above helps someone. This occurrence, perhaps unbeknownst to @teppo may be happening on the weekly.pw site. For example, if you Google for just one Issue (let's say #32), you get the URLs not only to Issue 32, but the page sections that make up that issue: https://www.google.com/search?q=site%3Aweekly.pw%2Fissue%2F32%2F Results: https://weekly.pw/issue/32/ https://weekly.pw/issue/32/latest-processwire-core-updates/ https://weekly.pw/issue/32/new-module-service-ip-geolocation/ https://weekly.pw/issue/32/processwire-resources-of-the-week/ Is that a bug Teppo? You may get docked for duplicate content depending on how you are handling canonical URLs.

CSS awesomeness! Enter this into the "Text color" field in the module settings: transparent; width: 70px; height: 70px; border: none; background: transparent; border-radius: 100%; overflow: hidden; padding: 0; margin-right: 0.7em; color: #aaa Also set the first field value to "70,70". No matter what you write elsewhere, the code above will overwrite it.

The module is working quite nicely, but I cannot click on the file in the backend anymore even though I'm superuser and editor, which I gave download from admin rights. Edit: Would it be possible to look at the ListerPro styling for the field?

I also change line 63 in the module to: $storageLocation = $this->wire('config')->paths->root.rtrim($field->get('storageLocation'), '/') . '/'; So my secure file path is relative to my web root: eg: ../secure_files/ Which is just one level down from my web root, and is easily configured on most shared hosts. Just saves a bit of time working out absolute paths on shared accounts. Might be an option within the module to select "Relative path to Processwire root" or "Absolute Path"

Ok, how's this work for you? http://modules.processwire.com/modules/process404-search/

Try adding this to the top of your /site/templates/admin.php, after the opening <?php tag: $pages->addHook('saveReady', null, 'makePageHidden'); function makePageHidden(HookEvent $event) { $page = $event->arguments(0); if($page->template != 'category-site') return; // replace 'category-site' with your template name if(!$page->is(Page::statusHidden)) $page->addStatus(Page::statusHidden); }

Hi, I've been struggling with building forms with the API this week-end. How would i translate the form errors messages (Missing require value...) ? Thank you.

The "missing required value" string is translatable in the file /wire/core/InputfieldWrapper.php. For your language pack, you would add this file as a translation target.

In future versions of ProcessWire, including the current PW 2.3 dev branch, you can also do this: if(count($options['pageStack'])) { // don't include header/footer, etc. } $options['pageStack'] is an array of pages that called render(); before the current one. It basically gives a way for a page to discover the context it is being rendered in.