MSP01

2 minutes ago, Tiberium said:

 

Funny how it is completely the opposite for me. I thought the more "bulky" design of the native repeaters was too much. More like: "You can't see the forest for the trees" (German: "Vor lauter Bäume den Wald nicht sehen"). The reason why I prefer more the way of Berhards RockPageBuilder. Where the content elements not jumping in your face.

Just to pipe in because the new look of the repeaters bothered me as well. I like both yours and @AndZyk suggestion better than what the new theme provides. There's something in it that makes the fields hard to look at for me.

23 hours ago, Nicolas said:

@MSP01 As stated by Ryan the original UIKit will still be available (though not as default). Regarding the color palette setting one that is pleasing to your eyes is as easy as tweaking some CSS variables in the admin.css file.

 

Thanks for pointing that out. I had read all the previous comments when this post was made, but had either forgotten or missed that the old theme will still be around!

I'd like to offer something more constructive about the new theme and how to improve it, but it's not easy to do. Differences are subtle and yet many at the same time, yet I cannot shake my initial negative experience, especially since it hasn't really changed after a week. If I have time and chance I'll try to offer some suggestions, though as someone mentioned, design by commitee is indeed not the way to go.

After using it for a week, I must say I'm not happy about the end result of this update.

Processwires backend has never been especially sleek or modern looking. But it is usable and clear for the most part. Ryan said he's not been a designer in a long time, and while that maybe true his version of the UIKIT admin is far better than what this update provides.

This new look basically just makes everything look more gray and drab and at least to my eyes, even more old fashioned. I'm not seeing any new functionality anywhere either, which to me would have been a far bigger upgrade than having a new skin, that seemingly isn't even optional but will be forced on everyone!

I think overall it's a step down and at best it's a sidegrade. I really hope the current admin version stays on as a version you can choose to use!

This might be a band aid but:

If you don't have a huge amount of pages to sort, one possibility is to create a separate page with page reference field, add the pages there and base the sorting on the ordering of this field. Admittedly this is a good solution in some cases and sometimes it's far too inconvinient to do it like this.

It's how I usually do web pages main navigation.

That's a neat little project!

Select list for fonts is bugging out a little bit (color and background-color are both white). 

@ryan Can you take a look at this? If I'm using the cache wrong it would be great to know. But if it's correct then there's definitely something funky going with the cache itself.

Hello,

I'm using WireCache with matrix repeater. Usually it works fine, but on occasion it seems to cache nothing instead of the actual content and serves a totally blank page, which then wont go away until someone manually clears it out.

I've also added a hook in ready.php that will clear out any related cache on page save. That seems to work fine, when cache is working correctly, but when it saves "empty" the hook does not function either, which I find pretty peculiar.

I'm just here to double check I'm using the cache correctly

Inside the matrix repeaters php file:

foreach ($value as $item) {

	if ($item->type !== 'matrixForm' && $cache->get('page_' . $page->id . '_item_' . $item->id, $cacheTime)) {
		echo $cache->get('page_' . $page->id . '_item_' . $item->id);
	} else {

		ob_start();

		// Matrix item HTML/PHP here

		$cacheValue = ob_get_clean();
	
		if($item->type !== "matrixForm") {
			$cache->save('page_' . $page->id . '_item_' . $item->id, $cacheValue, $cacheTime);
		}
	
		echo $cacheValue;
	
	}
}

There are few item types that are not supposed to get cached, 'matrixForm' being an example.

Well few hooks did the trick. Feels a little hacky but if it works, it works!

We have a need for enforcing the use of TFA TOTP on users. But neither Register Login Pro or Processwire in general seem to offer much help with this. 

Specifically TOTP needs to be turned on and then the QR code should be provided on first login attempt if TFA hasn't been added yet.

Has anyone done anything of the sort? 

I'm getting this error when trying to access the field, or any page that is using the field. 

"Expecting Hex color string (length 6 or 8 digits) with optional leading '#'"

I believe it's because I first selected hex output and later changed it to rgba.

The error is basically breaking every page where the field is used.

Some more information. Temporarily editing out line #84 in FieldtypeColor.module allowed me to fix the defaul value that was crashing the module. It seems that if default value has an alpha value it will cause a crash.

But now I'm running into an another issue. Allowing user to select alpha causes this error:

"InputfieldColor: Submitted value: rgb(0, 0, 0) does not match required pattern: /#?[a-fA-F\d]{6}/."

4 hours ago, bernhard said:

Sounds exactly like what the admin search does? ? 

You know what, I've never in my life tried the search. I'm not even sure what I thought it was for. It's a little slow, but still great improvement!

Sometimes when you have a lot of fields, finding one you want to edit can be bit cumbersome. I like to organize things with tags, but I've lately noticed that they really just slow you down and using the browsers search is probably the quickest way to find the right field, as long as you know what it's called. But if your tagged field groups are closed browsers search wont be able to find the field until you open the group...

So would it be possible to add one of these options?

A) Ajax search field that would show you a list of fields that match the search criteria

B) A simple checkbox or button that would open / collapse all the tagged field groups at once so you can use browsers search to find your field

Of course if someone has made an extension to do this, do let me know. ?

Seems to be back to normal now, about 8 seconds this time. About 3 seconds of that is two .js files and one .json that are giving 404 though.

I was a little shocked first time I opened the page, had a serious 14.4 Kb modem flashback. ?

Your pages homepage took more than 5 minutes to load.

Inspector shows that almost every image with took more than minute.

You might want to take a look at that pagespeed module, can't imagine it doing anything good.

Nice site. My only critique would be to remove the UIKIT transition from the thumbnails. It gets tiring very quickly and it's kinda gimmicky.

Interesting module for GDPR. Is there records of consent storage or Google consent mode somehow available?

Solution:
Just added one folder between root and the site and it started to work. Probably could have fixed through .htaccess as well, but what ever works.

--

I just did a local copy of a Processwire site and I run it on XAMP on windows.

Admin and rest of the site work just fine, but whenever I try to go on homepage, the browser downloads the index.php at the root of PW instead of running it as PHP.

Been trying to google about it, but after a day of poking around it I haven't been able to figure it out.

PW version is 3.0.210, PHP is 8.2.4 running on XAMP.

Would it be possible to get all the finnish translations to one place and have an up to date links here and in the language module list? Currently it seems to take quite a bit of detective work to find the translations.

Finnish language in the modules as an example has a link that leads to 404 page:
https://processwire.com/modules/finnish/

Finnish translations seem to be currently located here:

https://github.com/apeisa/Finnish-ProcessWire

Sending images using "$mail->AddEmbeddedImage" works well from frontend, but if I run the same code from backend the image will not appear in the email. First I thought content-type was the problem (for some reason it changes from multipart/alternative to text/html when sent from backend), but after I fixed it the problem persists.

In this case I send an email based on data on a page.

Email can be sent by filling a form on frontend, but also through backend by using checkbox and saving the page. Image in question is saved on another page.

I have a template file where I need to set $page->of(false) and then save a variable in a field.

This seems to break the frontend, specifically combo fields. Settings the $page->of(true) after saving doesn't seem to do anything either. How to does one fix something like this, or is $page->of(false) something that shouldn't be used inside a template file? I'm pretty sure I've done this a lot in the past without running into issues with it.

Edit:

Some additional information. The saving is done inside a function where the page is passed to. $page->of(false) and $page->save() seem to work fine, but $page->of(true) does nothing. 

I've solved this temporarily by putting $page->of(true) right after the function call, but it seems like bit of a hack.

Is the code in a template file and does that template use pw-regions?

I had a problem where a form was defined as variable at the top of a template file outside of the pw-regions, and then echoed inside a region later on on the same file. This caused it send mails twice each time someone used the form.

Now a questions, is it possible to hook language strings in the same manner?

I recently ran into the same problem. I tried to auto-activate the other languages in a saveReady hook, but it didn't work even though changing the hidden status inside the same hook works fine. Anyone got any advice on this?

@horst This could work, but I'd rather keep things very literal. A check box that says "don't show this page to certain people" is more clear than setting them hidden.

@Robin S I could of course do that, but I'd really rather not. There are a lot of these pages, and there's a lot going on under the hood. I'd have to change code all over the place and it's what I'm trying to avoid in the first place.

Sorry if it seems I'm trying to find the most difficult way to do a simple thing. If there's no easy fix via hook, I'll just do it manually in the code. ?

It's also possible there will be need to hide pages from more than one group while showing it to other groups in the future and Horst's suggestion wouldn't work in that case. Neither would the template. Or at least I wouldn't want to create a new template every single time something like that came up. It seems like a very heavy way of doing something that should be handled within a page itself.