simonsays

16 hours ago, LostKobrakai said:

You can look into the FieldMigration class to see what it does on migration/rollback. It should just remove the field itself. If that doesn‘t clean up the fieldgroup than it‘s expected behaviour. You can still override/add to that by putting your own upgrade/downgrade functions like e.g. I did it here: https://github.com/LostKobrakai/MigrationSnippets/blob/master/Reverse_Template_Migration_Type.php

It was just a quick question to confirm, whether repeater field downgrade works out of the box or requires additional extending.

Thanks for the reply.

@LostKobrakai

I have this code for repeater migration, however, I noticed something. Not sure if it is a bug or the way it should be.

<?php

class Migration_2018_11_18_00_00_00_RepeaterAccordionField extends FieldMigration {

    public static $description = "Add repeater for accordion";

    protected function getFieldName() {
        return 'repeater_accordion';
    }

    protected function getFieldType() {
        return 'FieldtypeRepeater';
    }

    protected function fieldSetup(Field $f) {

        $f->label = 'Repeater accordion';
        $f->collapsed = Inputfield::collapsedNever;

        $repeaterFieldGroup = new Fieldgroup();
        $repeaterFieldGroup->name = 'repeater_' . $this->getFieldName();

        //Add fields to fieldgroup - add others as necessary
        $repeaterFieldGroup->append($this->fields->get('title'));
        $repeaterFieldGroup->append($this->fields->get('content_columns'));

        $repeaterFieldGroup->save();

        $repeaterTemplate = new Template();
        $repeaterTemplate->name = 'repeater_' . $this->getFieldName();
        $repeaterTemplate->flags = 8;
        $repeaterTemplate->noChildren = 1;
        $repeaterTemplate->noParents = 1;
        $repeaterTemplate->noGlobal = 1;
        $repeaterTemplate->slashUrls = 1;
        $repeaterTemplate->fieldgroup = $repeaterFieldGroup;

        $repeaterTemplate->save();

        $repeaterPage = "for-field-{$f->id}";
        $f->parent_id = $this->pages->get("name=$repeaterPage")->id;
        $f->template_id = $repeaterTemplate->id;
        $f->repeaterReadyItems = 3;
        
        //Add fields to the repeater - add others as necessary
        $f->repeaterFields = $this->fields->get('title');
        $f->repeaterFields = $this->fields->get('content_columns');

        $f->save();
    }

}

If I rollback the migration, it deletes the field. But does not affect the fieldgroup.

So, when I try to run the migration for the second time - it throws me an integrity violation error (originates from fieldgroups table).

Is this the expected behaviour?

3 hours ago, horst said:

Have you tried to export as ZIP with a current pw version? 3.0.119 ?

Tried now, works! Thanks!

3 hours ago, horst said:

Have you tried to export as ZIP with a current pw version? 3.0.119 ?

No, I am using master (which is 3.0.98). Does it work there?

Hello,

Do you know, if there are any module alternatives or planned fixes for existing export and import functionality?

I do understand that it is still in development phase and for the most part it works well.

The only problem is that attached files (e.g. images) are not imported/exported together with pages.

On 10/22/2018 at 1:32 PM, adrian said:

@simonsays

Just back online tonight - will take a look tomorrow.

Hello ?

Bump. Any update on this? No feedback here, none on github ?

5 hours ago, flydev said:

Ok this is the issue. Your problem is a known bug in SOAP extension and  you should update the version running on your server to at least PHP 7.1.14  (known to me where the bug was fixed and its working).

So just to be clear, PHP 7.0 branch contain the bug. To fix it, update the server PHP version.

And FYI, a good habit is to develop with the same environment to avoid those head scratching moment ?

-

https://bugs.php.net/bug.php?id=70469

Submitted:	2015-09-10 13:50 UTC	Modified:	2017-11-22 22:14 UTC

https://github.com/php/php-src/pull/2899

 

I am still unsure why this fatal error was not displayed when using pure PHP (outside of module scope).

5 hours ago, flydev said:

Ok this is the issue. Your problem is a known bug in SOAP extension and  you should update the version running on your server to at least PHP 7.1.14  (known to me where the bug was fixed and its working).

So just to be clear, PHP 7.0 branch contain the bug. To fix it, update the server PHP version.

And FYI, a good habit is to develop with the same environment to avoid those head scratching moment ?

-

https://bugs.php.net/bug.php?id=70469

Submitted:	2015-09-10 13:50 UTC	Modified:	2017-11-22 22:14 UTC

https://github.com/php/php-src/pull/2899

 

@flydev

Thank you very much for your help! Solved the issue. Would have struggled if it had not been for your help.

25 minutes ago, flydev said:

Ok this is the issue. Your problem is a known bug in SOAP extension and  you should update the version running on your server to at least PHP 7.1.14  (known to me where the bug was fixed and its working).

So just to be clear, PHP 7.0 branch contain the bug. To fix it, update the server PHP version.

And FYI, a good habit is to develop with the same environment to avoid those head scratching moment ?

-

https://bugs.php.net/bug.php?id=70469

Submitted:	2015-09-10 13:50 UTC	Modified:	2017-11-22 22:14 UTC

https://github.com/php/php-src/pull/2899

 

Looks like this could be the thing. Thank you very much! Will get back shortly.

18 hours ago, flydev said:

Whats the PHP version on XAMP and server?

(Cant reproduce the error, working fine here)

That's the main issue, unable to reproduce it on my local computer ?

My local XAMPP is 7.2.8 and server runs on 7.0.27

However, I did not believe that the php version could be the issue.

3 hours ago, flydev said:

By default, SOAP trigger error with his custom php error handler. To catch exceptions, add array('exceptions'=> true) as an argument :

try {
    $client = new \SoapClient('faulty url goes here', array('exceptions'=> true));
}
catch (\SoapFault $e) {
    echo 'wrong';
}

 

Same result, both with and without

On 11/9/2018 at 5:38 PM, MoritzLost said:

What namespace is your module file in? If you're using the Processwire namespace (or your own namespace, for that matter), the catch block can't catch the SoapFault because it's looking in the wrong namespace.

If you module file uses the Processwire namespace, all type-hints (including those in catch-blocks) will be relative to that namespace. So your block catch (SoapFault $e) will only catch  \Processwire\SoapFault exceptions, instead of \SoapFault (the SoapFault class in the global namespace, as provided by the SOAP PHP extension). That would explain why it's working in your test file which doesn't have a namespace, but not in your module.

In this case, you can fix it by type-hinting the global object: catch (\SoapFault $e).

I tried both ways and there is no real difference.

I tried both

} catch (SoapFault $e) {
	print 111;exit;
    return $this->client = false;
}

} catch (\SoapFault $e) {
	print 111;exit;
    return $this->client = false;
}

It reaches the "111" part but even with exit; the error is still thrown

Also, forgot to mention, that the service works perfectly when SOAP service URL is correct and up. I just want to handle situations when it is not available for one reason or another.

Hello,

I am facing a mysterious issue.

I have a module for connecting to external SOAP service (which is initialized along with the project).

Since SOAP service times out every now and then, it is crucial to handle this timeout and hide error from the user.

I have this bit of code in the module

    public function init() {
        ini_set('default_socket_timeout', 5);
        $configData = $this->wire('modules')->getModuleConfigData($this);
        
        if (!isset($configData['url_wsdl']) || empty($configData['url_wsdl'])) {
            return false;
        }
        $url = $configData['url_wsdl'];
        
        try {
            $this->client = new SoapClient($url);
        } catch (SoapFault $e) {
            return $this->client = false;
        }
        $this->session_id = $this->wire('input')->cookie('SSID');
    }

It works well in my local XAMPP environment and does not show any error or exception when connection fails.

However, on the server I keep getting ugly error displays at the bottom of the page (red when loggen in and generic "internal" when I am logged out from admin).

At first I thought, that this had something to do with php error settings on the server, but afterwards I tried this bit code to see if it works outside of PW and it did! No error was thrown despite forcing PHP errors.

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
ini_set('default_socket_timeout', 5);

try {
    $client = new SoapClient('faulty url goes here');
}
catch (SoapFault $e) {
    echo 'wrong';
}
var_dump($client);

So, I assumed that processwire has to do something with that.

What exactly is the issue and how can I disable displaying these errors? try ... catch block is not enough and I already tried force setting $config->debug to 'false'

Logged issue on github https://github.com/processwire/processwire-issues/issues/736

@ryan

Found a bug which involves a certain scenario.

My version is 3.0.98, therefore I am not sure if it has been fixed in later versions or should I raise an issue.

Steps to reproduce:

1. Do a clean install of Processwire 3.0.98.

2. Install PageFrontEdit module.

3. Add repeater field and add an image field inside of it. Assign it to any template (I picked "home")

4. Create a page and add a button to open an edit modal dialog

echo '<edit field="' . $page->fields->implode(',', 'name') . '" page="' . $page->id . '">';
echo '<a>edit</a>';
echo '</edit>';

5. Open modal dialog on the front-end and upload an image to repeater. Save changes.

6. Open the dialog again and crop the image. Click "Apply" and "Save and replace".

Expected behaviour:

The form and the image field are updated with the new cropped image preview.

Actual behaviour:

Nothing is updated and old image preview stays. Through web developer tools and "network" tab I got a json error

{"error":true,"message":"Field 'headline' is not applicable to this page"}

The bug does not happen when editing the same page in admin as well as for "image" fields which are not inside a repeater.

Has this been raised or fixed already? Or is this something you are unaware of?

On 10/12/2018 at 11:51 PM, adrian said:

It should be easy enough to remove the first one when adding a new one by stripping off the ? and everything after it.

You can hook into Pageimage::crop

Thank you very much, I'll try (been on a holiday myself).

I'd rather use your module instead, though...

 @adrian

Hey man! Did you get a chance to reproduce the issue?

12 hours ago, adrian said:

Sorry for the delay in response to the CustomUploadNames issue - I am on semi-vacation, but I will try to take a look at that soon so maybe that will address your needs?

Take your time, man. You are not paid for this ?

I was just looking for a temporary solution while you fix your module.

Hello,

Moved this topic from "Modules". Put that there by mistake.

to avoid caching I am trying to end up with a hook to append page->modified timestamp to all image urls.

NB! I am aware of noCacheUrl method, but this one's no good as I want them to be out of cache on page update only.

NBB! I have tried CustomUploadNames module but it breaks the image path when cropping images inside the repeaters.

NBBB! Ideally it would be image->modified timestamp, which is unfortunately not updated on crop or focus.

I have come up with something like

wire()->addHookAfter('Pageimage::url', function($event) {
    $page = $event->object->get('page');
    $p = ($page instanceof RepeaterPage) ? $page->getForPage() : $page;
    $event->return = $event->return . '?nc=' . $p->modified;
});

This one has several issues though...

1) I end up with multiple appends, eg. ?nc=321223242?nc=4232424342323, etc

2) Page modified date is not updated when cropping an image (unless saving it afterwards, which is an overkill imho).

Can anyone think of a better solution for that?

On 9/28/2018 at 8:43 AM, adrian said:

Hi @PCuser - sorry you're having problems.

I just tested with an image with exactly that filename and it worked just fine.

I wonder if there is something else at play here. Any chance you could do a little debugging? Firstly try on a clean PW install and if that works, see if it's some other module that is conflicting. Or perhaps it's specific image field settings at play. Does it work with a newly created image field with default settings?

You get the idea ?

@adrian

I have come across a similar issue.

My filename pattern is {$page->name}-{$file->filesize}-[YmdHis]. Rename on save is checked.

The plan was to avoid caching, both on server side and on the client side, as our prod servers have several layers of cache.

I tested with image field inside a repeater and crop functionality.

Initially the image is uploaded fine and replacing image also works.

However, when I crop it and save the page, the image still gets the old path (which is now broken), both in admin and on the front-end.

I looked into both the DB and the filesystem. DB record (field value) is not updated and stays the same on crop. However, image filename is updated.

Once again - this happens on crop, inside a repeater field.

I tested without a repeater and indeed, it works fine.

On 9/24/2018 at 10:08 PM, adrian said:

I'm afraid I don't understand this - how are you setting them to false? Are you saving pages via the API, rather than the admin backend? 

@adrian

Yes, I am doing it via API, but I found a workaround.

Hello,

I am using two VPSs for a website and would like to have persistent admin login for both. E.g. when someone logs into admin on one server, he's automatically logged in on the second one. Both webservers are under the same domain (there is Varnish LoadBalancer on top, so it either fetches one version or another one).

Is it possible to sync sessions in processwire?

I have installed SessionHandlerDB module, but it does not seem to create any cookie (only session) on admin login.

Is there a good module for that? Or should I add a login hook instead?

15 minutes ago, pwired said:

Send me a beer if it works

This plugin is not so good as it sets embed properties globally (for our project they vary from page to page).

I managed to get ACF working by slighly modifying your input to

div(*)[*]{*}
iframe(*)[*]{*}

Guess, still own you a small one. This solves 2) with ACF.

Still confused about 1) (HTML purifier).