JayGee

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

Thanks ?. I will check out RockSEO. The thing that has kept us on MarkupSEO to date is the simplicity for implementation and also for clients. Combined with the changes you’ve made previously it’s pretty effective at doing what it needs to. I’ll have a think if there’s anything else that can be done to improve it further.

Hi all, Not sure if if everyone has jumped to SeoMaestro these days but I'm still fond of MarkupSeo and it's still live in many of our sites so I've made a few small but important tweaks based on real world usage. @adrian I've just made a pull request with these changes to your fixes branch in case others find these changes useful: Stopped canonical links from being able to inherit from parent pages: Inherited canonical links could cause problems with search engine indexing whereby you're inadvertently telling Google your new page is the same as another purely because you (or a client) missed the canonical field. So I think it is better for the default to be current page URL if the field is left blank rather than inherit the parent. Implemented handling of relative URLs in the canonical field: You can now use relative URLs in the canonical field for internal links. They will still render on the front end as SEO-friendly absolute URLs, but this way it is easier if you use different domains for testing or if you need to change the site domain. (https://github.com/mrjcgoodwin/MarkupSEO/tree/various-fixes-enhancements)

@Krlos I agree with @bernhard - more detail is required on your constraints to really advise. However we've built a number of data-driven sites using PW in this way and I would say putting all pages of a specific type under one parent is my preferred approach vs nesting in multiple sub-folders. It's also more like a regular database table). You can then just use selectors to filter the output and it makes more sense if you have entities that might apply to multiple parents. E.g. a staff member that works at multiple locations. For those maintaining the site/data you can make it easy on them by configuring the 'family' tab for each template. So for instance, only a 'hotel' can be added as a child of 'hotels'. When an editor wants to add a new hotel they can't then accidentally use the wrong template, or put it in the wrong place. Finding an existing hotel to edit is as simple as tapping the name into the default PW search box.

Yes - Formbuilder has the option to output each form in adherence with a number of popular frontend frameworks - bootstrap included (see screengrab below). There's also a number of embedding options which include the option to completely customise/control the code output so you should be covered from this angle too. Out of curiosity, what are the shortcomings of the default comments you are looking to overcoming. If it's just styling/presentation couldn't you just modify the markup for this instead?

@Goca Are you using a cookie consent management tool by any chance? This potentially could mess with Processwire's cookies if not configured correctly.

Hi all, Can anyone confirm 100% does ProDrafts work with repeater fields? The pro module store page says not, but this update from @ryan says it was added in 2017 - just want to be sure before buying it for a specific repeater-heavy site. TIA ?