[HiroiSekai]

Ah okay, I thought it would be as simple as just reversing the search method but it sounds like it’s more complicated. While we’re on the subject of search, is there a way to prevent the search from searching through my pages and individual file uploads? It’s even digging up my logo image upload and maintenance pages, and I don’t want visitors seeing them.

Thanks as always!

[HiroiSekai]

Hi David,

The results are matching now, but the fix was done in reverse. Both searches now don’t match the keyword to title, as the normal search did before the change.

To be more specific, the first article result before the change on the normal search was “STRIKE BACK! ECHOES’ WINTER 2011/2012 IMPRESSIONS” and the AJAX search showed “RIDE THE SKIES! CHROMA’S SPRING 2016 IMPRESSIONS!” first. Basically looking to revert the normal search back to show “STRIKE BACK! ECHOES’ WINTER 2011/2012 IMPRESSIONS” first, but have the AJAX search match that as well.

Thanks again for your assistance on this.

[HiroiSekai]

Hi David,

I changed it back to the Child theme, no changes. I think the problem is the AJAX PHP you sent still sorts results by descending publish date, while the full results search page does a different type of sorting.

[HiroiSekai]

This reply has been marked as private.

[HiroiSekai]

This reply has been marked as private.

[HiroiSekai]

Thanks David. I pasted the code into the functions.php file and nothing happened. I tried it on both the Cardinal and Cardinal Child themes to be sure, but no changes occurred. I did notice that the PHP does contain an “orderby:date” query, maybe that has to be altered? I’m not sure what else I could put in its place though.

Thanks

[HiroiSekai]

Thanks as always, David.

1) That fixed it up real good this time, many thanks.

2) Understood. Could you double check something though? Just for example, when I search “2011” in my search bar, my 5 shown results in the ajax_search_result section does not match up what I see when I click “See All # Results”. The 5 I see start at around 5 or 6 results down the page, bypassing the first few that actually make sense as a result. This is best demonstrated if:
– You click the search on the homepage (http://hiroi-sekai.com)
– Search “2011”
– Note the 5 shown results
– Click “View All 38 Results”
– Find the 5 shown results above several posts below the top hits

There must be something wrong? It’s like there’s a offset counter affecting it or something.

3) Understood, fair enough.

Thanks as always.

[HiroiSekai]

Quick update: once I cleared my website cache, that bit of CSS caused the search icon to be clickable across the entire width of my header. Naturally, my page links are not clickable. What is causing this?

Also regarding the search that I forgot to ask: just like the way related posts are selected, is there a way to alter how the search feature sorts through posts as well? At the moment, I’m thinking it takes the search query and just looks for any appearances of those terms within any posts on the site. The problem with this is that the results shown are often not matching to the titles themselves. Is there a way to change the search results to use the terms to search titles instead of post appearances? If I type “2011” I want to see posts with 2011 in the title, not posts from 2016 where I happened to mention that year.

Would really appreciate the help on this menu issue as well as the search and related posts limits. Thanks!

[HiroiSekai]

1) Problem solved, thanks! There was something else moving my .ajax-search-results bar back up, but that was a simple fix.

2) Here are two posts with similar categories/titles, but separated by a year in posting date:
http://hiroi-sekai.com/stargazing-beautiful/ (from 2011)
http://hiroi-sekai.com/stargazing-call-me/ (from 2012)

I do at least 31 of these posts a year, and these 31 are usually one a day in December. Is there a way to alter what shows up in related posts through the PHP documents? I’ve been getting feedback from followers that every one of the posts in this category always recommends the very first 4 posts of this category I made back from December 1-4, 2011. At best, I’d love for it to take the posts with that category tag or titling system, then randomly generate four posts to show for variety.

3) Many thanks, much appreciated. The current mobile menu is so heavily engrained into the PHP that I’m uncertain of trying to break it down and make my own. It would be great to have some customizability for a completely different look!

Much appreciated as always, great help.

[HiroiSekai]

Ah I did not see that button. It’s all good now, thanks!

[HiroiSekai]

Wow, I just received the new update, and what a change. I’m flying through posts now. Huge props and thanks for this excellent update.

[HiroiSekai]

Hi David,

Thanks again. I thought about splitting it up more and more, but I think that’s actually been more destructive than helpful in this case. Because image previews still load in each of these blocks, it actually makes moving and organizing these blocks insanely laggy since it has to re-render the preview image as the blocks get moved around.

I think the best way would be if we could have a toggle in the Theme Settings to turn off the dynamic live content preview (including images, audio player renders, youtube preview boxes, etc.) so the backend doesn’t have to load this ridiculously heavy load. It would help quite a bit as the frontend load for these posts are actually quite clean and smooth in terms of speed. Either that, or if there’s a way to at least reduce the resolution/dimensions of the preview images to something much smaller, that could reduce heavy load by a decent bit at the very least.

Would love to hear what the team decides is best for this. Many thanks again for looking into it.

[HiroiSekai]

Hi David,

I appreciate it. Looking forward to hearing back from you about the resulting discussion.

Many thanks.

[HiroiSekai]

Hi David,

I asked my host directly and we ended up running some tests using a query plugin. The results were a bit shocking. Loading the frontend page through GTMetrix showed a load of about 7 MB on one of our largest posts, but through the backend query, it had to load over 66 MB of content in the preview.

The support team took a look and deduced that it’s likely the fact that the Swift Page Builder is loading all of the preview images in full resolution and size within the builder every time. Their suggestion was this:

“Your best option is to request your theme developers to add an option to disable the preview images in the page builder. They could approach this in multiple ways including disabling the image preview entirely, rendering a tiny version of a thumbnail instead, or showing embed shortcodes instead of the actual image. They could even add a toggle switch in their custom settings so users could choose between leaving the image preview on or off. As it is currently laid out, any post with a decent number of images of any kind could potentially see significant slowdown.”

I would love to see this utilized, or find a way to alter the settings myself in the coding. At the moment, the page load on the backend is insane from the page builder. If you’d like to have a look, I’ll keep the Query plugin running, and you can see firsthand how crazy inflated some of these posts are getting on the backend alone.

Would love your assistance on this matter, hopefully we can implement a fix for the page builder. Many thanks.

[HiroiSekai]

Hi David,

Nothing specific done at all, the blocks just take a long time to move because it lags here and there. If you check the other post I mentioned, it’s even more noticeable.