dragan

https://processwire.com/api/ref/modules/refresh/

When you do an accessibility audit on the forum (and the main PW site) there are tons of color contrast failures (among many other issues). WCAG 2.1 states that color contrast has to be at least 4.5:1 for copy text, whereas here most text is below that. And yes, font size and line-heights are too small. body base font size should be at 16px with line-height 1.6 (unitless, not in pixels). And ideally, all other font-sizes further down should be specified in em or rem. The main container could be reduced: e.g. max-width 1280px instead of 1630px.

You could do it with a quick JS/CSS hack: (after you did the advanced mode stuff described above) let lis = document.querySelectorAll('#ProcessPageEditContent > ul.Inputfields > li.Inputfield'); lis.forEach(function(li, index) { li.style="order:" + index; }); document.querySelector('#wrap_Inputfield__pw_page_name').style="order: 2"; (only tested with Chrome + AdminThemUIKit)

I don't know anything about the linkedin post inspector. But I find it strange that you don't use a lang attribute in your html tag. Also, when I go to your sitemap.xml and view e.g. https://brightnode.io/it/projects/cosquare/ in my browser, I see this in the html head: <link rel="alternate" href="https://brightnode.io/en/projects/cosquare/" hreflang="en"> <link rel="alternate" href="https://brightnode.io/en/projects/cosquare/" hreflang="x-default"> <link rel="alternate" href="https://brightnode.io/it/projects/cosquare/" hreflang="it"> The last one is not needed. I am already on the Italian page, so why does it generate a superfluos hreflang="it" on that page? The same is true for that page's English counterpart: https://brightnode.io/en/projects/cosquare/ As for the 301 redirect, I don't know what's causing this. And with all these issues, it's hard to tell what exactly is caused by the SEO Maestro module, or your own code-bits in your template (or some module configs). If you find issues with the module, you should post it in the module's support forum thread. btw, the explanation of what hreflang=x-default is supposed to be, and how it's meant to be used seems quite clear, according to this Google article: https://webmasters.googleblog.com/2013/04/x-default-hreflang-for-international-pages.html

Did you check your browser console? Do you see anything suspicious there?

Do you mean via API? Check out these forum threads:

I still believe it's an .htaccess / server config issue. It's strange that on some sites you actually see /http404 in the URL. Or maybe mod_security: did you check your server error logs? And the PW logs? Turn debug mode on and install Tracy Debugger to maybe get more infos.

@Soma in your README, at the bottom, you write: I was doing a few tests just now. For me, it all works wonderfully (well, at least in a local setup). Did you change something recently in that regard and forgot to edit the readme?

I never had problems with multilang install... but I'm using Laragon locally. The above error or warning message is somewhat misleading. Don't ever edit files inside wire/. What you should do instead, is go to setup > languages and then spot the according JSON file to translate, e.g. http://localhost/pw/admin/setup/language-translator/edit/?language_id=1012&amp;textdomain=wire--modules--languagesupport--languagesupport-module (or are these underlined strings direct links to these settings?) In my case, the locale was already there. However, I don't think this is the reason why you get these strange 404 errors. Did you install one profile after another in the same directory? Maybe there are some leftovers from previous profiles / installs. Check the .htaccess file. Maybe you need to adjust some settings there. Maybe delete everything inside site/assets/cache/ folder, delete your browser cookies, log out of admin, and retry.

You could save yourself a lot of string concatenation if you use the heredoc syntax

Wow, I didn't even knew you could do this: &field=yourfield It works even with multiple fields: &field=title,headline,summary. Is this a new feature? I don't know if it is expected behavior to only have this one field you edited on the follow-up page-edit screen as well. You see them in the URL as query strings &changes=fieldname. Maybe you could create a hook to also append the &field query params too after save?

I just tried out this multi-instance approach and Tracy returns this error: E_COMPILE_ERROR: Cannot declare class ProcessWire\FieldtypeRepeater, because the name is already in use on line: 31 in /home/devsite/www/prototypen/instance-2/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module Compile Error: Cannot declare class ProcessWire\FieldtypeRepeater, because the name is already in use (line 31 of /home/devsite/www/prototypen/instance-2/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module) This error message was shown because: site is in debug mode. ($config->debug = true; => /site/config.php). Error has been logged. $site = new ProcessWire('/home/devsite/www/prototypen/instance-2/', 'https://prototypen.devsite.com/instance-2/'); $home = $site->pages->get(1); $homeUrl = $home->httpUrl; $homeTitle = $home->title; echo "<a href='$homeUrl'>$homeTitle</a>"; Path and URL are correct, and both PW sites are on the same server. I'm calling it from a PW 3.0.108 installation. Instance 2 is 3.0.126. Weird.

Yes. However, I tried it first on top of a heavily customized site. I guess there were too many hooks or modules etc. that got in the way. This evening, trying it out on a clean fresh latest dev installation, it works like a charm.

$c = 0; foreach($item->images as $photo){ echo "<li uk-slideshow-item='$c'><a href='#'><img src='{$photo->size(150,100)->url}' alt=''></a></li>"; $c++; } just use a good old counter var instead

I don't see any such link. pw.com belongs to PricewaterhouseCoopers LLP anyway o_O