adrian

Looks awesome, but just got this on attempting to install:

My fork of MarkupSEO has this ability.

https://www.1and1.com/digitalguide/hosting/cms/processwire/

Hi @netcarver - thanks for your thoughts. Nico has just given me push permissions to the repo for this module so I could now start maintaining this module moving forward. However, I honestly don't really want another high profile module on my list of things to support at the moment, so if I do take this on, I will be looking for the community to help with PRs moving forward. Regarding your suggestion to me via PM about a community Github organization - I still think this might be a good idea, but I am also ok with being the gatekeeper for the module, just not wanting to take on being the support person - does that make sense? The other issue is that my fork has several breaking changes that prevent easy upgrading from the current master version that is in the modules directory, so without some manual DB changes, it should only be used for new installs. Anyone else have any thoughts on how best to proceed to ensure no-one breaks there site when upgrading to my new version? Maybe I just need to add an upgrade() method that prevents the module from updating old installs?

It's true that it works by user role, but you could easily give one (or some) of the superusers a different role and block access based on that.

Thanks @Mike Rockett for the fix to prevent saving of unnecessary settings - that will be a huge improvement. Regarding the hidden/unpublished parents preventing children from appearing in the sitemap, isn't it simply a matter of adding include=all to the children() selector on this line: https://gitlab.com/rockettpw/seo/markup-sitemap/blob/142c86571aca9cb80569398b94d69a73676272b9/src/Traits/BuilderTrait.php#L190

Really just all the new features mentioned in the commit log: https://github.com/adrianbj/MarkupSEO/commits/various-fixes-enhancements Anyone else out there ? ?

Thanks @netcarver and @vincent for finding this issue and getting a fix in place and tested. PR has been merged and the module updated! Sorry for the delay - was away last week.

I'm away next week, so don't expect any quick responses to this question, but I am curious if anyone is using my fork (don't forget to go to the other non-master branch)? If you are, I'd love to hear your feedback and curious whether you think I should try to contact Nico and see if I can either take over this project, or whether I should make it a new module? There are lots of new features and in my mind lots of pretty critical bug/functionality fixes. Any thoughts?

The ProtectedMode module allows you to restrict access to just the superuser if you want so that no-one else can login.

I understand the theory behind sticking with labelled master versions and I don't see any harm in advising future superusers to follow that approach, but I guess I don't see why you can't use the latest dev now and still advise them of that for the future. It's not like being on dev forces you to stay on dev. No there isn't - it's really up to Ryan to make this decision and it's not something that is planned for specific date intervals. I think part of the reason for this is that he know that most of us are probably running the dev anyway. I think the key thing here is that starting a new project on the dev branch makes sense because you'll be testing thoroughly as you're using it. Upgrading an existing site to dev maybe the situation that is technically a safer approach. But I have been using PW for 5 years and in that time I think I've only come across 2-3 major bugs introduced in a dev version that affect existing functionality. Typically all you might have to worry about is new features which haven't been fully tested yet. Obviously PW is not perfect (https://github.com/processwire/processwire-issues/issues) and I actually think we need more solving of issues right now than new features, but no software is bug free. But does a "master" label make it more stable? Sometimes, but not always ?

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.