kongondo

moderator note: we already have a thread discussing the topic in the thread you started. I have merged your thread here.

I tested your code and it works fine for me; no errors. "Utente loggato" :-). I tested with both my supersuser role and one other non-superuser role. For the non-supersuser, I tested with their language as the default (i.e. in the backend) and also with their language as German (in the backend). I tested with both namespaced and non-namespaced variants of your code as well as with and without sanitising the password. I am wondering whether the issue is caused by the user roles? Have you tried to debug $checkUser? Is everything there OK? Another side note. I don't know your use case but just wondering why you are explicitly stating (error messages) whether it is the email or the password that is invalid for failed logins :-).

How old is the site in terms of ProcessWire version?

Glad you got it sorted. If you don't mind, please edit your first post in order to edit the thread's title to prefix it with [SOLVED] or similar. Thanks.

Just had a quick look. Lines #235-240 in PagesLoaderCache.php have this: if($this->wire('languages')) { $language = $this->wire('user')->language; if(!$language->isDefault()) { $selector .= ", _lang=$language->id"; // for caching purposes only, not recognized by PageFinder } } Line #237 is where the isDefault() method is called. The error you are getting indicates that in line #236, $language returned null. null cannot have the method isDefault(), hence the error. The reason, it would seem, we are getting null is that language is not being set for the current user (or theoretically, that there is no current user? - but don't think so). Maybe try to set a language for the user via the API before you log them in. https://processwire.com/api/ref/languages/set-language/ On a side note, why are you sanitizing passwords? :-).

Maybe I have been staring at my empty coffee mug for too long but I don't get the logic behind this :-). Could you please explain your use case some more? My thinking is that you delete things you no longer need and are sure you won't need. None of these seems to apply to your images. If you need them as some external resource, then why delete them in the first place? Secondly, depending on the number of pages and/or images involved and the frequency of the 'change image operations', you might be creating more headache for yourself in the future. You might end up with lots of orphaned image files in the sense that they are no longer being tracked by ProcessWire. You would have to dig into the file system to do maintenance. You would have to come up with a system for which images are still in use in ProcessWire and which have been decoupled but still in use as external resources. And what about images that may no longer be in use as an external resource? This sounds like a nightmare scenario to me. So whilst you could probably copy the images before they are deleted, I don't think that's the first approach to consider. Maybe if you could give us a better description of the situation including whether those external sites are ProcessWire sites. Please also explain why you want to delete the images in the first place. Hopefully we can then suggest other solutions and/or approaches, even about the external linking part :-).

This seems to have been an issue with sites installed in sub-folders. I'll fix this in next update. Thanks.

How would you React if I said I love Vue? ?

Just FYI, PHP has a NumberFormatter class. https://www.php.net/manual/en/class.numberformatter.php

True. It should be the work of the Fieldtype to make sure it is saving correctly formatted values to the DB. So, I would file a bug report

My guess. English decimal versus German comma ? Meaning, it is what I mentioned earlier. A data mismatch...

Strange indeed. I'll try and replicate. I have Maria DB 10.4.10 in local setup (windows).

Not a solution, but just some thoughts (which you are probably aware of...) That error can occur if either the data you are trying to insert is too big for the column or due to data mismatch. I doubt whether the former is the issue here. The column ratio is of type Decimal (4,2). The fact that this works on your local setup but not on your remote site does not tell us much because the are dissimilar (i.e. MySQL versus maria DB). Have you checked your remote site to make sure the Image field DB schema updated correctly? E.g., is the ratio field of type Decimal? What's your MySQL version? I seem to recall a change in decimal types between some MySQL versions. Could also be an issue with strict mode. In addition, it is not clear whether you are stating that the problem only occurs for non-superusers on your remote site. Is this the case? Does it work for superusers? Edit: see strict mode edit above

I see what's going on now. Did you inherit the site maybe? Or another developer was working on it? in your _func.php, there is a function called menuBuilder(). It seems that is what is/was being used in the site instead of renderNav(). So I guess it's a question of how you want to proceed. If you want to use the menuBuilder() function, you can do that and remove references to renderNav(). If you want to use renderNav() instead, you can find the full function here: https://github.com/processwire/processwire/blob/master/site-default/templates/_func.php. In that case you will have to edit your _init.php as well since menuBuilder() is included there as well as some other custom code. Edit You could also use both functions depending on your needs.

The error shows you are missing the function renderNav(). It looks like you are using one of ProcessWire's site profiles it ships with. The renderNav() function is in the file /site/templates/_func.php. I am assuming that file is in your install otherwise PHP would have thrown an error about the missing file in the file /site/templates/_init.php. That is where the _func.php is included. Do you have _init.php? If yes, in your template settings for basic-page, did you maybe change the setting for Prepend File? This is found in /setup/template/edit?id=xxxx , on the tab Files. Did you maybe tick Disable automatic prepend of file: _init.php?

Edit the page 'admin' and give it a new 'name' (in the page's Settings tab). Note that immediately you save you will get a 404 since the URL will still point to /processwire/. Just change that to the new name you gave admin and you are good to go.

That's only part of the problem though. The main(?) issue is echo'ed scripts and styles are not getting output on the page.

It doesn't seem to be a files' permission issue. For instance, when the following files are accessed directly, they show up: classie.js, bootstrap.js, jquery-1.10.2.js,custom-root, vegas.min.js, bootstrap.css and vegas.min.css. I suspect there's an issue with the template file itself or the page we are seeing (the home page) is actually reading/using a different template file from the one you think it should use. For instance, in your code above, there is no markup for po-home.js yet it is getting loaded when we view your site (unless you just left it out in your first post). Are you able to copy and paste your entire .php (template) file here? (the one with all the markup in your first post). Confirm if the home page is supposed to use that template file. Your ProcessWire version.

Hi @kunago, No. At least not directly. Please see the first post in this thread for the full announcement. I will look into creating a migration script though, but I cannot promise this. This depends on the urgency of your need. Please note though that current Padloper users will get the new Padloper (Padloper 2) at a discounted price (within a limited time period). This discount is yet to be determined though. Hope this helps.

Hi @nurkka, Thanks for the report and the suggested fix. I'll look into this.

Hello, This is primarily directed to MAC users and/or MAMP users. Recently, some Media Manager users have reported that their settings are not getting saved, especially the After Uploading setting. I have to replicate the issue on clean installs with nothing but MM, JqueryFileUpload and Tracy without success. Here's what we know so far: The settings actually get saved in the Database; the issue is what is saved is not what gets displayed in the GUI. Meaning, it always shows the default setting. For one user, the issue only appeared when they were using WAMP or XAMP. For the other user the issue appeared on both MAC and Windows. I don't have a MAC to test on. I have tested on both single language and multilingual sites. I can't replicate the issue. PHP, MySQL versions don't seem to be the issue. We've been testing on PHP 7.2+. I have tested on both the latest master and dev versions of PW. Those experiencing the issue see the same behaviour in Chrome, FF and Edge. I am not sure about Safari. We don't think there's a browser extension interfering. Media Manager version 012 (latest). Is there anyone with MM version 012, a bit of time and preferably a MAC and MAMP who can help us figure this out please? Any other ideas? Many thanks.

Ye. Looks like Sky News watched that before coming up with a similar analysis...or maybe just a coincidence.

Hi all, hi @Chris B, Sorry you haven't received your purchase link yet. Please note though that this thread is not intended for Padloper support (old or new or upcoming versions). Until specified otherwise, please direct all such inquiries to Antti via PM or via the email in the invoice. If you still haven't heard from him after a reasonable amount of time, then PM me instead. Thanks.

Hi @ottogal, Thanks for catching this. I have a feeling there are other similar gotchas! I'll search for and resolve (if need be) these at a later date. For now, please change line #1685 from: $authorPhoto = !empty($author->blog_images) ? to: $authorPhoto = $author->blog_images->count ? Thanks.

Hi all, Apologies for the very loud silence! I hope to elaborate more on this a bit later. However, rather than keep people guessing, I'll write something short. I have been working my fingers to the bone to release a beta by spring 2020. I suppose it hasn't gone unnoticed that I rarely post in the forums at large these days. This is because I am dedicating nearly all my time to Padloper. The plan was to start early beta testing in mid-April 2020. This was largely on track. Like many of us, maybe most of us in the forums, we have all been affected in one way or another by the current situation in the world. This has thrown a monkey wrench in the works. I have had to readjust how I work, albeit my productivity taking a hit. I wish I could properly 'guesstimate' how much delay this is going to cause but it will just be futile. On the other hand, I appreciate that you have been waiting for a relatively long time for this release. I want to reassure you that I am not just kicking the can down the road. Maybe I should have been showing you more screenshots of progress but currently, that would just eat further into my limited time. Thanks for reading, and hopefully, your patience. Cheers.