The Add Alias page that can be accessed via admin/config/search/path/add now requires that values entered for both of the fields Existing System Path and Path Alias must start with a leading slash. Otherwise, the form does not validate.
When filling in the form manually, error messages are displayed to that effect, so it's clear what the problem is.
However, when this is being done programmatically in an automated Testing case, it's not at all obvious what went wrong.
Here's a piece of original code to create a path alias to an existing node, written for a subclass of WebTestBase:
$edit = array();
$edit['source'] = 'node/' . $node->id();
$edit['alias'] = $this->randomMachineName(10);
$this->drupalPostForm($this->addAliasPage, $edit, t('Save'));
And here's the corrected code:
$edit = array();
$edit['source'] = '/node/' . $node->id();
$edit['alias'] = '/' . $this->randomMachineName(10);
$this->drupalPostForm($this->addAliasPage, $edit, t('Save'));
There seems to be an overall pattern that paths relative to the site root must now start with a slash. Besides these fields for the Add Alias page, I wrote in a previous post about such a requirement in calls to some methods of class AliasManager. And there's recent mention of this in Update the DB dump to have a leading slash for the frontpage.
Aug 19, 2015
Aug 14, 2015
Beta 11 --> Beta 12: AliasManager expects leading slash
As soon as I enabled the Optimizely module under Beta 12, I'd get the normal setup messages from the module, but then followed by this error.
The website encountered an unexpected error. Please try again later.
There was no other indication on the page of what had gone wrong. Moreover, the site would be completely unusable such that I could not even browse to the front page.
Eventually, I stumbled on a way to access the log. By deleting the directory for the module after the error occurred and using drush to clear cache, the site became usable again.
The log showed this message:
InvalidArgumentException: Source path node has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 191 of /var/www/html/opti/core/lib/Drupal/Core/Path/AliasManager.php).
This made me realize that the parameter in my calls to getAliasByPath() has to start with a leading slash. This also applies to the sibling method getPathByAlias().
So, for example, I revised the following function,
trait LookupPath {
static function lookupPathAlias($path) {
$alias = \Drupal::service('path.alias_manager')->getAliasByPath($path);
return (strcmp($alias, $path) == 0) ? FALSE : $alias;
}
}
to call a new helper routine.
trait LookupPath {
static function lookupPathAlias($path) {
$path = LookupPath::checkPath($path);
$alias = \Drupal::service('path.alias_manager')->getAliasByPath($path);
return (strcmp($alias, $path) == 0) ? FALSE : $alias;
}
static function checkPath($path) {
return ($path[0] == '/') ? $path : '/' . $path;
}
}
The fix was simple enough once I saw the error message in the log. The difficulty lay in getting to the log in the first place!
The website encountered an unexpected error. Please try again later.
There was no other indication on the page of what had gone wrong. Moreover, the site would be completely unusable such that I could not even browse to the front page.
Eventually, I stumbled on a way to access the log. By deleting the directory for the module after the error occurred and using drush to clear cache, the site became usable again.
The log showed this message:
InvalidArgumentException: Source path node has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 191 of /var/www/html/opti/core/lib/Drupal/Core/Path/AliasManager.php).
This made me realize that the parameter in my calls to getAliasByPath() has to start with a leading slash. This also applies to the sibling method getPathByAlias().
So, for example, I revised the following function,
trait LookupPath {
static function lookupPathAlias($path) {
$alias = \Drupal::service('path.alias_manager')->getAliasByPath($path);
return (strcmp($alias, $path) == 0) ? FALSE : $alias;
}
}
to call a new helper routine.
trait LookupPath {
static function lookupPathAlias($path) {
$path = LookupPath::checkPath($path);
$alias = \Drupal::service('path.alias_manager')->getAliasByPath($path);
return (strcmp($alias, $path) == 0) ? FALSE : $alias;
}
static function checkPath($path) {
return ($path[0] == '/') ? $path : '/' . $path;
}
}
The fix was simple enough once I saw the error message in the log. The difficulty lay in getting to the log in the first place!
Aug 7, 2015
"The RSA host key for git.drupal.org has changed"
Just now when I tried to git push to drupal.org I got a long warning message that started with the following.
The RSA host key for git.drupal.org has changed, and the key for the corresponding IP address 140.211.10.43 is unknown.
The article Drupal.org Git Server Migration and its comments give a good explanation and discussion about how drupal.org has migrated to different servers as of early July.
The steps I took to fix the issue on my Linux Mint system were as follows, where the -R option for ssh-keygen means "remove the keys".
# ssh-keygen -R git.drupal.org
# ssh-keygen -R 140.211.10.43
# git fetch
The authenticity of host 'git.drupal.org (140.211.10.43)' can't be established.
RSA key fingerprint is 16:f5:44:6c:a1:c6:be:72:cd:98:b5:b7:7d:26:d6:14.
Are you sure you want to continue connecting (yes/no)? yes
After that, there were no further warnings in using git to access drupal.org.
Instead of git fetch probably any git command that accesses the remote repo would have the same effect, such as git pull or git clone.
Source:
Drupal.org Git Server Migration
https://www.drupal.org/node/2529356
The RSA host key for git.drupal.org has changed, and the key for the corresponding IP address 140.211.10.43 is unknown.
The article Drupal.org Git Server Migration and its comments give a good explanation and discussion about how drupal.org has migrated to different servers as of early July.
The steps I took to fix the issue on my Linux Mint system were as follows, where the -R option for ssh-keygen means "remove the keys".
# ssh-keygen -R git.drupal.org
# ssh-keygen -R 140.211.10.43
# git fetch
The authenticity of host 'git.drupal.org (140.211.10.43)' can't be established.
RSA key fingerprint is 16:f5:44:6c:a1:c6:be:72:cd:98:b5:b7:7d:26:d6:14.
Are you sure you want to continue connecting (yes/no)? yes
After that, there were no further warnings in using git to access drupal.org.
Instead of git fetch probably any git command that accesses the remote repo would have the same effect, such as git pull or git clone.
Source:
Drupal.org Git Server Migration
https://www.drupal.org/node/2529356
Beta 10 --> Beta 11: String::checkPlain() moved to SafeMarkup::checkPlain()
It turns out that my blog post of last week was completely wrong in claiming that migrating the Optimizely module from Beta 10 to Beta 13 did not require any code changes. In fact, doing so completely breaks the site as soon as the module is enabled.
I'm not sure what went wrong during the migration. I must have had a brain burp and copied the wrong release into the test directory.
In any case, I have backtracked to Beta 11 and successfully migrated to it by making one coding change.
Method checkPlain() has been moved from class
Drupal\Component\Utility\String
to
Drupal\Component\Utility\SafeMarkup
I'm not sure what went wrong during the migration. I must have had a brain burp and copied the wrong release into the test directory.
In any case, I have backtracked to Beta 11 and successfully migrated to it by making one coding change.
Method checkPlain() has been moved from class
Drupal\Component\Utility\String
to
Drupal\Component\Utility\SafeMarkup
Jul 31, 2015
Beta 10 --> Beta 13: No code changes needed. But additional automated tests would help.
After a rather long digression of writing several posts about JavaScript in this blog, I got back to work on migrating the Optimizely module to Drupal 8, this time from Beta 10 to the recent Beta 13.
Once again, no code changes were needed.
Update: I made a serious mistake in migrating from Beta 10 to Beta 13. I thought that I had done so successfully without any code changes needed.
It turns out that I was testing against an older release, not Beta 13. In actuality, the Optimizely module completely breaks the site as soon as it is installed under Beta 13.
After discovering my mistake, I backtracked to Beta 11, where the method checkPlain() has been moved to a different class, that is, from String to SafeMarkup.
When I test this module against a new release of D8, I first carry out manual testing on the intended functionality, then run an automated suite of several tests written to the core Testing module.
When those automated tests all pass, they provide a lot of additional confidence that the module is working correctly.
At the moment, the suite consists only of the ones that I inherited when I started this conversion project. The suite lacks testing of two critical error conditions that must be detected when the user is editing projects.
Now, it's time for me to expand beyond that original set to provide some enhancements by adding new tests. For this module, D8 is a stable enough platform to start looking to new functionality.
Once again, no code changes were needed.
Update: I made a serious mistake in migrating from Beta 10 to Beta 13. I thought that I had done so successfully without any code changes needed.
It turns out that I was testing against an older release, not Beta 13. In actuality, the Optimizely module completely breaks the site as soon as it is installed under Beta 13.
After discovering my mistake, I backtracked to Beta 11, where the method checkPlain() has been moved to a different class, that is, from String to SafeMarkup.
When I test this module against a new release of D8, I first carry out manual testing on the intended functionality, then run an automated suite of several tests written to the core Testing module.
When those automated tests all pass, they provide a lot of additional confidence that the module is working correctly.
At the moment, the suite consists only of the ones that I inherited when I started this conversion project. The suite lacks testing of two critical error conditions that must be detected when the user is editing projects.
Now, it's time for me to expand beyond that original set to provide some enhancements by adding new tests. For this module, D8 is a stable enough platform to start looking to new functionality.
Subscribe to:
Posts (Atom)