LocomotiveCMS: Page not pushable - locomotivecms

I have already asked this on the LCMS Google Group, but the post got 3 views in a week and I can't continue my project with an entire page missing...
I have been getting an error when trying to push a specific page on wagon 1.5.4 on locomotivehosting and on my own hosting server. Everything works fine on the local wagon serve.
Warning: NOT all the pages were pushed.
Check that the pages inheritance was done right OR that you translated all your pages.
The strange thing is that it works on some pages that are almost identical (see below). My original problem was with the "elektronik-entwicklung" page.
Image: some pages were uploaded, but not all.
What I have tried:
deleted and re-pushed entire website
pushed pages with different slugs and same content, which only worked partially
I tried updating a lot of almost identical pages just with varying names and slugs, only to find out that there was no system behind the choice of which pages got uploaded (e.g. "l-entwicklung.liquid" got pushed, but "a-entwicklung.liquid" didn't get pushed; cf. image on Google Group post).
The files I created to test have the same content, just the corresponding slugs are different. E.g.:
---
title: Elektronik
slug: elektronik-entwicklung
listed: true
published: true
---
{% extends engineering/engineering-subpage %}
Any ideas?

After a lot of pain, I finally decided to upgrade the whole thing to locomotivecms 3.0 and wagon 2.0.
This solved the problem.

Related

SharePoint Quick Part Label Stopped Working

We are currently migrating our EDMS into SharePoint. As part of this workstream, I recently set up a SharePoint site with a Quick Part Label containing just the version number - as per the instructions here.
This worked fine in testing, now a few users have been added to the site and the migration works have begun. The option for "Label" within Quick Parts has simply dissapeared.
I tried some trouble shooting on Friday and found the following:
Recovering an old document from the recycle bin, still contain a correct version number label.
This label can be copy and pasted to a new document, and it correct applies the label quick part with the new documents version.
I set up a new test site and the Quick Part Label behaved exactly as expected, meaning the issue is within the Live SharePoint site itself.
I turned off labels and reset them. With no success.
I am opening in the app, the library has minor versions, check-in/check-out turned on (and currently approvals are turned off).
I also suspected that OneDrive sync might cause issues, but this again didn't seem to solve anything in the test site.
NB: this is also posted here, I will keep both threads up to date.
Screenshot showing label missing
Update 20/12/22
Since this morning I have now taken the following additional steps:
Added a new content type
Recreated the label for that content type
Change the content type of the document in the library, and the label
option now appears
This seems like a fix, but I am also curious as to limitations of
this method.
Limitations noticed so far: cannot edit SharePoint columns in the
details pane

Pagination with Blog/index.html in Jekyll-3.2.1

I am having a problem that seems to be somewhat common with using pagination on pages other than index.html in a Jekyll project.
I found this post that seemed to be exactly what I am looking for:
Jekyll Pagination on every page
However, the solution does not work for me. According to the documentation on Jekyll's website, the following code in _config.yml should change the paginator to use /Blog/index.html rather than /index.html:
gems: [jekyll-paginate]
paginate: 2
paginate_path: "/blog/page:num/"
I have rebuilt and restarted my local server, but the paginator still only works on the /index.html and not /Blog/index.html.
Does anyone have an idea what I could be missing here?
The paginator internal logic is to :
(from code comment) "Determine if a page is a possible candidate to be a template page. Page's name must be index.html and exist in any of the directories between the site source and paginate_path."
choose the one closest to paginate_path in length.
In your case Blog/index.html is not recognized as existing in /blog/ path, because Blog != blog.
Or you rename your containing folder to blog, or you set paginate_path: "/Blog/page:num/"

docpad as blogging engine, pagination and problems related to many posts?

I spent the last day setting up docpad as a blogging engine, starting from https://github.com/balupton/website
After getting everything working and looking the way I like it I came to one last issue -
In the page showing all blog posts I output document.contentRenderedWithoutLayouts for each document in #documents.
I have to be ready to handle a reasonably big blog
This means I need to do pagination.
What seems like the best way to do that?
I was thinking having posts in subfolders inside of blog, but then I have to iterate folders
assume each folder is a page paginate to next page
need to also sort so that the folder with the newest posts is the first, the folder with the next latest is rendered as page 2
Perhaps your best bet is the Paged Plugin, it will automatically split a specified document into multiple documents, and inject them into the database. Does that work for you?

SEO: Google fetch returns blank page (but rendered HTML seems correct)

I usually find all the answers to my question but this time I could not find any. This if actually the first time I post on stackoverflow!
Here is my problem.
The root of my website: "www.example.com" returns a blank (not empty) page when I use Google Webmaster Tools to fetch my website. When I look at the rendered HTML, it is exactly what it should be, but the preview of the page is just blank.
All the other pages of my website like "www.example.com/sample_page.html" seem to give the proper preview though. I have even tried to make a redirection (htaccess) of the root domain "www.example.com" to "www.example.com/sample_page.html" but it also gives a blank preview.
I use cached HTML files so it does not have anything to do with enabled JS or whatsoever. Furthermore, like I told you, the rendered HTML seems OK it's just the preview that does not return anything.
Any hint is greatly appreciated as I have been trying to find a solution since a few weeks now.

Mediawiki / Excel: Hyperlink from Excel to a non-existant wiki page gives a 404 - how can I fix or work around this?

I suspect this could be something faulty with Excel (although I keep an open mind), but I wondered if anyone knew how I could get around this apparent bug:
I wish to create Excel spreadsheets which link to pages in a local wiki (running MW 1.14.0, full details below) where those pages don't yet all exist.
The idea is that over time we will fill in details of the pages, but we would like to create the links now (because copies of the Excel files will get sent out to various internal users and it will not be feasible to go track them down and add links later once the pages are created)
The problem is that when I create such a hyperlink in Excel and then go to follow the hyperlink, I get a message back indicating that the page does not exist. The full text of the message is:
"Unable to open http://. The Internet site reports that the item you requested could not be found. (HTTP/1.0 404)"
This happens on our site or in fact if you link to a non-existant page on wikipedia (e.g. http://en.wikipedia/wiki/Swed53rf). Whereas if you put such a link into a browser you get the correct response (which is to be taken to a page indicating that there is no such page but that you can create it by following the usual link)
Is there some setting on Apache that I might need to configure / override to make sure it returns a valid server response to Excel?
Creating links to existing pages works fine. I appreciate that in theory we could go around creating all the pages that are required, but some of the people involved in the project (creating the initial Excel files) do not / cannot use our wiki and it would be better if this just worked as it would appear it should rather than having to try to add steps to work around it in this way.
I also wondered if it were anything to do with the short URL reformatting. Our wiki, like wikipedia has short URLs, eg:
http://server/w/index.php?title=User:Joe_Blogs/Sandbox
can be reached from
http://server/wiki/User:Joe_Blogs/Sandbox
but including hyperlinks to the full name versions of the pages does not resolve the issue.
The version of Excel being used is Excel 2003 (SP3)
I have discovered that this also happens with Word 2003 (I imagine they are using the same code). However the desired behaviour occurs with Lotus Notes (a miracle, as it's rubbish in so many other ways! )
I have not done any significant development on Apache, but I could consider some form of custom page that re-directs to the non-existent wiki page if Mediawiki changes were deemed to complex/tricky. (although I'm not particularly sure where I'd start with this idea, I'm guessing some sort of URL parameter to accept the destination pagename might be a possible approach)
Any helpful suggestions gratefully received!!
[FYI: I have posted a question on MWUsers forum (www.mwusers.com) too after Googling this to no avail! I'll update the forum response there if I get an answer here or vice versa]
Many thanks,
Neil
Running on Ubuntu Server 8.10
Product Version:
MediaWiki 1.14.0
PHP 5.2.4-2ubuntu5.6 (apache2handler)
MySQL 5.0.51a-3ubuntu5.4
Installed extensions:
CategoryTree (Version r44056)
Renameuser
CategoryTree (Version r44056)
ImageMap (Version r35980)
ParserFunctions (Version 1.1.1)
StringFunctions (Version 2.0.2)
Not sure how to get Excel to let you go to a page which turns out to be a 404, but as a temporary workaround, you can hack out MediaWiki's 404 reporting on missing pages...
In MediaWiki 1.14 or 1.15 releases this will be in Article::view() in includes/Article.php:
if( $return404 ) {
$wgRequest->response()->header( "HTTP/1.x 404 Not Found" );
}
Note that the latest dev code is a little different, but you can find it where it sends the same header in the same file. :)
Wikipedia returns a 404 with a redirect which gets you to the page you want; my guess would be that Excel's rendering engine is not following the redirect.
You could try capturing the conversation in Wireshark, both with a browser and with Excel. That might show you what's happening differently.
Surely once you roll out the new pages, the links would start working, though?

Resources