Search the Community

Sounds like you can simply set a flag at runtime: <?php // your script that creates the json page $page = new Page(); ... $page->createdViaApi = true; $page->save(); Then your hook should be able to catch that flag: <?php $wire->addHookAfter("Pages::saveReady", function($event) { $page = $event->arguments(0); if($page->createdViaApi) { // check and throw exception } else { // check and show error to user } });

Nothing is required outside of your module - make your module autoload and use the init() method in your module. The filename is not a property that is saved to the database - it is generated at runtime from the template name, so if you want to set a custom filename then this must be done at runtime. The comment in the Template class is clear about this: @property string $filename Template filename, including path (this is auto-generated from the name, though you may modify it at runtime if it suits your need). #pw-group-files

I'm a little late to the game on this but wanted to throw out what we use on our PW sites. We keep all credentials in .env files in the root directory and then loaded using a package called phpdotenv. The .env file is loaded and then the credentials can be accessed at runtime via the $_ENV global. Some further details on this setup: .env files are automatically protected system files in Apache and will not be served (unless someone actively overrides this, but that would be bad). These files are not added to the Git repository and never stored. We have .env files for local, staging, and production. The contents of each file are stored in whole as a secure note in our password manager. The dotenv library is loaded once in config.php and the values are available globally. We also store credentials for external APIs and services. This allows us to store not only credentials, but any values that differ between local/staging/production. We store all of our config.php variable values in .env so that the config.php file is environment agnostic and we can always be sure that the .env is the single source of truth for the entire CMS configuration. We use Git to deploy to staging/production servers so using .env files allows us to push all of our code while knowing that sensitive information and data that changes between environments never gets mixed up. Also makes it very clear to anyone looking at the code that these values are stored in a dedicated system dot file. Here's the package, can be installed with composer https://github.com/vlucas/phpdotenv This is what a config.php file looks like with it in use: <?php namespace ProcessWire; // Load env variables from .env in root directory $dotenv = \Dotenv\Dotenv::createImmutable(__DIR__ . '/../'); $dotenv->load(); $config->debug = filter_var($_ENV['CMS_DEBUG'], FILTER_VALIDATE_BOOLEAN); $config->usePageClasses = filter_var($_ENV['CMS_USE_PAGE_CLASSES'], FILTER_VALIDATE_BOOLEAN); $config->useFunctionsAPI = filter_var($_ENV['CMS_USE_FUNCTIONS_API'], FILTER_VALIDATE_BOOLEAN); /** * Database Configuration */ $config->dbHost = $_ENV['CMS_DB_HOST']; $config->dbName = $_ENV['CMS_DB_NAME']; $config->dbUser = $_ENV['CMS_DB_USER']; $config->dbPass = $_ENV['CMS_DB_PASS']; $config->dbPort = $_ENV['CMS_DB_PORT']; $config->dbEngine = $_ENV['CMS_DB_ENGINE']; // Etc... Hope this might be useful to someone!

@Ivan Gretsky That part I know I can handle. It's the front-end JS side of it that I don't know a lot about, yet. I mean this just to suggest the possibility of establishing some sort of guidelines for how a developer might implement selective rendering. I don't know what those guidelines would be, and just use that GET var as an example of how a request might indicate a change for a particular field (named "body"). Trying to communicate that in the simplest example possible. The developer would decide what that meant in terms of output that should be produced. But perhaps this example is too far from the context, I'm still learning how this SSE stuff works. PW can't generate partial markup for anything (outside of the admin at least), so it would be up to the site developer to implement whatever methodology we suggest for this, at least if they want higher performance live updates. From what I can tell, htmx can handle both cases... replacing partial markup, or selecting a part (hx-select) from a larger portion of markup, like the full document. @kongondo Yes you are right, it wouldn't be very practical. But the benefits of selective markup rendering may be enough that it's worthwhile for us to establish some guidelines for supporting selective rendering. Like that ?change=body example earlier, that's what I was trying to communicate there even if it's likely not a good example. The guidelines could be as simple as just letting the site developer know when they can skip over expensive things to render, like primary navigation or footer, etc. Something like if($config->livePreview) { // skip rendering unnecessary primary navigation } else { // render primary navigation } I was actually thinking of "body" as a PW field name, and the developer would decide what that means to the output in terms of what should be replaced. But you guys have a lot more experience with htmx than me so I think my example is likely flying a little blind, as my focus so far as only been on the auto-save part that identifies field changes. I need to start playing with htmx. ? The way that ProDrafts live preview works is by having the editor window communicate to the preview window and notify it when a field changes (JS based window-to-window communication). The preview window does pull a fresh/updated copy of the rendered page, but it attempts to only replace the markup that changed. It does this by having formatted values for fields like "body" include an extra <div> around them that identifies what it is, and then ProDrafts can replace just that element with JS. You can see things as you type in the editor, with a short delay, unless your page is very slow to render. This works well for formatted text fields (which is usually most of what one wants to see in live preview), but it does have to refresh the full document for other things where the site developer may be responsible for more runtime markup related to the field output. @monollonom ProDrafts only reloads the whole frame as a last resort. For most cases it can update just what changed. This is helpful for avoiding a very visible and distracting page refresh. Such page refreshes kind of kill the live-preview effect and can more easily draw your attention away from the content you are working on. I don't know if it'll be necessary to introduce a 3rd party dependency or not (htmx), but it does seem like a good place to start, even if we end up rolling our own later. That's more the domain of ProDrafts, and PagesSnapshots (another module in development). I think any kind of core autosave and live preview will focus on just those features (autosave and live updated view) and making them as good as they can be. It might be that one only wants to use these features for unpublished pages, but I think that's where it is most useful in the first place. If you wanted autosave/live preview on a published page, you could always clone it and then replace the original (or not) when you were done. This is essentially how PagesSnapshots manages drafts.

I don't think this is right. My runtime Fieldtype is based off Ryan's Concatenate Fieldtype and that does not create a DB table. See also his comments in the code, e.g. this one. No database table is necessary.

Been getting a similar error on a custom runtime module. Only way around it is to specify a field/fields to fetch as in your example.

I was just trying to think if there was a way to achieve what I wanted without changes to the module. I saw that the module was adding the import/export features according to a permission so thought I might be able to grant that permission selectively at runtime. But I later realised that the permission is checked at the ready state rather than before the InputfieldTable render so even if my idea was possible I'd have to set the permission at every page load which would be a bit over the top. I think that a couple of extra checkboxes on each Table field config would be ideal - something like "Allow CSV export" and "Allow CSV import", although it would still depend on the user having the relevant permissions so there should probably be a note about that. Existing users of the module would expect to have these options checked on all existing fields and I guess you could deal with that in the module upgrade() method. Thanks!

Hi @Zeka, Yes, I am using $modules->get("MyModule") in my front-end template. I was just surprised to see MyModule get installed as a result of that code rather than throwing an error, which is what I was expecting. I've achieved my original goal of preventing the install in that situation but I've realised that I still need to use isInstalled() in my front-end templates to avoid runtime errors so, thanks.

Hey @Peter Falkenberg Brown I'm not exactly sure what you are trying to do, but if you want some kind of excel-like data listing (maybe with filter and sorting functionality) you can have a look at RockHitCounter which uses a quick and simple implementation of tabulator.info to list page hit statistics: https://github.com/baumrock/RockHitCounter/blob/main/ProcessRockHitCounter.module.php https://github.com/baumrock/RockHitCounter/blob/main/fields/table.php If you simply want to show aggregated data in the admin page edit then as @kongondo said you can use one of the runtime markup fields. Or a hook: // site/ready.php $wire->addHookAfter("ProcessPageEdit::buildFormContent", function($event) { $page = $event->process->getPage(); if($page->template != 'yourpagetemplate') return; /** @var InputfieldWrapper $form */ $form = $event->return; $f = $this->wire(new InputfieldMarkup()); /** @var InputfieldMarkup $f */ $f->label = 'My Markup Field'; $f->icon = 'exclamation-triangle'; $f->value = 'Dynamic Markup @ ' . date('Y-m-d H:i:s'); // insert dynamic field after the "title" field $form->insertAfter($f, $form->get('title')); });

I don't know homebrew, but to me it looks like the ini setting for "always_populate_raw_post_data" isn't (finally) set to -1. Have you checked it on runtime? The issue simply is, that you get a PHP warning as return of an ajax request, what then breaks your app (PW), as it expects another return, (a json object, and not a PHP server warning). You need to disable all php warning output, other then logfile, you need to check your ini settings for the mentioned setting on runtime, and / or you should set the mentioned setting on runtime too. Sometimes there are multiple php.ini files on a system, and it isn't quite obvious which one(s) are involved. So, additionally you may scan your filesystem for all php.ini files and explicitly set "always_populate_raw_post_data" to -1 in every file, if the runtime check shows that it isn't set to this.

Typically two choices if you want a custom 'view' in the admin. If custom view per page, i.e. as some sort of field / inputfield: have a look at the growing number of runtime markup fields in the module's directory A dedicated admin page view: You will need to create a custom module. More specifically, regarding data, and lots of it or spreadsheet-like data, have a look at @bernhard's modules and work in the forum. Looks like he has done extensive work in this respect. I am in a bit of a rush so cannot be more concrete. Hope this helps you get started.

Last week we released the new ProcessWire 3.0.184 master/main/stable version. This is our biggest version release in a year. It's been a very smooth stable version launch with no major issues so we're keeping the version number where it is this week. If you haven't upgraded yet, it's an easy and worthwhile upgrade. For full details see the blog post that covers it all. This week I have 3 new Textformatter modules released in the modules directory. These are modules that I developed earlier for recurring needs that I had, but this week decided to finish them up and release them. I hope that you might find one or more of them useful sometime. TextformatterFindReplace This module applies find/replace patterns to formatted text or markup at runtime. The patterns may be simple text or more complex regular expressions. This module can be handy if you perform a text replacement on all output from a particular field, without having to manually make the change on all instances where it might appear. For instance, maybe you need to insert a trademark symbol ™ after every appearance of a brand name, or maybe your website hostname has changed and you need to replace all references to it, or perhaps you need to replace all <h1> headlines with <h2> headlines. These are just a few examples of any number of possibilities. Read more / Usage / Examples TextformatterMarkdownInMarkup Enables you to use Markdown formatting codes in CKEditor (or HTML). A significant amount of content that is populated into the “bodycopy” field of websites is not actually written in the admin and instead originates from text editors, word processors, and other tools outside of the CMS. It then gets pasted into CKEditor, and then manually formatted into HTML using tools in CKEditor. This process of manually converting links, lists, headlines, bold, and italic text and more can be sometimes very time consuming. This module provides a time saving alternative, enabling use of markdown formatted text in CKEditor (or any HTML/richtext editor). It remains as markdown formatted text in the editor, but as soon as it is rendered on the front-end it is automatically formatted as HTML. This means that text like **this** gets converted to this, links like [this](https://processwire.com) get converted to this, and so on for most types of markdown formatting. This enables markdown formatted text to be written anywhere and the formatting to be rendered properly in your bodycopy when viewed on your website. Using this module means that you can mix richtext and markdown in the same copy. No longer do you have to manually convert all of the links, lists, bold/italic, and so on in pasted in text. This module saves me quite a bit of time when writing blog posts like the one last week. Much of the formatting in that post was markdown based, since I wrote the post in my text editor over a period of a couple weeks. Once I got it into CKEditor, I did some formatting with that too, but when it came to other formatting (especially links and inline `code`) it was a big help to have them just work, and not to have to re-do all of them manually with CKEditor tools. So why not just work exclusively in Markdown? Well I don't like working with just markdown most of the time, I much prefer CKEditor. But I also can't deny the convenience of markdown for a lot of cases too. So being able to use Markdown within CKEditor is the best of both worlds, to me at least. Read more / Supported markdown / Configuration options TextformatterEmoji This module converts more than 800 named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. ? This can be especially useful if your ProcessWire database uses the utf8 character set rather than utf8mb4, as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Though when you want to specify an emoji by name, this module will be useful regardless of your database charset. Read more / Supported emojis reference

Is there a reason why you cannot follow this same pattern in the present project? I can see how this will be painful in the long run. It is also prone to mistakes; posts being added in the wrong sub-sub-category. What comes to mind is a custom module. Could be a process module or a runtime inputfield coupled with a Pages Save Hook. You probably won't even need to save they dynamic field as it is only there to help you drill down to the final parent of the post you are creating. An inputfield may not help with the challenge of going via the tree. It may even confuse authors as they will click on a parent page in the tree to 'Add' a post but the post will then be re-parented. So, maybe a process module is more friendly in this regard. At the top, you would have a dynamic select like field to drill down to sub-sub-category you want. It would then reveal a post add form. On create page, post author is redirected to the edit page of that post. The challenge here is that you will be working away from the usual page edit form. You will need to embed ProcessPageEdit::execute() output in your form. It is not difficult to do. There are posts in the forum that show you how. Just some preliminary thoughts...

Not another Markup Fieldtype ? https://github.com/BernhardBaumrock/FieldtypeRockMarkup What do you think of a Fieldtype that does nothing else then rendering runtime markup from files that you provide in the settings or at runtime? In addition to that, I'd like the field to trigger javascript events to be usable for other fieldtype modules (like a charts module or a grid module). Javascript events would be necessary on field load (ajax/non-ajax), on collapse of the field, on click of a tab. When working with charts and RockGrid this has sometimes become a pain and I've implemented (sometimes dirty) fixes for that in different modules in different ways. I think it would make sense to have a solid base for such kind of modules (fieldtypes) that use some kind of standard events for standard situations. I'm especially interested in your opinions @Beluga because of the upcoming RockTabulator module and @kongondo because of your existing module. I think there are already similar modules by @Robin S and @kixe ? Thx for your input ?

In most cases I expect people to use the Select Image inputfield in conjunction with the Dynamic Options fieldtype. And regarding the value of a Dynamic Options field: The Select Images input type is a bit of a special case because it can be a "multiple" or a "single" input type: And beyond that there is a config option for Dynamic Options that can be used if the values that are saved are paths or URLs to Pagefiles or Pageimages, and this could be a good option when you're using Select Images as the inputfield: When that option is enabled you could use the Pageimage sizing methods on the field value. Note that for multiple images the value is an array of Pageimage objects and not a Pageimages object. That's because these modules are intended to be flexible enough to allow selection of images from more than one PW page but a Pageimages object only supports Pageimage objects associated with a single page (see the class constructor). The readme for Select Images says: So you can have the value for each option (thumbnail) be any string you like and output that in a template file or use it in a conditional to affect the page markup in some way. But I think my most common use case will be as an "image reference" field to select URLs to Pageimages and have the formatted value be a Pageimage or array of Pageimage objects. People have suggested different use cases for an image reference field in the GitHub request linked to at the start of the readme: https://github.com/processwire/processwire-requests/issues/207 Personally I have used image references in these scenarios: To allow an editor to select a social media "share" image from among all the uploads to Images fields on a page. In cases where an editor may only select from a collection of existing images and is not allowed to upload new images. Similar to the previous example, but where the editor needs to choose images that have been prepared in advance to fit in spaces with particular aspect ratios. So for a landscape space they can only select landscape images, square space can only select square images, etc. The allowed options for a Dynamic Options field are determined at runtime according to the FieldtypeDynamicOptions::getSelectableOptions hook you are using. These allowed options are used to validate any stored value when it is accessed. So if an image that was referenced is deleted then it will no longer be in the value you get from $page->your_dynamic_options_field

I'm not sure that I fully understand what you need to do, but I have a couple of thoughts. One is that runtime fields and searches won't mix well, and if you need to maintain a field for some kind of sort code, you'd be better off hooking on saveReady to maintain a field. The other is that it can be quicker than you expect to loop through the results of a search (so long as there aren't huge numbers). So a good strategy might be to get as few pages as possible using selectors, and then loop through those pages to produce the final result.

I think i can at least shed some light on where status 3073 is coming from in the DB. If you take a a look at Page.php (in the wire/core folder) you see this: /* * The following constant flags are specific to a Page's 'status' field. A page can have 1 or more flags using bitwise logic. * Status levels 1024 and above are excluded from search by the core. Status levels 16384 and above are runtime only and not * stored in the DB unless for logging or page history. * * If the under 1024 status flags are expanded in the future, it must be ensured that the combined value of the searchable flags * never exceeds 1024, otherwise issues in Pages::find() will need to be considered. * * The status levels 16384 and above can safely be changed as needed as they are runtime only. * */ const statusOn = 1; // base status for all pages const statusLocked = 4; // page locked for changes. Not enforced by the core, but checked by Process modules. const statusSystemID = 8; // page is for the system and may not be deleted or have it's id changed (everything else, okay) const statusSystem = 16; // page is for the system and may not be deleted or have it's id, name, template or parent changed const statusHidden = 1024; // page is excluded selector methods like $pages->find() and $page->children() unless status is specified, like "status&1" const statusUnpublished = 2048; // page is not published and is not renderable. const statusTrash = 8192; // page is in the trash const statusDeleted = 16384; // page is deleted (runtime only) const statusSystemOverride = 32768; // page is in a state where system flags may be overridden const statusCorrupted = 131072; // page was corrupted at runtime and is NOT saveable: see setFieldValue() and $outputFormatting. (runtime) const statusMax = 9999999; // number to use for max status comparisons, runtime only So i think 3073 comes from the combined values of statusOn, statusHidden and statusUnpublished. One would assume that pages, like readypages, with a code > 1024 would be excluded by default in finding and listing repeater items. I have looked through the FieldtypeRepeater code to see what's going on but this is beyond my php skills and knowledge of the core system. Maybe Ryan can comment on this. For the moment i think your filter solution seems fine. I you want to read more on status stuff i suggest you do a 'find in files' for 'status'. Tools like Sublime Text then give a nice overview of the search results. Not really slick docs..but good for learning :)

@teppo Thanks for the update. I'm migrating a live site to the Wireframe and I need to set altFilename to wireframe for specific templates on the runtime via hook or somehow else only for superuser role. Is there is a way to do that?

If you can build enough discipline in the way you write conditionals, you can avoid this by always putting the constant part first: if ('xx' == $page->template->name) { So if you accidentally miss an equals sign and do an assignment, you get an error from the runtime as you are trying to assign to a constant string literal. I've tried to build this habit over the years and sometimes remember to do this - but I'm not there yet.

Here is a discussion related to this issue, in which Ryan explains the API decisions: https://processwire.com/talk/topic/11736-get-requests-not-subject-to-access-control To sum it up real quick (quotes): A $pages->find() or $pages->findOne() method that filters results is based on database-filtering, not runtime filtering. The API is based around providing methods for the developer to control access the way they see fit. The viewable() method is the basis of that. PW's access control model supports runtime hooks to Page::viewable. One shouldn't skip a $page->viewable() call regardless of what method you used to retrieve the page. When rendering frontend templates <?php if ($page->viewable()) : ?> (or $page->viewable('field_name'); ) is the way to go to check for default PW permissions. For example: https://processwire.com/talk/topic/4834-simple-hooks-tutorial-turn-a-pagearray-into-a-list-of-links/ ... // loop through each item in the PageArray and render some links foreach($event->object as $page) { $value = $page->get($property); if(!strlen($value)) continue; // skip empty values if(strlen($out)) $out .= $delimiter; if($page->viewable()) { $out .= "<a href='$page->url'>$value</a>"; // if page is viewable, make it a link } else { $out .= $value; // if page is not viewable, just display the value } } ... In order to "extend" the access control logic, one can hook after Page::viewable eg.: https://github.com/processwire/processwire-issues/issues/560#issuecomment-384656192 quote: // goes into /site/ready.php $wire->addHookAfter('Page::viewable', function($event) { $viewable = $event->return; if($viewable) return; // use PW's existing logic, since it said it was viewable $page = $event->object; if(!$page instanceof User) return; // this is an example for User templates only if(whatever logic you decide that $page is viewable) { $viewable = true; $event->return = $viewable; } });

Hi, Tks for the module. Wanted to install it to give it a try. I got this error message when the installation started. I have installed the Fieldtype Runtime Only module before. do you have any suggestion ? I am running it on ProcessWire 3.0.164 and php 7.4 Thanks a lot

As I've mentioned svelte already and the filesize argument was used: https://v3.svelte.technology/repl?version=3.0.0-beta.22&example=onmount This example downloaded and compiled results in a 4kb javascript bundle. I'm quite sure even just the code using jquery would need about half of that size to do the same excluding jquery itself. So there are more modern ways to have the benefits of a nice view library in javascript without the need for bloated runtime library code. Svelte has a tiny runtime library, which can even be tree shaken (only include what's needed), while the heavy lifting is done at once at compile time. The better part of your file size bundle will only consist of the actual stuff you build using it. It's only sad that it's currently in a "please don't start using v2 anymore, but also wait till v3 is done" phase.

Hi you might call it dumb, but this is actually interesting, I was thinking is there any mechanism to /condition to stop a Hook from being called, so pardon this jargon, so I took the time to see if such exists public function runHooks($method, $arguments, $type = 'method') { $result = array( 'return' => null, 'numHooksRun' => 0, 'methodExists' => false, 'replace' => false, ); $realMethod = "___$method"; if($type == 'method') $result['methodExists'] = method_exists($this, $realMethod); if(!$result['methodExists'] && !self::isHooked($method . ($type == 'method' ? '()' : ''))) { return $result; // The condition for not running is when not hooked or method doesn't exist } $hooks = $this->getHooks($method); foreach(array('before', 'after') as $when) { if($type === 'method' && $when === 'after' && $result['replace'] !== true) { if($result['methodExists']) { $result['return'] = call_user_func_array(array($this, $realMethod), $arguments); } else { $result['return'] = null; } } foreach($hooks as $priority => $hook) { if(!$hook['options'][$when]) continue; if(!empty($hook['options']['objMatch'])) { $objMatch = $hook['options']['objMatch']; // object match comparison to determine at runtime whether to execute the hook if(is_object($objMatch)) { if(!$objMatch->matches($this)) continue; } else { if(((string) $this) != $objMatch) continue; } } if($type == 'method' && !empty($hook['options']['argMatch'])) { // argument comparison to determine at runtime whether to execute the hook $argMatches = $hook['options']['argMatch']; $matches = true; foreach($argMatches as $argKey => $argMatch) { $argVal = isset($arguments[$argKey]) ? $arguments[$argKey] : null; if(is_object($argMatch)) { // Selectors object if(is_object($argVal)) { $matches = $argMatch->matches($argVal); } else { // we don't work with non-object here $matches = false; } } else { if(is_array($argVal)) { // match any array element $matches = in_array($argMatch, $argVal); } else { // exact string match $matches = $argMatch == $argVal; } } if(!$matches) break; } if(!$matches) continue; // don't run hook } $event = new HookEvent(); $event->object = $this; $event->method = $method; $event->arguments = $arguments; $event->when = $when; $event->return = $result['return']; $event->id = $hook['id']; $event->options = $hook['options']; $toObject = $hook['toObject']; $toMethod = $hook['toMethod']; if(is_null($toObject)) $toMethod($event); else $toObject->$toMethod($event); $result['numHooksRun']++; if($when == 'before') { $arguments = $event->arguments; $result['replace'] = $event->replace === true || $result['replace'] === true; if($result['replace']) $result['return'] = $event->return; } if($when == 'after') $result['return'] = $event->return; } } return $result; } As you can see there isn't any logic to stop hooks from running other than if the arguments are wrong and method doesn't exist or the method itself in question is not hookable. However using an exit should work since the exit method stop the execution of the current script. I think the concept of Hooks is you attaching to them and not stopping them. But another alternative would be to remove the check from the hook and and have the check determining whether to call the WireHttp::send Let me know if that suffices

/** * allowed flag constants (bitmask) for context * @see core/field.php * */ Field::flagAccess // 32 Field::flagAccessAPI // 64 Field::flagAccessEditor // 128 /** * set context via fieldgroup * @see core/fieldgroup.php * */ $fieldGroup->setFieldContextArray($field_title->id, ['flagsAdd' => 192, 'flagsDel' => 32]); $fieldGroup->saveContext(); /** * set context via fields * @see core/fields.php * */ $field_title = wire('fields')->get('title'); $field_title->addFlag(128); // runtime wire('fields')->saveFieldgroupContext($field_title, $fieldGroup); not tested, but should work

Hi all. I've got something that I'm not 100% sure is a problem with AppApi or elsewhere, so I'm hoping someone can just help me cross the AppApi module off my list of the things I'm looking into. I'm currently trying get my API to send an email when a certain POST is made. Locally this works fine, but on our test server I'm getting an unexpected error: { "error": "Internal Server Error", "devmessage": { "message": "set_time_limit() has been disabled for security reasons", "location": "/home/runcloud/webapps/D2U-API/site/assets/cache/FileCompiler/site/modules/WireMailSmtp/WireMailSmtp.module", "line": 750 } } Now a quick look through this forum suggests that this should be generating a PHP warning, that I should just be able to ignore, but for some reason it's stopping execution and generating the API error. I'm wondering whether AppApi is handling this as a hard error and stopping execution, but really it would carry on fine if left, or whether the situation I'm seeing is more serious than the examples in that other forum post? @Sebi or @thomasaull do you have any comments about how a PHP runtime warning would be handled?