After converting the WordPress export to Markdown, you will find `<!– more –>` tags in your content. These tags serve as delimiters in WordPress, allowing you to define where the excerpt ends on listing pages.

The Challenge

Astro does not provide a built-in mechanism to handle these tags. I also could not find a suitable plugin that would manage this functionality.

My first approach was to use a Remark plugin like remark-excerpt. However, this did not work as expected. Instead of adding an Excerpt property to the frontmatter or to the data object of the content collection, it simply replaced the Content with the Excerpt.

Writing a custom Remark plugin proved challenging as well. While extracting the excerpt markdown is straightforward, rendering it to HTML is not. Since Astro does not expose its renderer (yet*), you would need to create your own renderer or use Astro’s internal `astrojs/markdown-remark`. Both approaches are rather hacky and not really recommended.

* There are ongoing discussions about making the renderer API public: Astro Roadmap Discussion #1094.

The Solution

The current best way to handle the WordPress More Tag in Astro is to split the rendered HTML content directly.

On the list page where you want to display the excerpt, you can map over the entries, split the rendered HTML at the <!--more--> tag, and add the excerpt to the return object:

const previewPosts = await Promise.all(
	posts.map(async (post) => {
		const fullHtml = post.rendered?.html || '';
		const moreIndex = fullHtml.indexOf('<!--more-->');
		const excerptHtml = moreIndex !== -1 ? fullHtml.slice(0, moreIndex) : fullHtml;
		const hasMore = moreIndex !== -1;
		return { post, hasMore, excerptHtml };
	}),
);

{previewPosts.map(({ post, hasMore, Content }) => (
	<div class="preview-content">
		<Content />
	</div>
	{hasMore && <p class="read-more">Read more...</p>}
))}

Straightforward and effective :)

Integrating the Blog in Silverstripe (which indeed would have made things simpler) was not  an option at the time. The usage of loads of WordPress plugins would’ve made a rewrite a major task, which was out of the budget.

The blog was integrated in the same page layout as the rest of the website. So ideally it would at least share the same Templates for header, footer etc. and would integrate the sites navigation built by Silverstripe.

But how to use the pre-rendered Silverstripe template .ss files in a WordPress theme?

The following worked fine for me, using Silverstripe 3.0:

In the functions.php of the wordpress theme i added this code to init a silverstripe controller:

//init silverstripe
require_once '[path-to-silverstripe-root-folder]/framework/core/Core.php';
require_once '[path-to-silverstripe-root-folder]/framework/model/DB.php';
//init the Database connection
DB::connect($databaseConfig);
//fetch some page, it that case i used the 404 ErrorPage
$SSPage = DataObject::get_by_id('Page', 4);
//init a the controller and cache it as a global variable
$SSctrl = new ContentController($SSPage);
//add the controller to the stack, so it becomes available as the current controller for the template
$SSctrl->pushCurrent();

and also some helper functions to get the actual templates

function get_Silverstripe_Header()
{
    global $SSctrl;
    //render the controller with the includes/Header.ss template
    return $SSctrl->renderWith('Header');
}

function get_Silverstripe_Footer()
{
    global $SSctrl;
    //..or any other template, like the footer
    return $SSctrl->renderWith('Footer');
}

…and then just use these in the templates:

<?php echo get_Silverstripe_Header() ?>

Of course this is no way limited to WordPress. It just an idea how to access Silverstripe Templates outside of Silverstripe code.

//wenn "local" in der Domain vorkommt, sind wir lokal unterwegs

if(strpos($_SERVER['HTTP_HOST'], 'local.') !== false ){
  define('DB_NAME', 'mydbname');
  define('DB_USER', 'mydbuser');
  define('DB_PASSWORD', 'mydbpassword');
  define('DB_HOST', 'mydbhost');
}

//ansonsten auf dem Produktiv Server

else{ 
  define('DB_NAME', 'mylivedbname');
  define('DB_USER', 'mylivedbuser');
  define('DB_PASSWORD', 'mylivedbpassword');
  define('DB_HOST', 'mylivedbhost');
  //wenn man möchte, kann man hier noch die FTP Daten eintragen 
  //und damit "one-click" die automatischen Updates laufen lassen
  define('FTP_HOST', 'myFTPhost');
  define('FTP_USER', 'myFTPuser');
  define('FTP_PASS', 'myFTPpassword');
}

//damit die ganze Kiste dann auch ohne Anpassungen funktioniert,
//muss man hier aber noch die WP_SITEURL und WP_HOME aus der DB überschreiben
//(und zB. dynamisch halten oder eben in die if Abfrage mit reinpacken)

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] );
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);

Klingt komplizierter als es ist. Im einfachsten Fall wird jemand der

http://www.domain.com

aufruft, auf

http://domain.com

umgeleitet. Klappt auch ganz hervorragend.

…

Ausser wenn nach dem redirect das “www.” aus irgendeinem Grund zwar aus der URL, aber nicht aus dem http-Header verschwinden möchte  Dann wird WordPress schön weiter redirecten und fertig ist die Endlosschleife.

Ausführlicher erklärt ist das alles hier.
Dort hat Schnurpsel der Autor hat auch direkt ein WordPress Plugin (123 True HTTP Host 0.10), was diese Merkwürdigkeit 1a ausbügelt.

Denn dank des Plugins ist die Verschlagwortung von Artikeln binnen kürzester Zeit erledigt und, via Zugriff auf die Yahoo terms extractions API und den Service Tag The Net, werden bekannte Personen, Namen und andere Ausdrücke, die man vielleicht selber gerade nicht auf dem Schirm hat, aus dem entsprechenden Pool gefischt und jeder Artikel ist mit wenigen Mausklicks getagged.