Fieldtype not found after installation of site profile

[Robin S]

I have an issue that has been a mild annoyance for a while but has become more serious now due to a core change.

The issue occurs at the end of the PW installation process using a custom site profile that I generated using ProcessExportProfile, and relates to a custom Fieldtype module not being "known" to PW immediately after installation.

The error I used to get is this...

...and it was of no real consequence. I just ignore the message and on the next page load the message does not reappear (I used to do a Modules > Refresh but after more testing today it seems this isn't necessary - just reloading the page is enough to resolve the message). The issue relates to this section of code and seems to indicate that FieldtypeSelectImage is not included in $fieldtypes immediately after installation. But as soon as I login and check with Tracy I can see FieldtypeSelectImage is included as expected:

 

 

Due to recent changes to FieldtypeRepeater.module I now get a more serious problem at the end of installation that prevents me from completing the installation, and install.php is left behind...

Again due to the FieldtypeSelectImage fieldtype not being present in $fieldtypes.

Now FieldtypeSelectImage is a custom module I created, and it was the first PW module I ever made so it wouldn't surprise me if there was some mistake in it. But there are other similar issues reported in the forums so I think it might be a more general issue that isn't specific to this particular module.

https://processwire.com/talk/topic/574-site-copied-to-development-server-fieldtype-does-not-exist/

https://processwire.com/talk/topic/4067-site-doesnt-work-after-hosting-migration/

https://processwire.com/talk/topic/13781-problems-after-installing-remote-copy-to-local/

The agreement seems to be that the issue relates to the module cache, but what can I do to prevent the issue occurring during installation? The cache file that Ryan mentions in his reply to one of the threads above does not exist in my case.

Is there some change I need to make to FieldtypeSelectImage so that PW can recognise it during the PW install process? The module code:

Spoiler

<?php

/**
 * Fieldtype Select Image
 *
 * This Fieldtype stores a reference to a single image that is chosen from the images on the current page using a select dropdown.
 *
 */

class FieldtypeSelectImage extends Fieldtype {

	/**
	 * Module information
	 */
	public static function getModuleInfo() {
		return array(
			'title' => 'Select Image',
			'version' => 4,
			'summary' => 'Allows the selection of a single image from any of the image fields on the current page.',
			'installs' => 'InputfieldSelectImage',
			'icon' => 'image'
		);
	}

	/**
	 * Get options for select field
	 */
	public function getImageOptions(Page $page) {
		$options = [];
		foreach($page->fields as $field) {
			if($field->type instanceof FieldtypeImage) {
				foreach($page->$field as $image) {
					// key is image filename and value is image thumbnail url
					$options[] = array("label" => $image->basename, "thumb" => $image->height(260)->url, "data" => "{$field->name}|{$image->basename}");
				}
			}
		}
		return $options;
	}

	/**
	 * Get inputfield
	 */
	public function getInputfield(Page $page, Field $fields) {
		$inputfield = $this->modules->get("InputfieldSelectImage");
		$options = $this->getImageOptions($page);
		// add options to the input field
		foreach($options as $option) {
			$label = $option["label"];
			$value = $option["data"];
			if ($value != "" && ($label != "" || $label == NULL)) {
				if(!strlen($value)) continue;
				$inputfield->addOption($value, $label, array("data-thumb" => $option["thumb"]));
			}
		}
		return $inputfield;
	}
	/**
	 * Get database schema
	 */
	public function getDatabaseSchema(Field $field) {
		$schema = parent::getDatabaseSchema($field);
		$schema['data'] = 'text NOT NULL';
		$schema['keys']['data_exact'] = 'KEY `data_exact` (`data`(255))';
		$schema['keys']['data'] = 'FULLTEXT KEY `data` (`data`)';
		return $schema;
	}

	/**
	 * Sanitize value
	 */
	public function sanitizeValue(Page $page, Field $field, $value) {
		if(is_string($value) && strpos($value,"|") !== false) {
			list($field_name, $image_name) = explode("|", $value);
			$value = $page->$field_name->get("name=$image_name");
		}
		if( !is_object($value) || $value->className() !== 'Pageimage' ) $value = '';
		return $value;
	}

	/**
	 * Wakeup value
	 */
	public function ___wakeupValue(Page $page, Field $field, $value) {
		if (strpos($value,"|") !== false) {
			list($field_name, $image_name) = explode("|", $value);
			$value = $page->$field_name->get("name=$image_name");
		}
		return $value;
	}

	/**
	 * Sleep value
	 */
	public function ___sleepValue(Page $page, Field $field, $value) {
		if(is_object($value)){
			$field_name = "";
			foreach($page->fields as $field) {
				if($field->type instanceof FieldtypeImage) {
					if($page->get($field->name)->has("name={$value->basename}")) {
						$field_name = $field->name;
					}
				}
			}
			$image_name = $value->basename;
			$value = "{$field_name}|{$image_name}";
		}
		return (string) $value;
	}

}

 

 

[Robin S]

Update: seems like the issue is not related to that particular custom Fieldtype module - it just happened that it was the only non-core Fieldtype module installed in my profile.

I added FieldtypeMapMarker to my site profile and got this when installing PW 3.0.62...

So I'm thinking it's a bug with either the PW installer or ProcessExportProfile, but I'm keen to hear anyone's thoughts on this.

[abdus]

26 minutes ago, Robin S said:

The agreement seems to be that the issue relates to the module cache, but what can I do to prevent the issue occurring during installation? The cache file that Ryan mentions in his reply to one of the threads above does not exist in my case.

I'm not sure around which version but almost all caches were migrated to DB from filesystem. I presume it's faster to access DB as it's cached in the memory than accessing a file on the disk.

But inside install.php you can flush module cache by adding $wire->modules->refresh() before the last screen when PW is ready to be bootstrapped.

/**
 * Execution controller
 *
 */
public function execute() {
    // ...
    if(isset($_POST['step'])) switch($_POST['step']) {
        case 0: $this->initProfile(); break;
        case 1: $this->compatibilityCheck(); break;
        case 2: $this->dbConfig();  break;
        case 4: $this->dbSaveConfig();  break;

        case 5: require("./index.php");
            /** @var ProcessWire $wire */

            // Refresh module cache
            $wire->modules->refresh();

            $this->adminAccountSave($wire);
            break;

        default:
            $this->welcome();

    } else $this->welcome();

    // ...
}

 

[Robin S]

1 hour ago, abdus said:

But inside install.php you can flush module cache by adding $wire->modules->refresh() before the last screen when PW is ready to be bootstrapped.

Thanks for the reply - you're definitely on the right track there. Your suggestion solves the issue for PW 3.0.62, but when installing PW 3.0.75 I still get the error below:

I'm guessing that might be due to this part of FieldtypeRepeater.module firing as soon as PW is bootstrapped, before the module cache has had the chance to clear. Can you see a way to work around that?

Edit: this edit to FieldtypeRepeater does the trick...

if(!$field->type || $field->type->className() != $className) continue;

I have created a GitHub issue for this.

[abdus]

1 hour ago, Robin S said:

I'm guessing that might be due to this part of FieldtypeRepeater.module firing as soon as PW is bootstrapped, before the module cache has had the chance to clear. Can you see a way to work around that?

You might be right. initFields() is called from FieldtypeRepeater::init() method, which fires after PW finishes loading modules in boot sequence.

You can try deleting module cache directly from the database using the config prepared in the previous step, before PW is bootstrapping. This forces Modules class to recreate caches

<?php

$db = new \ProcessWire\Database(
    '127.0.0.1',
    'dbUser',
    'dbPass',
    'dbName',
    1234
);

// OR (not tested)
$config = new \stdClass();
require_once __DIR__ . '/site/config.php';

// OR
$config = \ProcessWire\ProcessWire::buildConfig(__DIR__);
$db = new \ProcessWire\Database($config);

$db->query("DELETE FROM caches WHERE name = 'Modules.site/modules/'");

But a better solution would be excluding caches table from the exported profile.

[Robin S]

15 minutes ago, abdus said:

But a better solution would be excluding caches table from the exported profile.

Thanks for the suggestion, but site profiles created by ProcessExportProfile already do not include any content in the caches table (the table is created but nothing is inserted into it).

[abdus]

Hmm, you're right. 

// create, but no data
$options['excludeExportTables'] = array(
	'field_roles',
	'field_permissions',
	'field_email',
	'field_pass',
	'caches',
	'session_login_throttle',
	'page_path_history', 
); 

 

[adrian]

Just a quick note here - I have seen the same "Fieldtype does not exist" error in other circumstances also, so it's not just to do with ProcessExportProfile. I didn't read thoroughly through this thread, so maybe you guys already figured that out.

[kongondo]

I get the "FieldtypeXXX" does not exist as well...during regular login. I always assumed it was due to my setup. I symlink my modules folder to be shared amongst a 2.7 multi-sites site, a normal 2.8 and normal 3.x installs. However, I also see it sometime on a machine with 3.x only. I'll try to keep an eye on it.

[Robin S]

For anyone not following the issues repo: Ryan has committed a fix for this issue to the dev branch.