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?
Related
Is it possible to extend Shopify objects in Liquid? I'm trying to find a way to have there be more than 1 photo associated with articles belonging to a specific blog. I know I can allow users to upload more photos using the settings schema, but I need to access the photo URLs outside of the Blog template/section the same way I'm able to access its direct properties (something like article.images[2]). My understanding is that anything saved from Settings is only accessible from within the Section in which it was defined. Is that accurate?
I have the idea of saving a list of URLs as the article's content and just parse them out of article.content (and hide the list using CSS when the page is displayed), but I'm not seeing any way to do the parsing (no regEx).
I thought of using tags too, but there will be hundreds of articles and potentially several images associated with each article. I"m not sure if there is a max number of tags, but even if there isn't, it seems hack-y (and probably a bit inefficient to create tags that aren't shared by multiple articles. IDK...
Does anyone have any ideas for a good way to do this?
Metafields are done for these type of cases:
https://shopify.dev/api/storefront/2022-01/objects/metafield
I am building a big blog application with express and my question is about how big blogs and big applications structure their files.
For my application, I am making a new ejs file for every blog article that I write. I am doing this because each blog article that I write has a different amount of pictures, different headings, etc. However, I am realizing that there are a lot of files building up.
Is there a better way of doing this?
I thought of storing the article contents in the database but due to the contents of each article being different I didn’t think this was viable.
something like this
let articleText = query db for article text;
res.render("article.ejs", {blog_cotent: articleText});
For my application, I am making a new ejs file for every blog article that I write. I am doing this because each blog article that I write has a different amount of pictures, different headings, etc. However, I am realizing that there are a lot of files building up.
Is there a better way of doing this?
You should be able to use the same EJS template for each blog entry, so "yes" there is a better way of doing it. For us to help more specifically, we would need to see how you're storing and naming your images and how you know which images go with which blog post. Shouldn't headings be part of the content itself which is unique for each blog post and not part of the EJS template?
Yes, the headings would be part of the content which is unique.. you are right. Now my question is... if every article should use the same ejs template, what do I do when articles have images in different places within the article? Or, how would I handle article one containing a list of steps while article two does not contain that list?
Can't your unique content for each blog contain EJS and insert it in a way that it gets processed as part of the template? So, you could use EJS commands in your content. Or, you could make your own simple tags in the content that your JS processes and inserts the right things (but it would be better to just let EJS do that work).
On the website I run we have a single search field where you can enter a name or profession. When you search you are served with a page full of results that come from 3 seperate sources.
Once you click on one field e.g. John Do, you will be taken to his page. On that page we have a back to search, but it goes to a blank screen.
I want to go back to the actual search results so the person doesn't have to do it all again, but I'm not sure where to start. Any suggestions?
That's a tricky situation.
There can be many solutions for this issue but I'll will name some of them.
Activate the cache of the pages (Quick trick, no suitable for websites that relies on users (*login)), you can go back and your form will be the same with the results without any issue.
Manage the load of the page of Jhon Do as a ajax load and #hashtag references, you don't reload the page but you just manage the states of the HTML. (Can be done with JS frameworks or React)
Depends on which platform are you working try to manage the variable of the search with this concept post-redirect-get
Hope that is helps!
Cheers.
We are using Liferay as a classic CMS meaning that we compose pages using web content articles. There is an issue with Liferay's internal search I could not yet find a proper answer for:
Because web content articles are pretty much only building blocks for pages we don't want the search to show them as distinct items. The user should only get a list of pages that contain their search keywords, including all the articles put onto this page.
At the moment we can see two different approaches and both come with certain problems we could not solve yet:
Idea 1
We modify the journal indexer and try to obtain all URLs of the pages (how?) where the article has been placed on. Then we add them to the document to be indexed. In the search result we then can access the URLs and collect them. In the end we make sure every URL is only shown once.
Idea 2
At some point Liferay renders the entire page before sending it to the browser. If we somehow could put an indexer there, we could index the entire page. We then could limit the search to the special "page documents". Getting the fully rendered page would be the main issue here, because either we would have to run a crawler to frequently trigger this indexing or we would need to find a way to trigger page rendering from within an indexer or something like that.
I have been carrying this problem around for quite a while now and still could not find an idea good enough to spend time trying it out. If anyone of you has some input on those two ideas or maybe an entirely different approach, I would be extremely grateful.
I'll just answer myself, because by now we found a suitable solution to solve our problem:
In addition to the default search portlet there is also a "Web Content Search Portlet" shipped with Liferay. It seems to have been part of Liferay for quite a while now, but it's somewhat hard to find, because there is hardly any documentation for it (I only found the Liferay wiki page, which isn't really anything at all). It searches only within web content articles and shows links to the pages rather than just a link an isolated view of the article. It has much less configuration options than the default search portlet, however. Pretty much all it allows to change is whether articles actually have to be placed on at least one page to show up in the results.
So there is no need for any kind of custom indexer or any other "hack"...all we need to do is use the correct portlet. We will only need to write a hook that changes the appearance of the result page.
What you ask is interesting but your ideas are on the wrong direction.
Specially idea 2 it's particulary wrong because you cannot do indexing work meanwhile a page is rendered. Think about performace only.
In Liferay pages and assets are not directly linked: pages have portlets and portlets display assets (web content and more).
Liferay indexing refers and scans assets content, not refers the display result of the assets. Think about permission: the same page can display different contents depends on the user who looks.
bye
I have a search engine that searches albums.
For each music album, I have a page.
So, the work flow goes like this:
People search for music titles
The search engine displays a list of albums.
People click on an album to go to a details page.
I want google to index my front page and the details page. I want the details page to be highly ranked. How can I build a sitemap for this?
By the way, I have about 5 million albums (but I want the top 1000 ones to be highly ranked on google)
You would not use a sitemap for that many results. You would want each album to appear as a page with a unique URI to reference that page. That way the search engine can crawl your site by crawling links since search bots cannot submit form data. Each of those URIs should be simple, meaning limited to this part of the URI syntax:
scheme://authority_segment/path
Program your web application to remove and throw away any extraneous data, such as query string or parameters. If you do this you have to be sure that you are watching for URI poisoning or SQL injection even through means of character encoding.
How can I build a sitemap for this?
By pulling the addresses out of your database and creating a XML file with a high priority for some selected pages. Somehow I think that isn’t your real question …
If I wanted to automate building a site map for a site like this, I'd employ Python. I'd pretty much write everything from the ground up (except the data store access). The format is quite simple.
I'm not sure I quite understand your question...