adrian

There are many of us running the dev version on live sites - it's typically more stable than master. Of course there are exceptions on occasion, but I tend to look at the changes implemented in each dev commit - if they are significant, I'll hold off for a week, but if not, I'll update right away.

PHPSpreadsheet will let you read the file: https://phpspreadsheet.readthedocs.io/en/develop/topics/reading-files/ Once you have read the cell that you need, you can add that to a PW page field with the PW API. It's really not that complicated to do, but you might find it a little challenging at first to get your head around things.

The "Restore" tab is now supported. I have also added a new option that lets you display the name field in the Content tab if you have hidden the Settings tab - default is not to show it though.

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