adrian

@matjazp - I'll take a look at the new Restore tab - thanks for the reminder. As for the difference between those two conditions - that's a good question - I am not sure really - you'd think the check for homepage and languagePageNames would be relevant on the content tab as well. I guess maybe because you have to explicitly check the "Display 'name' field in content tab?" option for the home template it's up to you as the dev to decide if you want the name on the Content tab.

Great idea @Robin S - I do know about wrapAttr but I must admit that I often forget about it in situations like this - thanks for the reminder. I have implemented like this and it seems to be working well now. @netcarver - if you decide to revert to using this module, let me know how it goes for you.

Sorry @Mike Rockett - another question for you. What do you think about supporting the finding of pages that are children of hidden / unpublished pages? Just because a parent isn't viewable doesn't mean the children aren't. Thanks!

Just an FYI that my fork has just had some major updates and bug fixes: https://github.com/adrianbj/MarkupSEO/tree/various-fixes-enhancements If you are upgrading from an old version of my fork, please change the seo_robots field settings: Details > What should be used for input to Checkboxes

Hi @Mike Rockett Thanks for this module! I was just looking at the module settings and noticed that there is an array of setting for every page of the site that has been saved since this module was installed. Any chance you could not add the: "o1029":{ "priority":false, "excludes":{ "images":false, "page":false, "children":false } } for each page, unless one of the options is true? Otherwise on a large site over time, this is going to become huuuge! And especially given that for most pages, I doubt anyone is touching these settings. Thanks!

Hi @tires - thanks for your thoughts. I am interested in the idea of supporting the doNotTrack option that way - I have raised the discussion with some others. The x icon behavior is intended. While I don't really agree with it, it seems to be standard practice at the moment, which is why we went that route. Personally I hope these silly banners go away soon and it is completely dealt with from a browser setting. Not sure how a user knows if a web site is respecting the setting or not, but I guess in reality you don't really know what is happening even with the banners. Anyone else have any thoughts on all this?

It used to work like that, but it wasn't working for multi-language page names. This change happened in this commit (https://github.com/adrianbj/RestrictTabView/commit/9316082a26315a42d5036481da9d136eb5d4c42e). You could use an older commit, or if you can find a way to make it work while being hidden, I'd love to know. Maybe it needs to be hidden (or positioned off screen) via CSS instead?

I have played with namespacing it and had no luck with this issue. I have to head out in a minute, but if you are interested, you can get the module working with namespace with these lines around line #134 in the main module file: $actionName = $this->wire('input')->get->action; $fullclass = __NAMESPACE__ . '\\' . $actionName; $this->action = new $fullclass; Let me know if you get anywhere, otherwise I can investigate further later and if no luck we can ask Ryan.

I was wondering about that short syntax vs the functions API - I think it's actually a bit confusing because: $pages(1) is obviously the short syntax and pages(1) is obviously the functions API, but $this->pages(1) seems a like it could be interpreted as either. I don't really understand why it's not working either though because as you say, an AA action does extend Wire. I just checked this: bd($this->wire()->pages(1)); which does work without error. I don't know whether this is somehow a bug in my module, or an issue with PW? Any thoughts?

Installing the zip (either from URL or Upload), rather than manually unzipping takes care of this stuff for you ?

Long shot, but I had this recently on the frontend - I was viewing the site via its IP address and I hadn't added this to the allowed hosts in the config.php file yet. As soon as I added, it loaded properly.

Actually, I just decided to commit the changes - there were issues with calling an action via the API which this change fixes, so wanted to get it committed. Let me know if you notice any issues.

Hey @Robin S I think it's all because you are using $this If you try it with just: $p = pages(1) it will be fine. Take a look at: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/FunctionsAPI.php#L50-L52 Note that the pages function is not a class method, but rather a global function. All that said, you did highlight an issue with my __call() method which is why the error message is so confusing. I think I have a fix in place - I might PM it to you and see what you think before I commit.

I would try this line: include_once(__DIR__ . '/DateTimeImmutable_php5.4.php'); before: include_once(__DIR__ . '/BusinessHours.php'); making sure that you have saved the contents of that new class into the BusinessHours module folder.

I would think that including it in the __construct() method would work. Make sure the path is correct and it is actually being included. Note that I haven't ever used this.

This might do the trick: https://gist.github.com/Grummfy/6d4f07a86121a1477cdc

I think it's probably too rare of a need to add to BatchChildEditor, but happy to have it in AdminActions. Just committed it to the latest version.

Yeah, I guess you must be right. Maybe the ozadje_strani image field is set to return a single image which is why it can't be foreach'd? Actually, I guess it's a repeater field and bgimage is the image field - I don't know ?

I don't really understand why it's working at all - '/home/' is not the path for the home page, it's '/' - try that and things should work without the error.

Just to make things clear in case they aren't, you are getting the selected item - you're actually getting the full $page object for the item. The __toString() method is resulting in the ID of that being being output when you try to echo it as a string. You have to specify what field you want from the page, ->title, ->body, etc.

No there's no way around this really, but my solution is the combination of these two modules: https://modules.processwire.com/modules/email-new-user/ With this, when a new user is created they are automatically assigned a password and this is sent to them via email. https://modules.processwire.com/modules/password-force-change/ This ensures that the next time they login they have to change their password. I think this combination is the easiest way to migrate large numbers of users to PW.

I only see one occurrence of that text: I'm not really sure how this could be browser related because the output is all generated server-side. Just an FYI that you have a couple of JS errors showing up in the browser dev console.

@dragan - I just tested your code here without any problems: But based on the error message, it looks like the images field is corrupted somehow. I have never come across this before, but that is where to start looking.

Yeah, it will cause problems if the name field is not available somewhere. If you enable PW's Advanced mode you can use the "Display 'name' field in content tab?" option in a template's System tab. Or you can do this in a module with: $page->template->nameContentTab = 1; You may also want to do: $form->_pw_page_name->collapsed = Inputfield::collapsedYes; Both of these can be seen in action in: https://github.com/adrianbj/RestrictTabView Hope that helps.

I think several AOS features need to be in the core ? Seriously though, if we could get the most used features in the core, then perhaps the lesser used ones could remain in a trimmed down AOS. I think I'd rather see a module that works on top of a core theme, rather than you creating a separate theme that misses out on new features that Ryan adds until you have a chance to add them to your version of the theme. Does that make sense? I don't think you should being trying to maintain support for multiple themes though - I think going forward PW needs one solid flexible theme which can be restyled via CSS and functionality tweaked by hooks and js overrides. I think having multiple themes with different codebases just makes things difficult for Ryan because he often has to add new functionality to multiple themes - this is why I always stick with his default, which in my mind is UiKit these days. Anyway, I am a little OT now, but hopefully my ramblings make sense.