JayGee

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. ? 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. Agree this isn't clear - I've always thought the hooks were optional. 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!!! ? I'll update and close the issue I raised accordingly.

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?

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?

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 ?

@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?

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!

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 ?

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.

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.

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!

Hi @Gadgetto - just wondering if you have or are thinking of doing any more work on the V3 support for your module?

We also use the Keyword field more as a reminder of keywords we're targeting a particular page at - especially as most search engines ignore this data anyway.

I haven't had a chance to dig into it yet but according to a recent weekly PW newsletter it's a new module @bernhard is working on: https://github.com/baumrock/RockSeo

Awesome thanks for confirming ?.