Maybe a bug in SS markdown?
The old code generated:
<a href="(faulty-link)">assertEmailSent</a>
<code>which can simulate sending emails through the</code>Email->send()` API
Instead of the expected:
<code><a href="(good-link)">assertEmailSent</a></code>
which can simulate sending emails through the <code>Email->send()</code> API
faulty-link = http://api.silverstripe.org/search/lookup/?q=SapphireTest->assertEmailSent(&version=trunk&module=framework)
good-link: http://api.silverstripe.org/search/lookup/?q=SapphireTest->assertEmailSent()&version=trunk&module=framework
I was trying
Member:
extensions:
MyMemberExtension
And it didn't work then someone on IRC pointed that I need to put a '-' before values. So this works.
Member:
extensions:
- MyMemberExtension
Hope will help someone else.
Since ViewableData was returning a casting helper for Link, but DataObject was
only using $this->$fieldname to set values on that casting helper, you could
not use <% if Link %> (or <% if $Link %>) in your templates because Link is not
a field, and thus had no value to be set on the casting helper, causing
hasValue to think that there was no value. Since DataObject->dbObject says that
"it only matches fields and not methods", it seems safe to have it call db(..)
to get the field spec, and not call ViewableData->castingHelper at all.
Removed trigger background. Incidentally this also makes it less
obvious that the trigger has too much padding on the right
(which I can't figure out ...)
It doesn't make sense to show it there, since the "delete"
action has no effect, the "edit" button only collapses (useless),
and the thumbnail duplicates.
450px width are often not available to the dialog (with all margins/paddings subtracted from the window).
Ensure the URL doesn't cause an unnecessary wrap. Ideally we can size this to the dialog width
automatically of course.
NOTE: This change should be reviewed to make sure it does not cause any side effects.
Example use case:
An admin porting user images from an old website.
The script would put the images in the assets folder,
and then insert them into the database using Image::write()
and data from the old database.
public function insertImage($data) {
$image = new Image();
$image->ParentID = $data->parentId;
$image->Title = $data->title;
$image->FileName = $data->filename;
$image->OwnerID = $data->ownerId;
$image->write();
// In the current version, this results in all images
// being owned by Member::currentUser() instead of
// the expected $data->ownerId;
}
Wasn't parsing data-editor attrs correctly.
Using proper instances of the underlying editor now,
instead of relying on "active editor" states which get
wonky once they lose focus (e.g. when opening a dialog).
