aagd

@fruid If your image URL is showing up normally in the meta tags, maybe the FB sharing cache got stuck. If FB has already cached the page, they might not parse it again anytime soon. But you could try resetting the cache at https://developers.facebook.com/tools/debug/sharing/batch/ . Enter your page URLs there and try again...

@ClausWell, I can't guess where you would need the output of the SVG. If you need it just before the body content, it could look s.th. like this: $content = "<div class='svg-container'>" . file_get_contents($page->image->filename) . "</div>"; $content .= $page->body; Note the .= for appending to $content. If you want the SVG to appear somewhere in the middle of the body content I'd recommend looking into the Hanna Code module. If all you need is a single (or few) SVG in your page body, Hanna Code might also work without an extra SVG field, when you'd copy the SVG source directly in a tag (Haven't tested this). You could then place the tag within the body field like [[svg]]. The body field will the need to have the Hanna Code Text Formatter added as last element (in body Field Settings > Details > Text Formatters) to be able to output the tag.

These are translatable strings. Means text in templates that is translateable via the Language module, but that's only editable in template code. Usually that's used for UI elements like buttons and other static texts. For editable content you need to create a (multi-language) field via Setup > Fields (or change existing text/textarea fields to their multilanguage versions).

@Claus Instead of the image tag <img src="<?=$page->image->url?>" /> you would directly write the content of the svg file <svg>...</svg> <?=file_get_contents($page->image->filename)?> filename should give the full server path to the file. A relative path might also work. Note that ideally there should be no XML declaration in the SVG file. Also be aware that a 'bad' SVG can break your page or can do other evilous things. You shouldn't allow editors to upload SVG files, at least not without testing (or hide the field for non-superusers). Inlining allows to access SVG contents through external JS & CSS. From simple color changes on hover to animations (CSS & JS), there are a lot of useful benefits. There are also other ways that might work for you here like using <object> or <embed> tags. A good overview is Using SVG | CSS-Tricks - CSS-Tricks

Do you output the SVG in an img-tag? Probably you need to output them as inline SVG, directly in the HTML with something like: file_get_contents($page->image->filename); Edit: I'd recommend an extra image field called sth. like "svg" that only allows svg format. You don't want JPGs end up inline like that. Also you probably don't need the XML declaration in the SVG.

https://processwire.com/blog/posts/new-user-admin-permissions-automatic-version-change-detection-and-more-2.6.10/#new-user-admin-permissions Did you also add the user-admin-all permission? (to be able to edit other users)

According to https://github.com/ryancramerdesign/FileValidatorSvgSanitizer there should be a log at Setup > Logs > File-validator, does it say anything?

found this, didn't test:

Are you on a shared hosting account? Wouldn't a server upgrade solve this? Or an external MySQL Hoster?

Thanks Robin. I created this now: https://github.com/processwire/processwire-issues/issues/1536

I read through the thread you posted and tried out a couple more things. I tried 3 different browsers (Chromium, FF, Safari), cleaned browser & completely removed all PW caches – all browsers are showing the same error. The site is a multilanguage (DE, EN, FR) site with German as default. Locally I can simply trigger the error by adding a tag with an umlaut, and removing the tag removes the error. New insight: switching to English also helps, French no. ? On the live site the field editing works well with umlaut tags in German and English, but still not in French. ? I somehow suspect the server configuration might matter as well. Maybe JSON functions in MySQL or PHP? My local MySQL is 5.7.34 (5.7.36 on live), and PHP 7.3.29 (7.3.31 on live). In the MySQL changelog are mentioned some JSON fixes in 5.7.35 and 5.7.36, but right now it's too time consuming for me to test this properly.

In some places in PW a double click acts on a whole list. It might be useful if this behavior could be more consistent for all kind of lists, cancelling or marking for deletion.

You're right, I assumed he just sees the comments in Admin.

You might want to use https://browsersync.io/ with laragon to get instant reloads on changes in defined source folders. Since I have never used laragon, I can't help with configuration. But there should be plenty of info on the web.

Do you have the _uikit.php* in your templates folder? (Required to render ukComments($comments)) Do the comments appear in the page source? If so they might be just be hidden by CSS. *Edit: Which should be included in _init.php. include_once('./_uikit.php'); like in the site-regular theme in the ProcessWire Source download.

Just had a wierd experience with a local copy of a site, that all over sudden had problems with opening the field editor. The online copy still works normal. The problem seemed to be related to a JSON parsing problem, but I do not understand why it worked just normal some minutes earlier and still normal on the live site. The Error looked like this: The site runs on PW 3.0.183 and after reading Joss's thread I first tried updating to latest master, and also latest dev, but with no success. Since that error was thrown by InputfieldTextTags.js I looked at the tags that some fields had. Out of maybe 50 fields only 3 had tags, and one containing the letter "Œ". After removing the tags in the online version (where I could still edit the fields) and then reimporting the database, the error was gone. I suspect this is an encoding bug, because if I put the tag back in, the problem reappears. It seems to affect only certain server configurations, in my case my local MAMP setup. I tried several PHP versions 7.3.29, 7.4.21 and 8.0.8. seemingly without any difference. Should I post this as a possible bug on github? Any hints how to drill down to the real reason of this behaviour would be appreciated... Edit 2022-02-27: Seems like the tag input is missing a sanitizer or it's not properly configured. The interface of the "Manage Tags" dialogue (Fields Overview) says "Any combination of letters (a-z), numbers (0-9) and underscores (no spaces)." but I can still enter umlauts and other characters that can break the UI. Even capital letters might not be allowed!? The Tags input in the field settings, doesn't mention those limitations.

Thanks, very cool idea. The str_replace() isn't even necessary, if you use basename($ext = false). // Create $image->alt method wire()->addHookProperty('Pageimage::alt', function(HookEvent $event) { /* @var $image Pageimage */ $image = $event->object; $event->return = $image->description ?: $image->basename($ext = false); }); https://processwire.com/api/ref/pagefile/basename/

Hi, I'm trying to figure out if there is better a way to get a file basename without extension in Twig. In PHP I can use: $page->image->basename($ext = false) The only way I got it working in Twig seems a bit ugly: {{ page.image.basename | replace({("." ~ page.image.ext):""}) }}

Is there any way of keeping HTML comments in content rendered via Markup Regions? Per default all comments seem to get filtered out (Why this?). There is a forum thread touching this topic but it doesn't answer how to get the comments back. I found in 'wire/core/WireMarkupRegions.php' there seems to be an option "exact" with is explained as: but I'm not sure if that's what I need. At least changing the default value in wire, doesn't seem to make any difference. I also found that comments starting with a hash symbol will be kept intact, like <!--#Test --> but those are actually intended as Markup Region Hints so it might affect performance to use them as regular comments!?

I have the same problem, trying to get a site working with an optional SSL Proxy. The site should work with and without the proxy. I think the problem is that all paths in PW are relative, so they think the SSL Proxy is the root, and all paths miss out the actual domain then. I was experimenting with prepending all URLs in my templates with something like `/my-domain.com` in case a HTTP_X_FORWARDED_HOST is set (that's the proxy). This works well with all public parts of the site (= my templates), but not for the admin parts, which are actually the only reason the proxy would make sense. I'm looking for a way to 'repair' the admin paths like i did with my other paths for pages and assets, but have no clue how to manipulate them. Any hints welcome! Thanks, AA

*** post removed by author, problem was already solved above ***