JayGee

4 hours ago, Jim Bailie said:

@Guy Incognito Your above explanation on url segments is very interesting. Can you expand any further on how you set this up?

I've read through https://processwire.com/docs/front-end/how-to-use-url-segments/ , but I'm still not fully absorbing what I think is your approach. I'm sure the parent could benefit from this approach as well.

@Martinushas summed it up pretty well. This is basically the same approach I use. So you build your navs/links up using your category (or sub page names) rather than a 'traditional' link to a sub-page url and append them to the parent page URL.

<a href="<?=$page->url.{CAT-NAME-GOES-HERE};?>">Example Category</a>

Then you can get retrieve the url segment from the page URL and use it in your selectors for filling out the dynamic content.

@msavard You add custom styles by editing the CK Editor JS file which (from memory) is located at something like /site/modules/InputfieldCKEditor/mystyles.js.

But you may wish to first check out this thread as there is a new RTE incoming for ProcessWire ?

@Martinusif I understand what you're trying to do correctly, I think url segments are the best approach.

I frequently use ProcessWire for organising and displaying categorised data and usually approach this sort of thing with url segments rather than working with the actual pages (if that makes sense).

So put all your items under a /items page rather than in a set structure. You can then you can create category pages as views of different sub pages by using the url segments in your selector.

The advantage is that you can have your items in multiple categories without any duplication of pages, you only have to maintain one parent 'category' template and from an SEO perspective the url segments appear the same as regular URLs. (You may need to manually inject them into your sitemaps though).

4 minutes ago, Robin S said:

@Guy Incognito, could you please reopen the GitHub issue because I think there is a bug that needs attention? I've added a comment to the issue.

Done.

Thanks @szabesz that adds good context as to why it works like it does and it makes perfect sense.

Hi @Robin S thanks for your help on this. I have a few personal modules I want to update and then later submit on a couple of public modules we've adapted in-house, so wanted to be sure I got my head round what is going on with how upgrades are meant to work, so everybody's assistance and time here is much appreciated. ? 

10 hours ago, Robin S said:

as a general debugging tip.... you don't want any non-essential code executing. In your example you have:

Yes I typically would carry out a more in-depth debugging but in this case, as it seems you have confirmed, I suspected that I may have been misusing the method rather than other bugs being at-play so was trying to keep things simple to start with. But definitely agree with your advised approach.

10 hours ago, Robin S said:

1. The method name must be ___upgrade() and not upgrade(). The docs for Module make it sound like it is optional whether the method is made hookable with the underscore prefix but that seems to be incorrect because I can't see the method firing if the underscores are missing. So either that's a bug or the docs need to be updated.

Agree this isn't clear - I've always thought the hooks were optional.

10 hours ago, Robin S said:

If your module has autoload set to true then it will be loaded immediately after the refresh (and on every other page load). But if it's not autoload and you want to see the ___upgrade() method called then you can force the module to load like this:

Ok this is interested as the module I was experimenting with is definitely set to autoload and this hasn't been my experience... so there's likely something else going on I need to troubleshoot. But now at least I know where not to be looking!!! ?

10 hours ago, Robin S said:

This isn't a bug as whatever actions you are taking in ___upgrade() will get applied in time for the next usage.

I'll update and close the issue I raised accordingly.

8 hours ago, Guy Incognito said:

Hi @BitPoet - I'm pretty sure I did try both with and without defining it as hookable, but will do another test to double check and report back.

I've checked now. Making it hookable doesn't seem to make any difference. The method just doesn't get called and the test message is never displayed.

I'm not misunderstanding the functionality am I? The method should be called whenever the version number bumps right?

53 minutes ago, BitPoet said:

It should work if you define the upgrade method as hookable (___upgrade).

Hi @BitPoet - I'm pretty sure I did try both with and without defining it as hookable, but will do another test to double check and report back.

Yes, I've been using the module refresh to trigger the change but it doesn't seem to fire and it does register the change in version number and displays the default upgrade message. But no custom functionality within the upgrade method seems to get called.

I've raised an issue now on GitHub just now actually: https://github.com/processwire/processwire-issues/issues/1634

As an aside - I've tried setting the version both up and down... I presume as the version numbers are strings not numbers any version change should trigger the upgrade method?

1 hour ago, prestoav said:

Hi @Guy Incognito, thanks for replying. In the short term it looks like the current client might be moving away from Zoho so we've paused further development for now. However, I know some of our other clients still use Zoho so I may be back in touch at some point if that's ok!

Yes of course, feel free to DM me - always great to network with other UK based ProcessWire fans too ?

Hi @prestoav. We've done a fair bit of work around the Zoho API for a client who uses Zoho products extensively. We've not (yet) turned this into a module, but have some work coming up for this client that may make this an options. But feel free to pick my brains if it helps. From memory their API can be a bit unconventional as I think it's centred around 'views' inside the Zoho UI.

Not sure I fully follow the issue - but wouldn't it be easier to just use an email MSP like Mailgun to route all your emails. You can send 10's of thousands of emails at low cost this way and not have to worry about hitting limits?

Plus the WireMailgun module works a treat ?  

On 9/9/2022 at 12:00 PM, Liam88 said:

So I am using website.com/profile/user-id/ as the user profile page.

@Liam88 I've only skim-read your thread and I think @flydev probably has you covered, but one other thing to look out for is if you are using URL segments/pages etc that use the same terminology as used in the Login Register module.

I had an issue along these lines a while back where I was using the word 'profile' in a directory site and it conflicted with the login module's own profile setup. Ryan was going to patch it I believe so it may no longer be an issue. But thought I would mention it in case.

I've accidentally let my Login Pro subscription lapse so I can't see the details of our conversation at the moment but I know it had us puzzled for a while until Ryan spotted what was going on!

I'm not sure if this is potentially a core bug or an error/misunderstanding on my part. I'm working on a module where I'm pretty sure the upgrade method never gets called. I've tested with a simple message output and changing the version numbers up and down but I can never get any output from it. I've tried with and without using the ___hookable prefix on both my own method and the ones I'm calling.

public function upgrade($fromVersion,$toVersion) {
        $this->___install();
        $this->wire()->message('Upgrade method called');
}

I note here just today somebody else is flagging the same issue.

Does anybody have any insight into this or what I might be doing wrong?

2 hours ago, tcnet said:

It seems that the upgrade function don't get called after an upgrade. This might be a bug in ProcessWire.....

This is really weird - I was just about to start typing a message into the forum about this. I'm working on a module where I cannot get the upgrade method to fire. I'll post separately rather than hijack this thread but glad to see it's not just me with this problem!

3 minutes ago, flydev ?? said:

To try it, you can just create a dummy page with page's name `hello` and paste the whole code in `ready.php` ?

First I need...

You're an hour ahead of me in France ?

Thanks @flydev ?? this is awesome. I've not even had a chance to try it out yet but I can see I had previously been doing something wrong...

/// change the button's label (attribute: value)
  $submit->attr("value", "Foobar");

Had been trying to target 'label' rather than button value... duh! Probably led me down a blind alley from the get go!

Thank @wbmnfktr. I did see that thread from Ryan, but it didn't seem to cover modifying the default button, more about adding a new one.

However on second thoughts I'm going to use the drop down actions anyway as may need more than one option, but it would be good to know about editing the default label if anyone has any insight on this for future reference.

I'm trying to do something I thought would be simple, but maybe not!...

I'm trying to hook ProcessPageEdit to change the label/text displayed on the page save button in certain circumstances based on fields in that page. But can't figure if it's possible to target the button.

I can get to the button actions in the drop down with ProcessPageEdit::getSubmitActions but this array doesn't contain the top level label only the drop down values.

Can anyone point me in the right direction here please?

TIA ?

On 3/8/2022 at 7:46 PM, fruid said:

I'm trying to add hook before the page is saved. Then it should check if the SEO fields are empty and if so, use page's field's values that make sense.

let me illustrate:

$wire->addHookBefore('Pages::saveReady', function($event) {

    $page = $event->arguments[0];

	if (!$page->id) return;
    if ($page->isChanged('seo')) return; 

    if ($page->seo->title == '') {
        if ($page->template == 'speaker') {
            $page->seo->title = $page->academicrank.' '.$page->givenname.' '.$page->lastname;
            $page->message(':D'); // just to make sure the conditions are set right :D
        } else {
            $page->seo->title = $page->title;
        }    
    }

    $event->arguments(0, $page);
        
});

Something like this. I do get the message : D, so the issue is not there. However, the seo title field stays empty. Any ideas why this is not working?

Late response I know, the recent message triggered the notification for this thread!...

But I don't think you need a hook for this. The new version of this MarkupSEO allows you to set up automatic field inheritance for empty fields. E.g. so meta title is auto populated by page title.

Thanks @BrendonKoz this is useful to know/have.

The reason I create the little module above is because we were told that Google's own widget version was going to be completely removed and that the deadline for this was only extended due to Covid. We had a few sites reliant on it, so wanted a fall back.

It will be interesting to see whether the original widget stops working on not.

I created a simple translation module for a project we're currently working on and I thought I would share it in case it's useful for anyone else as it's a request we've come across a few times recently. It's a basic page translation module using Google Translate to replace their now retired embeddable page translation widget.

The module outputs a simple, un-styled, dropdown language selector that routes the visitor to a translated version of the current page via translate.google.com. From there you can then navigate the whole site in the your language of choice. There's also a method to output a single language-specific translation URL for any supported language using the language ISO code.

Download, usage and supported language list available on my Github here: https://github.com/mrjcgoodwin/MarkupGoogleTranslate

Caveat 1: Google seem to be trying to encourage use of their Google Translation API, so the continued working of this module is completely at their mercy - I can imagine they may discourage this usage at some point, but who knows!

Caveat 2: I haven't yet deciphered what all the parameters are used for in the constructed Google Translate URL. It's possible there may be some sites/scenarios where the URL doesn't work. Feel free to report if you find any issues.

4 hours ago, bernhard said:

You are not dreaming - this is already possible using RockMigrations:

<?php
$rm->migrate([
    'fields' => [
        'myfield1' => [
            'type' => 'text',
            'label' => 'My field one',
        ],
        'myfield2' => [
            'type' => 'text',
            'label' => 'My field two',
        ],
    ],
    'templates' => [
        'mytemplate' => [
            'fields' => [
                'myfield1',
                'myfield2',
            ],
        ],
    ],
]);

If you don't like PHP arrays for whatever reason simply use json_decode( _your_fields_and_templates_as_json_string_ ) instead...

I'll release a new version soon that makes it a lot easier to get started with RockMigrations though the API will 99% be the same as in the old module.

Ah brilliant thanks - think this is what I was thinking of ?.

Nothing against php arrays either, in my mind I was thinking of JSON for some reason.

Although I’m considering a workflow that has gulp in it anyway, so json may be involved at some point. 

16 minutes ago, kongondo said:

Not sure if this is the one...it is about translations..

 

Thanks - but I don’t think that’s the one. I think it was in one of the newsletters discussing dev branch updates. It was more along the lines of creating new templates using a text or json file to define the fields.

Had some ideas around experimenting with this in our workflow… but now seriously beginning to wonder if I dreamed it ???

I think I saw post on here or an article in the newsletter about a forthcoming feature for defining/importing templates using a JSON file… or did I completely imagine this?! ?

If it’s real I can’t find the info anywhere!