Posts by dunc

Yeah, it's probably Azure introducing the problem. I can give it a go myself at some stage (I'm playing a lot with containers\Kubernetes at the moment). What are you using - App Services (for containers) or Container Instances or Kubernetes Services?

I don't think Azure Storage will work with Perch. It may work with Runway, but will probably need a storage driver written for it. Runway comes with storage drivers for AWS S3, Dropbox and OpenStack.

With containers, there is a way to get round the "home" folder issue by packaging your container into a Docker Compose multi-container.

The link here explains more https://docs.microsoft.com/en-…gure-multi-container-apps

Otherwise, utilising Azure Kubernetes will allow you even more flexibility with your config/setup.

The docs for pagination (https://docs.grabaperch.com/templates/pagination/) show a “total” variable being available.

Also, if you use <perch:showall/> in the template with the pagination, it will show you all the variables available to you.

Line 2 has a non-closed perch:pages tag. It’s stopping the lastmod tags showing.

I guess the version in use is pre-3.1 (or whichever version introduces self-closing Perch tags).

That sounds like something that has been raised before - I think making saves in the meta tab is a little buggy. I believe it's due to be potentially fixed by using field groups instead of a separate tab - maybe it will appear in Blog after the Perch 4 upgrade? Purely a guess on my part!

Are you confusing categories and sections? Looks like you've named them both the same ("news"), but the individual posts look to be set to section id 1 (probably the default "posts"), not 2 (probably "news"). The section is set per post, on the meta and social tab...

You can use template filters to provide similar functionality:

https://docs.grabaperch.com/api/template-filters/

Quote from seoMatt

dunc Thanks for the reply. Can I ask you a couple of more questions about your experience?

• Why did you switch?
• Have you noticed any performance benefits?
• Was it a fairly painless transition or was there a learning curve?
• Do you still use PHPMyAdmin with MariaDB or do you perform most tasks with the command line?

I appreciate your time. I've been looking into it but prior to doing anything I like to gather info to see if it makes sense for the way I work.

Hi Matt,

I switched because at the time I was looking to run stored procedures and views in a database and MariaDB did that better than MySQL - the switch was painless, zero learning curve.

At the time, there was meant to also be a performance benefit and to me it 'felt' faster - but that is purely anecdotal, as I didn't run any kind of benchmarking. And of course, there's so many other places to slow things down, that the performance benefit was negligible.

I still use PHPMyAdmin with it and it works fine. Although I do also use the command line. Which is also fine...

All in all, no issues what-so-ever. But again, I did this a few years ago.

I've been using MariaDB for a few years now - no problems to report. I like to keep it up to date - currently on 10.3.13 and again, no issues.

Hi both - do you mind if I turn this into a bit of a discussion?

Drew - I have a (kind of) related question/request - would it be possible to allow a "non-obvious" config file setting to stop the index table optimisation that happens after a write to the collection index?

The reason I ask this is due to my testing of changing the database/table engine to InnoDB - it appeared to give me a slight performance increase for queries, but it was unusable after updating anything - due to the optimisation failing on the InnoDB table.

Hussein - I have a site with about 1000 items in collections which equates to about 114000 rows in the index table - I'm expecting this to grow to at least 5x bigger than it is now, and I've seen some intermittent performance issues. Hence why I tried the InnoDB experiment, purely down to the fact that tweaking the InnoDB cache size seems to be more effective than tweaking the MyISAM cache settings (I could be wrong about this though).

I also tried a test with putting data into a CouchDB database (if you don't know it, it's another NoSQL document-based database, not too dissimilar to ElasticSearch) - as it uses JSON as its default data type, getting data in was easy. Getting it out was fairly trivial and in some cases a LOT faster - but as soon as the queries got a bit more complicated, it dramatically slowed. The same may happen with ElasticSearch...

Again, apologies for a thread derail - let me know if it's annoying and I'll hide it behind a spoiler tag!