Leaderboard

@eutervogel I corrected that for you. And there's nothing to be sorry about ?

As requested by @fuzenco (quite a while ago... sorry for being slow), I'm just creating a separate thread for our TextFormatterLiteVideoEmbed module rather than hijacking the Lite YouTube Embed Module thread. TextFormatterLiteVideoEmbed is a text formatter that replaces YouTube and Vimeo urls in text and textarea fields with custom web components that only load the video iframe when they've been interacted with. This is a million (approximately) times faster than loading the video when the page loads, especially if you have multiple videos on a page. You can check Paul Irish's original YouTube version to see what it's all about. There are config options to set the button colours for the components, and one day I'll get round to adding all the other parameters we ought to have. I've used it on several live sites at the moment and is our go-to module for embedding videos now so hopefully will keep adding to it but I'm happy to take requests if anyone needs anything specific adding. It was originally based on the TextformatterLiteYouTubeEmbed module so props to @jacmaesfor creating that. The code is available on Github at https://github.com/millipedia/TextformatterLiteVideoEmbed and I'll add it to the modules repository once I've tidied up the code (it's getting there slowly).

@dotnetic @MarkE was refering about multi-instance issue, where there are some hints with Ryan intervention, it might help:

I don't have a real solution, but I have had similar Problems when using multi-instance. I don't think it is a namespace issue. At least in my case this was not the case. In my case the problem came from including some dependencies by using "require_once". At least on my modules I was able to fix that problem by using the PW internal class loader instead of require or require_once. This tells me that PHP seems not to be able to correctly understand "require_once" when it is used from different directories. So for PHP including the same PHP class (eg /foo/wire/MyClass.php and /bar/wire/MyClass.php) looks like including two different things and therefore it will fire the include twice and not only once. This would then lead to such "is already in use" errors. In my modules that was easy to fix, but you can't easily refactor modules that are not under your control. What I'm wondering though is why it works with plain installs and does not with your real life projects. So maybe it's another issue. But maybe my observations help nonetheless ?

Template Engines have helpers for that very common use case. For example when using RockFrontend + Latte you can take your statement and simply add "n:ifcontent" to only output the whole li-tag if it contains content, meaning it will only be output if $page->title contains something: <li n:ifcontent><a href="<?= $page->httpUrl ?>"><?= $page->title ?></a></li> Additional to that you also have other helpers, like n:tag-if that refers not to the whole markup but only to the specific tag you put it on. That's very handy when rendering menus and some items should be linked and others should not be: <li n:foreach="$page->children() as $item"> <a href="..." n:tag-if="$item->viewable()"> {$item->title} </a> </li> Which will output something like this: <li><a href="...">Viewable page</a></li> <li>Non-viewable page</li> <li><a href="...">Other viewable page</a></li> ...

When I modify a module that exists in the modules directory I put my initials in the module title or summary as a reminder, e.g. "Some Module: RPS mod". Then I disable the download button and add a notice to the "Download and Update" form just in case I forget. $wire->addHookAfter('ProcessModule::buildDownloadConfirmForm', function(HookEvent $event) { $data = $event->arguments(0); /* @var InputfieldForm $form */ $form = $event->return; $modules = $event->wire()->modules; // Return early if the module isn't already installed if(!$modules->isInstalled($data['class_name'])) return; // Get info about the installed module $info = $modules->getModuleInfoVerbose($data['class_name']); // Return early if special string doesn't occur in the title or summary if(strpos($info['title'], 'RPS mod') === false && strpos($info['summary'], 'RPS mod') === false) return; // Disable download button and add warning notice $update_button = $form->getChildByName('godownload'); if($update_button) { $update_button->value = 'Update disabled (RPS custom mod)'; $update_button->attr('style', 'opacity:0.5;'); $update_button->attr('disabled', 'disabled'); $this->warning('Module has custom RPS modifications: update disabled'); } $event->return = $form;

Hello @Matze No, not by default, but I have added a new method which counts the times set: getNumberOfTimes() You can use this method to do a check, but you have to update to version 1.2.0. Best regards Jürgen

Hi Krlos - thanks - I believe the module does support multilanguage, and we had added support for that a few years ago. I know there is probably no example of how to set a multilanguage field in the samples, but AFAIK it should work if you get the JSON or PHP setup to tell it the various language parameters.

Hello, You can do this: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-copies-of-the-same-module Maybe I'm missing something, but how can one accidentally upgrade a module? Besides, if you think that is an issues, your backups and/or git versions, etc... should cover you, shouldn't they?

Hi, like @flydev says, you need a template for the pages you want to display on the front side... i just wanted to add two little things inspired by your template name "partner_3.php" - if ever there are partner_1, partner_2 and so on pages, it may sound obvious but well... you can of course have a partner.php template and use it for all your partner pages... it's not a page/a template but a kind of page needing which fields then no matter how many partner pages you are going to create they can of course use the same template - coming to those no file templates they are very useful in many case, for exemple imagine a page aggregating children pages that are not going to be displayed by themselves (when the chilodren are going to be a bit heavy or numerous and would slow the admin in a repeater, thos children pages could use a template without php file lots of other cases, one i like a lot a default fields template for a... default fields template ? to centralize the default value for fields you're going to use on a lot of pages/templates (hero img for example) have a nice day

Page List Auto Expand Automatically expands the next adjacent page when moving a page in Page List. Usage As you are moving a page in Page List, if you position the yellow move placeholder above a Page List item for a configurable period of time (default is 1000 milliseconds) then that item will expand, allowing the moving page to be dropped as child page. Configuration In the module config you can set the delay before the Page List item adjacent to the move placeholder will be automatically expanded. Restricting the module to certain roles If you want to restrict the module functionality to only certain roles then create a new permission named page-list-auto-expand. If that permission exists then a user's role must have that permission or the module will not have an effect in Page List. https://github.com/Toutouwai/PageListAutoExpand https://processwire.com/modules/page-list-auto-expand/

Does this help?

Try checking them since they DISable appended files. Also check your config file for “appendTemplateFile”: https://processwire.com/api/ref/config/#pwapi-methods-template-files

This is a bit hackish and add only obscurity. There is a better way that not everyone are aware of to achieve what OP ask if it's ok to let users log in into the backend, I didn't followed all the topic previously. Keep in mind that you can override parts of the AdminTheme. To give you an example, let's assuming you are on a default setup with AdminThemeUikit, then follow theses steps: create a new directory AdminThemeUikit in site/templates create a file called _restricted-masthead.php and paste the code you will find at the end of this post copy the file _main.php from /wire/modules/AdminTheme/AdminThemeUikit/_main.php into /site/templates/AdminThemeUikit adjust the behavior of the admin theme as you want in _main.php (example below, just replace the full code) Code of _main.php ? Code of _restricted-masthead.php ? Result Enregistrement #61.mp4 - https://streamable.com/jg2l0p More informations there: https://github.com/processwire/processwire/blob/dev/wire/modules/AdminTheme/AdminThemeUikit/README.md Enjoy ✌️

Please post the content of your template file where the error occurs. Do you prepend or append files to the template? I think this might be the cause. Go to your template in ProcessWire and to the files tab. Disable prepending and appending any files, and see if that fixes the error.

I'd fake it and use a selector like this: $pages->find("id=1")->each('<li><a href={url}>{title}</a>');

Hey @kongondo, is there actually anything new to see here? ?

This is one of the rare things that are not instantly intuitive to I guess 99% of my clients! Have you considered adding a PR @Robin S ? Imho that's really an essential feature, thx for creating and sharing it! Just added it to RockMigrations default profile ?

Thanks, hope this module gets included in the PW-core.

Thank you - this will be very useful!

Hi, `$this->addHook()` give you the ability to define a custom method that can be available in the class object given as a parameter. $this->addHook('Page::summarize', $this, 'summarize'); | | | |- (name of the method defined in the current object (module, class..) | | | | | |- current object where the method is defined (module, class) | | | |- the name is mandatory, | you will call the method given as third param from the Page $page object ($page->summarize()). | |- the object where the new method will be added to In the example of the `summarize()` method you are talking about, it expect a method `summarize()` to be defined in an autoload module. But you are not required to write a module just to define a new method to an existing class. You can write it outside a class, for example, in the file `init.php` by writing the following: $this->addHook('Page::summarize', function ($event) { // the $event->object represents the object hooked (Page) $page = $event->object; // first argument is the optional max length $maxlen = $event->arguments(0); // if no $maxlen was present, we'll use a default of 200 if(!$maxlen) $maxlen = 200; // use sanitizer truncate method to create a summary $summary = $this->sanitizer->truncate($page->body, $maxlen); // populate $summary to $event->return, the return value $event->return = $summary; }); // or by defining the function... function summarize_2($event) { // the $event->object represents the object hooked (Page) $page = $event->object; // first argument is the optional max length $maxlen = $event->arguments(0); // if no $maxlen was present, we'll use a default of 200 if(!$maxlen) $maxlen = 200; // use sanitizer truncate method to create a summary $summary = wire()->sanitizer->truncate($page->body, $maxlen); // populate $summary to $event->return, the return value $event->return = $summary; }; // ... and giving the name of the function to the hook. // note the `null` parameter used to tell the hook we are not using it from a class object $this->addHook('Page::summarize_2', null, 'summarize_2'); You will be using a hook where `after` or `before` doesn't matter, to define a new method `summarize()` to the existing class `Page`. So in your template, eg. `home.php` or `basic-page.php`, you can then call both methods from the `$page` api variable. <?php namespace ProcessWire; // Template home.php // if the `body` field content is: "The body field of this page summarized in less than 200 characters, or it will be truncated." // calls of the new defined methods `summarize()` and `summarize_2()` will print the content of the `body` field. echo $page->summarize(); echo $page->summarize_2(); If you want to test it from a module, then is quite simple (note we replace the `null` param by `$this` to tell the hook we are using it from the current object class (themodule): class ExampleSummarize extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'Example Summarize module', 'version' => 1, 'summary' => 'Add a new method `summarize()` to page object.', 'autoload' => true, ]; } function summarize($event) { // the $event->object represents the object hooked (Page) $page = $event->object; // first argument is the optional max length $maxlen = $event->arguments(0); // if no $maxlen was present, we'll use a default of 200 if(!$maxlen) $maxlen = 200; // use sanitizer truncate method to create a summary $summary = wire()->sanitizer->truncate($page->body, $maxlen); // populate $summary to $event->return, the return value $event->return = $summary; }; public function init() { $this->addHook('Page::summarize', $this, 'summarize'); } } If you write this code in a file `ExampleSummarize.module` and from the backend you refresh modules and install this module, the method `summarize()` will be available by calling `$page->summarize()` from where you want. You can also find more informations and lot of details there: https://processwire.com/docs/modules/hooks/

If you want to try the example I built (it looks for css/less files in assets/fonts and templates/ and then parses font families and returns a select options box with unique path/font family pairs) let me know and I'll tidy up an example and attach it. On the backend it gives me this:

In this tutorial I will cover how to use clsource's REST Helper classes to create a RESTful API endpoint within a PW-powered site and how to connect to it from the outside world with a REST client. This is a quite lengthy tutorial. If you follow all along and make it through to the end, you should get both, a working REST API with ProcessWire and hopefully some more basic understanding how these APIs work. As always with PW, there are many ways you could do this. My way of implementing it and the code examples are loosely based on a real world project that I am working on. Also, this is the first tutorial I am writing, so please bear with me if my instructions and examples are not that clear to understand. And please let me know if something is missing or could be made more clear. The steps covered: create templates and pages in the PW backend to get an API endpoint (an URL where the API can be accessed at) copy and save the REST Helper classes to your site create a template file and write some logic to receive and process data through our endpoint and send data back to the REST client test the whole setup with a Browser REST Client Addon I will not go into fundamentals and technical details on how RESTful APis are supposed to work. I assume that you have already read up on that and have a basic understanding of the principles behind that technology. Some helpful resources to brush up your knowledge: https://en.wikipedia.org/wiki/Representational_state_transfer http://www.restapitutorial.com/lessons/whatisrest.html The complete pages.php template is attached to this post for copy/paste. Lets get started. 1. create templates and pages in the PW backend to get an API endpoint (an URL where the API can be accessed) First we need to create some templates and pages in the PW backend to make our REST API accessible from the outside world through an URL (API endpoint). In my example this URL will be: https://mysite.dev/api/pages/ Note the "https" part. While this is not mandatory, I strongly recommend having your API endpoint use the https protocol, for security reasons. Further down in step 3 we will use this URL to create new pages / update and get data of existing pages. Go to your PW test site admin and: create 2 new templates: one is called "api", the other one "pages". For a start, they both have only a title field assigned. Just create the templates. We will create the corresponding files later, when we need them. enable "allow URL segments" for the "pages" template. We will need this later to access data sent by the requests from the client. in the Files tab of the "pages" template check "Disable automatic append of file: _main.php" create a new page under the home page with title, name and template "api" and set it to hidden create a child page for the "api" page with title, name and template "pages" The pagetree should look somewhat like this: Ok, now we're all set up for creating our API endpoint. If you browse to https://mysite.dev/api/pages/ you will most likely get a 404 error or will be redirected to your home page as we do not have a template file yet for the "pages" template. We will add that later in step 3. 2. copy and save the REST Helper classes to your site I have the REST Helper class sitting in site/templates/inc/Rest.php and include it from there. You could save it in any other location within your site/templates folder. I forked clsource's original code to add basic HTTP authentication support. Click here to open my raw gist, copy the contents and save them to /site/templates/inc/Rest.php In the next step we will include this file to make the classes "Rest" and "Request" available to our template file. 3. create a template file and write some logic to receive and process data through our endpoint and send data back to the client This will be the longest and most complex part of the tutorial. But I will try to present it in small, easy to follow chunks. Since we access our API at https://mysite.dev/api/pages/, we need to create a template file called "pages.php" for our "pages" template and save it to /site/templates/pages.php. Go ahead and create this file (if you're lazy, copy the attached file). Now right at the top of pages.php, we start with <?php require_once "./inc/Rest.php"; to include the REST Helper classes. Next, we initialize some variables that we will keep using later on // set vars with the default output $statuscode = 200; $response = []; $header = Rest\Header::mimeType('json'); 3.1 retrieve data with a GET request Now that we have the basics set up, we will next create the code for handling the easiest request type, a GET request. With the GET request we will ask the API to return data for an existing page. To let the API know which page it should return data for, we need to send the page id along with our request. I am attaching the page id as an url segment to the API endpoint. So the URL that the client will use to retrieve data for a page will look like: https://mysite.dev/api/pages/1234 where 1234 is the unique page id. Add following code to pages.php // if we have an urlsegment and it is a numeric string we get data from or update an existing page: handle GET and PUT requests if($input->urlSegment1 && is_numeric($input->urlSegment1)) { $pageId = $input->urlSegment1; // GET request: get data from existing page if(Rest\Request::is('get')) { // get the page for given Id $p = $pages->get($pageId); if($p->id) { $pdata = ["id" => $pageId]; // array for storing page data with added page id $p->of(false); // set output formatting to false before retrieving page data // loop through the page fields and add their names and values to $pdata array foreach($p->template->fieldgroup as $field) { if($field->type instanceof FieldtypeFieldsetOpen) continue; $value = $p->get($field->name); $pdata[$field->name] = $field->type->sleepValue($p, $field, $value); } $response = $pdata; } else { //page does not exist $response["error"] = "The page does not exist"; $statuscode = 404; // Not Found (see /site/templates/inc/Rest.php) } } } else { // no url segment: handle POST requests } // render the response and body http_response_code($statuscode); header($header); echo json_encode($response); Lets brake this down: First we check for a numeric url segment which is our $pageId. Then the Rest Request class comes into play and checks what type of request is coming in from the client. For the GET request, we want to return all data that is stored for a page plus the page id. This is all good old PW API code. I am using the $pdata array to store all page data. Then I am handing this array over to the $response variable. This will be used further down to render the JSON response body. If the page does not exist, I am setting an error message for the $response and a status code 404 so the client will know what went wrong. The else statement will later hold our POST request handling. The last 3 lines of code are setting the header and status code for the response and print out the response body that is sent back to the client. You can now browse to https://mysite.dev/api/pages/1 where you should see a JSON string with field names and values of your home page. If you enter a page id which does not exist you should see a JSON string with the error message. Lets move on to updating pages through a PUT request 3.2 update pages with a PUT request Since our API needs to know the id of the page we want to update, we again need to append an id to our endpoint url. In this example we will update the title and name of our homepage. So the request url will be: https://mysite.dev/api/pages/1. For the GET request above, anyone can connect to our API to retrieve page data. For the PUT request this is not a good idea. Thus we will add basic authentication so that only authorized clients can make updates. I use basic HTTP authentication with username and password. In combination with the https protocol this should be fairly safe. To set this up, we need an API key for the password and a username of our choosing. We add the API key in the PW backend: add a new text field "key" and assign it to the "api" template. edit the "api" page, enter your key and save. (I am using 123456 as key for this tutorial) Now add following code right after the if(Rest\Request::is('get')) {...} statement: // PUT request: update data of existing page if(Rest\Request::is('put')) { // get data that was sent from the client in the request body + username and pass for authentication $params = Rest\Request::params(); // verify that this is an authorized request (kept very basic) $apiKey = $pages->get("template=api")->key; $apiUser = "myapiuser"; if($params["uname"] != $apiUser || $params["upass"] != $apiKey) { // unauthorized request $response["error"] = "Authorization failed"; $statuscode = 401; // Unauthorized (see /site/templates/inc/Rest.php) } else { // authorized request // get the page for given Id $p = $pages->get($pageId); if($p->id) { $p->of(false); $p->title = $sanitizer->text($params["title"]); $p->name = $sanitizer->pageName($params["name"]); $p->save(); $response["success"] = "Page updated successfully"; } else { // page does not exist $response["error"] = "The page does not exist"; $statuscode = 404; // Not Found (see /site/templates/inc/Rest.php) } } } Breakdown: We check if the request from the client is a put request. All data that was sent by the client is available through the $params array. The $params array also includes $params["uname"] and $params["upass"] which hold our API user and key. We set API key and user and check if they match with the values that were sent by the client. If they don't match we store an error message to the response body and set the appropriate status code. If authentication went through ok, we get the page via PW API and update the values that were sent in the request body by the client. Then we put out a success message in the response body. If the page does not exist, we send the appropriate response message and status code, just like in the GET request example above. Now you might wonder how the client sends API user/key and new data for updating title and name. This is covered further down in step 4. If you want to test the PUT request right now, head down there and follow the instructions. If not, continue reading on how to setup a POST request for creating new pages. 3.2 create new pages with a POST request Final part of the coding part is creating new pages through our API. For this to work we need to implement a POST request that sends all the data that we need for page creation. We will do this at our endpoint: https://mysite.dev/api/pages/ Paste following code within the else statement that has the comment "// no url segment: handle POST requests": // POST request: create new page if(Rest\Request::is('post')) { // get data that was sent from the client in the request body + username and pass for authentication $params = Rest\Request::params(); // verify that this is an authorized request (kept very basic) $apiKey = $pages->get("template=api")->key; $apiUser = "myapiuser"; if($params["uname"] != $apiUser || $params["upass"] != $apiKey) { // unauthorized request $response["error"] = "Authorization failed"; $statuscode = 401; // Unauthorized (see /site/templates/inc/Rest.php) } else { // authorized request // create the new page $p = new Page(); $p->template = $sanitizer->text($params["template"]); $p->parent = $pages->get($sanitizer->text($params["parent"])); $p->name = $sanitizer->pageName($params["name"]); $p->title = $sanitizer->text($params["title"]); $p->save(); if($p->id) { $response["success"] = "Page created successfully"; $response["url"] = "https://mysite.dev/api/pages/{$p->id}"; } else { // page does not exist $response["error"] = "Something went wrong"; $statuscode = 404; // just as a dummy. Real error code depends on the type of error. } } } You already know what most of this code is doing (checking authorisation etc.). Here's what is new: We create a page through the PW API and assign it a template, a parent and basic content that was sent by the client. We check if the page has been saved and update our response body array with a success message and the URL that this page will be accessible at through the API for future requests. The client can store this URL for making GET or PUT requests to this page. If you're still reading, you have made it through the hard part of this tutorial. Congratulations. Having our code for reading, updating and creating pages, we now need a way to test the whole scenario. Read on to find out how this can be done. 4. test the whole setup with a Browser REST Client Addon The link in the heading will take you to a place from which you can install the very useful RESTClient addon to your favorite browser. I am using it with Firefox which is still the dev browser of my choice. Open a RESTClient session by clicking the little red square icon in the browsers addon bar. The UI is pretty straightforward and intuitive to use. 4.1 test the GET request Choose Method GET and fill in the URL to our endpoint. If you do not have a SSL setup for testing, just use http://yourrealtestdomain.dev/api/pages/1. If you happen to have a SSL test site with a self signed certificate, you need to point your browser to the URL https://yourrealtestdomain.dev/api/pages/ first in your test browser and add the security exception permanently. Otherwise RESTClient addon won't be able to retrieve data. If you have a test site with a 'real' SSL certificate, everything should be fine with using the https://... URL Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string with data of your page. now change the 1 i the URL to some id that does not exist in your site and hit send again. You should get a 404 Status Code in the Response Headers tab and an error message "{"error":"The page does not exist"}" in the Response Body (Raw) tab. If you get these results, congrats! The GET request is working. For further testing you can save this request through the top menu Favorite Requests->Save Current Request. 4.1 test the PUT request Choose Method PUT and fill in the URL to our endpoint ending with 1 (http://yourrealtestdomain.dev/api/pages/1). In the top left click Headers->Content-Type: application/json to add the right content type to our request. If you miss this step, the request will not work. You will now see a "Headers" panel with all your headers for this request Click on Authentication->Basic Authentication. In the modal window that pops up, fill in user (myapiuser) and password (your API key). Check "Remember me" and hit Okay. You now should see Content-Type and Authorization headers in the "Headers" panel. Next, we need to send some data in the request body for updating our page title and name. Since we're using JSON, we need to create a JSON string that contains the data that we want to send. As I will update the home page for this example, my JSON reads { "title" : "Newhome", "name" : "newhome" } Be careful that you have a well formed string here. Otherwise you will get errors. Paste this into the "Body" panel of the REST Client addon. Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string "{"success":"Page updated successfully"}". Now go to the PW backend and check if title and name of your page have been updated. If yes, congrats again. 4.2 test the POST request Choose Method POST and fill in the URL to our endpoint without any page id (http://yourrealtestdomain.dev/api/pages/). In the top left click Headers->Content-Type: application/json to add the right content type to our request. If you miss this step, the request will not work. You will now see a "Headers" panel with all your headers for this request Click on Authentication->Basic Authentication. In the modal window that pops up, fill in user (myapiuser) and password (your API key). Check "Remenber me" and hit Okay. You now should see Content-Type and Authorization headers in the "Headers" panel. Next, we need to send some data in the request body for updating our page title and name. Since we're using JSON, we need to create a JSON string that contains the data that we want to send. I will create a new page with template basic-page and parent /about/ for this example, my JSON reads { "template" : "basic-page", "parent" : "/about/", "title" : "New Page created through api", "name" : "newapipage" } Be careful that you have a well formed string here. Otherwise you will get errors. Paste this into the "Body" panel of the REST Client addon. Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string "{"success":"Page created successfully","url":"https:\/\/mysite.dev\/api\/pages\/1019"}". Now go to the PW backend and check if title and name of your page have been updated. If yes, you're awesome! Summary By now you have learned how to build a simple REST API with ProcessWire for exchanging data with mobile devices or other websites. Notes I tested this on a fresh PW 2.7.2 stable install with the minimal site profile and can confirm the code is working. If you experience any difficulties in getting this to work for you, let me know and I will try to help. There purposely is quite a lot of repetion in the example code to make it easier to digest. In real life code you might not want to use procedural coding style but rather separate repeating logic out into classes/methods. Also, in life applications you should do more sanity checks for the authentication of clients with the API / for the data that is delivered by the client requests and more solid error handling. I skipped these to make the code shorter. RESTful services are by definition stateless (sessionless). My implementation within PW still opens a new session for each request and I haven't found a way around that yet. If anyone can help out this would be much appreciated. And finally big thanks to clsource for putting the Rest.php classes together. pages.php.zip

Another, maybe better, approach would be to use AdminCustomFiles (http://modules.processwire.com/modules/admin-custom-files/) to add some custom JS to do this on-the-fly. Then use jQuery to grab the contents of your street and city fields, concatenate them, insert them into the map address field and then blur so that google maps triggers a geocode. Maybe something like this: $('#Inputfield_city').on( "blur", function() { var address = $('#Inputfield_street_address').val() + ' ' + $('#Inputfield_city').val(); $('#Inputfield_map').val(address); $('#Inputfield_map').blur(); }); On limited testing here it seems to work just fine. Of course it assumes the address field is named "street_address" and the city field is "city" and the mapmarker field is simply "map". Let me know if that works for you. Don't forget that you can test via your dev console so you know it's working before adding via Admin Custom Files. PS - of course you can always add commas, and even state and country elements to the address that goes into the map address field for geocoding.