$page->edit() method

Get front-end editable output for field (requires PageFrontEdit module to be installed)

This method requires the core PageFrontEdit module to be installed. If it is not installed then it returns expected output but it is not front-end editable. This method corresponds to front-end editing Option B. See the front-end editor docs for more details. If the user does not have permission to front-end edit then returned output will not be editable.

Use $page->edit('field_name'); instead of $page->get('field_name'); to automatically return an editable field value when the user is allowed to edit, or a regular field value when not. When field is editable, hovering the value shows a different icon. The user must double-click the area to edit.

The 2nd and 3rd arguments are typically used only if you need to override the default presentation of the editor or provide some kind of action or button to trigger the editor. It might also be useful if the content to edit is not visible by default. It is recommended that you specify boolean true for the $modal argument when using the $markup argument, which makes it open the editor in a modal window, less likely to interfere with your front-end layout.

Available since version 3.0.0. This method is added by a hook in PageFrontEdit and only shown in this class for documentation purposes.

Example

// retrieve editable value if field_name is editable, or just value if not
$value = $page->edit('field_name'); 

Usage

// basic usage
$string = $page->edit();

// usage with all arguments
$string = $page->edit($key = null, $markup = null, $modal = null);

Arguments

NameType(s)Description
key (optional)string, bool, null

Name of field, omit to get editor active status, or boolean true to enable editor.

markup (optional)string, bool, null

Markup user should click on to edit $fieldName (typically omitted).

modal (optional)bool, null

Specify true to force editable region to open a modal window (typically omitted).

Return value

string bool mixed


Hooking $page->edit(…)

You can add your own hook events that are executed either before or after the $page->edit(…) method is executed. Examples of both are included below. A good place for hook code such as this is in your /site/ready.php file.

Hooking before

The 'before' hooks are called immediately before each $page->edit(…) method call is executed. This type of hook is especially useful for modifying arguments before they are sent to the method.

$this->addHookBefore('Page::edit', function(HookEvent $event) {
  // Get the object the event occurred on, if needed
  $page = $event->object;

  // Get values of arguments sent to hook (and optionally modify them)
  $key = $event->arguments(0);
  $markup = $event->arguments(1);
  $modal = $event->arguments(2);

  /* Your code here, perhaps modifying arguments */

  // Populate back arguments (if you have modified them)
  $event->arguments(0, $key);
  $event->arguments(1, $markup);
  $event->arguments(2, $modal);
});

Hooking after

The 'after' hooks are called immediately after each $page->edit(…) method call is executed. This type of hook is especially useful for modifying the value that was returned by the method call.

$this->addHookAfter('Page::edit', function(HookEvent $event) {
  // Get the object the event occurred on, if needed
  $page = $event->object;

  // An 'after' hook can retrieve and/or modify the return value
  $return = $event->return;

  // Get values of arguments sent to hook (if needed)
  $key = $event->arguments(0);
  $markup = $event->arguments(1);
  $modal = $event->arguments(2);

  /* Your code here, perhaps modifying the return value */

  // Populate back return value, if you have modified it
  $event->return = $return;
});

$page methods and properties

API reference based on ProcessWire core version 3.0.135

Twitter updates

  • New post: Version 3.0.135 of ProcessWire on the dev branch focuses on some .htaccess updates, adds clarity to debug mode, and improves upon the installer— More
    5 July 2019
  • ProcessWire 3.0.133 adds a useful new Page::meta() method for a new type of page-specific persistent data storage, adds the ability for users to create their own bookmarks in Lister, and has a handy and time saving update for the asmSelect input type— More
    14 June 2019
  • New post: This week we’ll take a look at 3 different WEBP image strategies that you can use in ProcessWire 3.0.132+. Then we’ll dive into a major update for the Google Client API module, and finish up by outlining some useful new updates in FormBuilder— More
    31 May 2019

Latest news

  • ProcessWire Weekly #270
    This week in the 270th issue of ProcessWire Weekly we're going to cover the SearchEngine module, feature some recent support forum highlights, and introduce a brand new site of the week. Read on!
    Weekly.pw / 13 July 2019
  • ProcessWire 3.0.135 core updates
    Version 3.0.135 of ProcessWire on the dev branch focuses on .htaccess updates, adds additional layers of security, adds clarity to debug mode, and improves upon the installer.
    Blog / 3 July 2019
  • Subscribe to weekly ProcessWire news

I just love the easy and intuitive ProcessWire API. ProcessWire rocks!” —Jens Martsch, Web developer