horst

hey @Nomak, you said you have installed the module. Do you mean the module shipped within the PW core? How exactly have you installed it? (The questions are only for me to get clear informations.) You also can set debug to true, so there should or could be some debug log saved when the image sizing is processed and / or failed.

Have you tried to add the same template name with repeater_** set in front? Or how exactly the repeaters template is named? If I remember right, this should work. Example: You have a simple template called "mytemplate", and have a repeater field in it, you need to set up the CAI3 and CAI4 fields with BOTH template names. The one from the template and the one from the repeater field. (They have own, system needed, templates / templatenames)

Oh sorry to be not clear. I will update my initial post later with a link, when I'm back in the office. I'm speaking about the SEO yoast plugin for w*rdpr*ss, and available for other CMSs and as a bare JS libeary too, if I had read it right.

That's a good Blog post! I really want to read a part two, (and maybe three?). ? Also very useful for new starters, I believe.

(only what the title says) ?

Hey @Pete, I do not see any possible improvements with your code. (So this also may be a bit because my CLI knowledge of this tools maybe a bit lower as you expect. ? - On my local machine I (can & do) use other tools for those things. ?)

@bubu2110 have you already had time for a look into your Inbox? ?

@dotnetic Jens, when do we get an update to the latest stable? 3.0.200 ? Or is it already online and I haven't found it?

when it says 2) install the PagePaths module, you can find the module under modules > core in the admin. By default, the search through urls and paths is disabled, but you can enable it by installing given module.

Ah yes, there it is still in plain text too, but also the DB credentials are. But looks like a better solution indeed. Best practise is to have one single config.php file only, that one on the live server. No copies in GIT. And not a plain password in every DB dump! Thanks @fliwire

I'm not sure I understand completely. The password is saved in the DB (module config). If this can be read by someone, you have much more problems then a single smtp password. ? The smtp sending process explicitly needs the password passed in as plain text. So, if we would encrypt it before storing in DB, we would need to decrypt it before sending. If we use hash or salt, or keys etc, they must be stored somewhere (DB?). So, this would not be a "better" solution. Any ideas by you?

Short thoughts (on mobile ATM): PW cache API, PW template cache, PW ProCache, PHP memcache(?) AFAIK, Apache without ProCache handover a request to PHP, PHP has everything to rebuild what is not cached in some sort (cache API for pages or chunks of any sort; template cache for a complete template markup, or a complete "php page" in memcache). When things have to be rebuild, the mysql server gets involved too. At best would be PC, omits PHP and MYSQL; second would be PHP, it omits the MYSQL server; somewhere in between is a mix of cached and uncached bits that builds a complete page markup. Another strategy, (if its practical depends on your project(s)): serve a more or less bare HTML markup, with maybe direct content only for header section, H1 and first paragraph(s), and fetch all under the fold with progressive lazyloading (wide threshold). Or a combination of all. ? EDIT: additional: If you need to serve individual pages for each request, check your fields setups. Maybe you can "move" or optimize some parts to get be prepared on page save in the admin. (additional fields, hidden for the editors, that can contain combined data, that lowers the number of db requests for visitors, at a small cost for the authors on page save)

I never had the need to use raw text searching upon JSON objects. Looks a bit fragile to me. Have you thought about alternative storing strategies, other field types?

Isn't the escape character this one: \ ?

Hi Robin, I think one can do that a bit simpler, at least I always use it this way: 1) I'm not hundred percent sure, but maybe there is difference between cloning the whole template compared against only duplicate the fields. (Cloning definitely includes all settings under family, files, advanced, etc) 2) And this saves the creation of an extra template file. All in all very useful when I want to use something like a single controller file, that calls different view files upon the template names. ?