Sorry for the delay, I only just installed v1.3.3 on my working copy. I reverted all my quickfixes (only keeping files from the archive that is available here) but I have not tested on a fresh XF install.
I think I fixed this in a previous update. Does this still happen with newly created articles? Can you run the rebuild caches and see if this fixes it for old articles?
NOK : I can confirm this is still an issue with v1.3.3 on my WC, with either new or old articles, even after cache rebuild (article & article page) and even after hourly library cleanup. This is how I fixed the Waindigo_Library_Model_Article::getPageNumbers() function
PHP:
public function getPageNumbers($pageCount)
{
$pages = array();
if ($pageCount > 0)
{
for ($i=1; $i <= $pageCount + 1; $i++)
{
$pages[] = $i;
}
}
return $pages;
}
OK : for 's.
It is now a lot easier to link threads to articles.
NOK for "created_date bug"
There are still some "$article.created_date" used in the following templates, once in each of them:
- waindigo_article_container_library;
- waindigo_search_result_article_library;
- waindigo_search_result_article_page_library.
The resulting effect is the current date displayed in place of the actual article/article page post_date.
NOK for article page inline edition : when editing an article page inline, making changes to the page content, then clicking "More Options...", the changes are lost. I fixed this by adding this test in Waindigo_Library_ControllerPublic_ArticlePage, anywhere after getting $articlePage in actionEdit():
PHP:
if ($this->_input->inRequest('more_options'))
{
$articlePage['message'] = $this->getHelper('Editor')->getMessageText('message', $this->_input);
}
Next is not a bug, but rather a question : wouldn't it be better SEO practice to either throw a 404 error or link to an article's first page when accessing a nonexistent page? Currently, this case only displays an empty page.
I hope this helps. Thank you for your work !
