adrian

I was thinking that the PW admin could push its js and css assets, but as I mentioned above, it does seem like there might be some caching issues with "push", so maybe it's not worth worrying about and just stick with swapping to http/2 and making sure that the ALPN extension is enabled?

So just to confirm, do you agree that this module isn't having any impacts on the issue?

@Mike Rockett - I've come across an issue with the way that Jumplinks sanitizes the URL. I have partners linking in to the site with campaign info in the query string, but Jumplinks is removing the "?" so that: mysite.com/subscribe/partner/?utm=123 becomes: mysite.com/sign-up/partner/-utm-123 which of course looks like a second urlsegment to PW and therefore breaks things. Any chance of revising the sanitizer that makes that change please?

@Kiwi Chris Just looked at one of my sites and this is what I put in ready.php // lets non superusers view unpublished and hidden pages in listers // https://processwire.com/talk/topic/9346-not-all-specified-templates-are-editable-only-includehidden-is-allowed/?do=findComment&comment=143068 $this->wire()->addHookBefore('ProcessPageLister::getSelector', function($event) { $event->object->allowIncludeAll = true; }); Does this solve your problems?

I see that notice with non-superusers even without this module installed. Have you tested with the module uninstalled, disabled, or with a user with no restricted branches?

@Kiwi Chris - even on a site without this module installed, I have to do this for users to see unpublished pages in ListerPro: Does that help?

Yep, because of the way this module works, it can only limit to one branch of the tree. This limit affects all places where the user could view and/or edit pages outside that branch. If you want to give access to multiple branches you'll need a different approach - this thread might be helpful:

Hi all - I just wanted to start a discussion about using push with http/2. @teppo's recent post here (https://processwire.com/talk/topic/5630-module-aiom-all-in-one-minify-for-css-less-js-and-html/?do=findComment&comment=193086) got me to finally move all my servers to use http/2 which is great, but it seems like there is much more to it than that. There are a few articles of interest: https://www.smashingmagazine.com/2017/04/guide-http2-server-push/ https://www.keycdn.com/blog/http-preload-vs-http2-push https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ but I'd love to hear what everyone is actually doing on their sites and also wondering if the PW core should try to push certain assets. There seem to be issues with browsers not caching assets when push is used and I am wondering whether in general you should push everything needed for a page, or ? Thanks all! PS - if you're wanting to upgrade your Debian or Ubuntu servers, this is a good guide: https://blog.samuel.domains/blog/tutorials/how-to-enable-http2-on-apache-debian-9 - I am running Debian 10 and PHP 7.3 so just replace the references to 7.0 to 7.3 and you'll be good.

Thanks @sz-ligatur for those screenshots - you are confusing two different features here. The use of "snippets" is probable confusing things here. The snippets that can be stored in that linked js file are autocompletion snippets triggered automatically when typing in the ACE code editor that the Console panel uses. I think for your purposes you should be using the SnippetRunner panel (https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=snippet-runner) and storing each snippet and a separate *.php files under either: /site/templates/TracyDebugger/snippets/ /site/assets/TracyDebugger/snippets/ Does that help explain things?

@sz-ligatur Can you show your snippets file? It should look like this: https://cdn.rawgit.com/adrianbj/f110cf9cc10b455d4d794c18f128b2fd/raw/34b6fc02e0e6c4a3a6d6668c35110bf44005d562/tracy-snippets.js which as you can see defines getCustomCodeSnippets()

I use: http://modules.processwire.com/modules/fieldtype-phone/ ?

Thanks - from what I can tell, the backup is being created successfully - it's just not linked to. The new version just committed now returns this with the restore link included and the error color changed to match the PW uikit color and also make links white and underlined so they are visible. You mentioned above that the restore didn't work though, so please test the new version and let me know.

Thanks @Mike Rockett - using the page ID like that does work. This was the combo I needed: Note that the first one showing "sign-up/" is from the selected page, not manually entered. With this, all seems to work as expected.

Simplest option for right now would be to remove all custom links from the PW Info panel - ie, empty the list on the right in the module settings.

Hi @Robin S - the backup should still get created even if the action returns false. Could you perhaps send me your action code to test?

@Chris B - I also wonder if you'd be better off creating a module that works with SendInBlue's API rather than using SMTP. I would use WireMailGun as a starting point.

Brilliant as always @Robin S

@Robin S - the option is now available in the latest version. It feels a bit weird the way I have implemented it, but it's the quickest option for now.

Just grab the version before that commit, eg: https://github.com/processwire/processwire/tree/4b8b06af0f39828cec384c6bb8ad7997fc6d21fe Would you mind submitting an issue report about this so that Ryan can fix ASAP? PS - find and count methods only return published pages by default, so I am not sure why you actually need the status=published ?

Looks like Ryan just broke it in this commit: https://github.com/processwire/processwire/commit/6fcc0502b6d3c7c4aed2fc1b1842e513e6c5221c PS - it's coming from the "status=published" selector in your home.php template.

They are just pages behind the scenes and unpublishing would work if Ryan would fix the 2048 vs 2049 issue, although I guess at this point it might be a breaking change. Did you try: $item->addStatus(Page::statusUnpublished); $item->removeStatus(Page::statusOn);

Yeah, I am sure I can sort out the Pluralize issues. Of course the really simple solution here would be keep the field settings even with the create field checkbox unchecked - this way nothing else would need to be changed - you'd just use the field label as the way to generate all the other things. It would work well, but would be a strange / confusing interface.

I've definitely done that before as well, so you're not the only one ? You're right that it kinda makes the module name a bit weird, but then it's always been a bit of a mouthful anyway. The thing is I am not sure what would be the most logical way to support this - everything is pre-populated based on the field label and its plurality. I am thinking that there should be a "Create Field" checkbox in the field settings that is checked by default, but if you uncheck, the field settings are hidden and the form starts at the "Page Settings" fieldset where you need to manually enter the Parent Page Title and that is used to automatically populate the parent and child template field lables/names (rather than coming directly from the field label? Any thoughts?

Thanks for your thoughts @teppo - I agree it's not a simple problem to solve and that there are some gotchas for sure. However I feel like if some assumptions are made, it could be made to be functional. Firstly, if only supported first level pages (those directly under home), we could simply strip off everything after the second forward slash and assume those are urlsegments and simply find the page that matches the ID of the page whose name was changed and then re-append all those segments as they were in the original URL. I know this wouldn't solve the problem for all setups but I bet it would handle most. I think this discussion should be continued here: https://github.com/processwire/processwire-requests/issues/338

Hi everyone, I haven't really used this module much before, but just came across something that I thought should work, but it doesn't seem to. This works: But this doesn't: which of course means that if someone changes the name of the "buy-now" to something else, not only do I need to add a new jumplink from "buy-now" to the new name, but I also need to remember to change the destination for the initial linking from "/subscribe" to the path of the renamed page. Is there any reason the "page:1495" format can't also work when using wildcards? Just in case it's not clear, {all} represents a PW url segment. Thanks for any thoughts. OT, but I was actually a little surprised that the core PagePathHistory module doesn't try to handle paths with urlsegments - I know it's not simple, but I thought it could try to strip back a segment at a time to try to find the actual page and redirect to the stored ID.