JayGee

Is there a method or a selector for including unpublished items when outputting from a repeater field?

On 6/2/2020 at 7:44 PM, matjazp said:

Yes, it's on the dev branch. I applied fixes on the current master version until the next master. So far so good.

Finally got onto trying this out and confirm fix works - thanks for your help ?

4 minutes ago, matjazp said:

https://github.com/processwire/processwire-issues/issues/1086

Ah thanks @matjazp - I'll try applying those fixes later as I presume they're currently only in the dev branch? I'm working on a master copy downloaded yesterday.

I seem to be running into a repeated fatal error in a fresh PW install version 3.0.148. I can't quite put my finger on the pattern but it seems to be around deleting image fields or removing images from certain image fields.

This is the trace from the log generated by trying to save a page and delete an image from an image field:

Fatal Error: Uncaught Error: Cannot access protected property Pageimage::$original in /wire/core/PageimageVariations.php:256 Stack trace:
1. /wire/core/Pageimage.php(1327): PageimageVariations->getInfo()
2. /wire/core/Wire.php(386): Pageimage->___isVariation()
3. /wire/core/WireHooks.php(823): Wire->_callMethod()
4. /wire/core/Wire.php(450): WireHooks->runHooks()
5. /wire/core/Pageimage.php(1369): Wire->__call()
6. /wire/core/Pageimage.php(399): Pageimage->getOriginal()
7. /wire/core/WireData.php(333): Pageimage->get()
8. /wire/core/PageimageVariations.php(256): Pro
Line 256 of /wire/core/PageimageVariations.php

Earlier in the day I was experimenting with custom fields for images for the first time and kept running into this error, thinking it was me using this feature wrong and not having time to read up I deleted the custom image fields template and went about my business. So now I don't know if I triggered an issue or whether it was never related to the custom image fields in the first place?

Any ideas?

11 hours ago, Ivan Gretsky said:

Wouldn't it also break complex fields frontend editing, which happens in popup iframes with admin pages loaded?

Interesting I hadn't considered that.

I was wondering - could I just change the admin template permissions in the access tab to exclude the roles I don't want to give backend access to? Any unforeseen consequences here? ?

1 minute ago, bernhard said:

Actually this would also prevent you from opening the login-screen. But you get the idea and can modify it to your needs (like checking for a user role or a page template or id etc.).

Yes sure I can make something work here thanks. Love these kind of simple approaches - I was way overthinking it!

1 minute ago, bernhard said:

I think it should be enough to put this in your /site/templates/admin.php

if(!$user->isSuperuser()) $session->redirect('/');

 

A beautifully simple approach thank you! ?

As per the title really, is it possible to set up front end editing permission on a template without granting a user access to the back end dashboard?

I know I can allow editing with the API but seems to be reinventing the wheel somewhat!

I have installed this module on a site that uses URL segments on the home page. I don't seem to be able to access /sitemap.xml - it just redirects back to the homepage, presumably the path is being treated as URL segment. Is this expected behaviour or do I have something set up incorrectly?

On 3/11/2020 at 4:36 PM, Pete said:

Right, this should be fixed now finally.

For those that are interested, there was an issue with the forum session wiping out the ProcessWire session by the end of the script - a little puzzling because right up to the end of the script everything seems fine but when you redirect the session information is lost. To overcome that there's some background CURL stuff going on now so the two systems are separated completely during the login process.

Please feel free to post/update your profiles again and sorry it took so long.

Thank you - I can confirm I managed to log in too now, but had to go Incognito to get it to come back to life otherwise it just looped back to the login screen with no messaging. Presumably something to with session info related to my account as above.

Thank you. I did try most of the different ways of including files. The problem wasn’t with the include itself which was working fine.

The include itself was running some PW selectors and dynamically populating some variables critical to the rest of the page content. Seems that with a standard include things weren’t loading in the order I needed for this to work, but using an appended init file works fine ?

After some sleep I answered this myself by prepending an _init.php file in my config with the include in ?

I'm experimenting with markup regions for the first time instead of static output. Everything's going great other than I can't work out how to include other PHP files in my _main.php file that use PW functionality. Primarily I have a script that runs some checks against user permissions and runs a few PW selector queries to set up a few useful variables for a basic web app.

If I include this file into my _main.php the variables don't populate as it doesn't have access to things like the PW $pages object - presumably something to do with the load order?

What's the correct way to go about this, a new module seems overkill. Is it just a case of including the file at the top of every template, or is there a smarter way?

On 2/27/2020 at 11:11 AM, Robin S said:

I think you edited your original post and topic title, right? My answer was for the original question and isn't relevant now that you've changed it. Better to mark a topic as solved and start a new topic in such situations I think.

Oh sorry you got me!! I was originally going to post two threads for the slightly different (but related) issues. But shortly after posting I fixed one of them and as nobody had seen or responded to it yet (or so I thought) I edited it into one post... but you must have responded at the same time. Apologies ? 

@joshua this looks like a really useful module thank you ?. Will definitely be giving this a try on our next project.

Thanks @Robin S - although, not sure if I'm being thick here ?, but will that change anything on the specific problem of the final image's description not being updated? The rest of my loop seems to work fine, but for some reason it doesn't apply the description to the final image/iteration. Really odd.

This short script loops through some images from an XML feed and pushes new ones to an image field. It all works perfectly, except for some reason the last image (only) in the loop each time doesn't receive the image description... can everyone spot why? TIA! ? 

foreach ($propertyImages as $img) {

            $fileName = trim($img[0]);

            if ( !empty($fileName) ) {
                
                $imgPath = '../property_data/'.$fileName;
    
                if(file_exists($imgPath) && !in_array(strtolower($fileName),$currentImages)) {
                    $p->property_images->add($imgPath);
                    $p->save();
                    $newImg = $p->property_images->last();
                    $newImg->description = $img[1];
                    $p->save();
                }

            }            
            
        }

Ok got it - this works!

$ogImg = $page->single_image->first()->httpUrl;

So as you said @gebeer it's something to do with the images being stored in an array, but no idea why looping through them manually wasn't working!

4 minutes ago, gebeer said:

Have you tried httpUrl without the () ? In API docs it states that httpUrl is a property, not a function https://processwire.com/api/ref/pageimage/

 

Yes have tried both as a method and property.

42 minutes ago, gebeer said:

I think, the problem is with $page->single_image being of type Pageimages, not Pageimage.

Inside hooks the $page object's output formatting is turned off. This means that even for image fields that are defined to hold only 1 image, the field is of type Pageimages, which is an array.

You can confirm this by doing var_dump($page->single_image) (or better using Tracydebugger bd($page->single_image)).

So to get to the actual image, you need to loop over the Pageimages array like

foreach($page->single_image as $image) {
	// your logic goes in here
}

 

I'm not getting the memory error now, I've changed the page save to target the specific field and this seems to hugely improve performance.

Pageimages being an array makes sense, but looping through the image field isn't working either. In actual fact when I start logging the output on save as I go it just seems httpUrl() isn't returning anything whereas url() does.

32 minutes ago, wbmnfktr said:

Why in a hook and why saving the image to another field and so on?

Why not just checking it in the template and outputting different values for OG/SEO?

It's because the site is running markupSEO module to handle OG and meta on all other pages. Only on this specific page type I just want to auto populate the OG image field so they can go on using the rest of the module functionality elsewhere.

I've written a very basic hook script with the aim of updating one field with the value from another on page save. I want to get the full absolute URL of an image to populate an OpenGraph image tag field.

If I change the url() call on single_image to httpUrl() I get a server memory exhausted error. I'm certainly not a PHP wizard but I don't think this should be particularly taxing. Have I accidentally created a loop somewhere? Calling url() works fine.

Running ProcessWire 3.0.141.

<?php

//Hook page save to update Open Graph Image URL with featured image
$wire->addHookAfter("Pages::saved(template=article)", function ($event) {

    //Get which page has been saved
    $page = $event->arguments(0);

        //Check featured image is set
        if ($page->single_image) {
            
            $ogImg = $page->single_image->url;
            updatePage($page,$ogImg);

        } else {

            $ogImg = 'https://examplesite.co.uk/site/templates/images/default-og-img.jpg';
            updatePage($page,$ogImg);

        }

        //$message = "Open Graph image successfully generated";
        //$this->message($message);
        
});

function updatePage($page,$ogImg) {

    $page->seo_image = $ogImg;
    $page->save();

}

2 hours ago, horst said:

Which pw version are you running?

This site is 3.0.123.

17 hours ago, matjazp said:

I could be completely off but maybe setting the path is not working correctly: https://github.com/processwire/processwire/pull/156 (related to https://processwire.com/blog/posts/pw-3.0.141/#processwire-system-urls-paths-now-more-customizable)

Interesting - I did try to call setLocation() from ready and init and both threw an error even though the blog post indicates they’re callable from there.

42 minutes ago, dragan said:

Can't you just use httpUrl instead of url?

That was my first thought too but it seemed to produce different output when bootstrapped vs loading as ‘native’ ProcessWire.

Although I’ve now solved it, my hunch is still the rewritebase option in htaccess wasn’t working as intended. It could be because of the NGINX Apache proxy setup.

For the record since I left the office for the day it dawned on me that the link @wbmnfktr posted above to Ryan’s updates on the customisable paths probably will work - but I think it may currently require the dev branch whereas this site is running master. 

Ah ha moment - I think I got it!

Setting the root url in the template seems to have solved the issue. Although I think as per your post @wbmnfktr there's possibly a less destructive/repetitive way to this in future if can get my head round it!

<?php $config->urls->root = '/pw/';?>