adrian

@Macrura - I decided to take a different approach with this. Now all the issues I noted above are no longer relevant. Please grab 1.0.4 and let me know how it goes.

I would still recommend the module that soma linked to - if it's just for Youtube or Vimeo videos, this is a much nicer approach than pasting in iframe embed code.

I guess that is another situation where my implemented fix may not be great. I did look at an alternative which is to grab the title from the locked div (rather than the title <input>). The only catch with this approach is that you can't be certain there isn't other html in there - for example, AOS adds a link to edit the field and with locked fields, this is also in that div, so you need to exclude that when extracting the title via js. I suppose I could pass the title to the js file in a different manner so that the updating will still work - do you think I should look into that?

Are you by chance using the master instead of develop branch again? Remember this was fixed on the develop branch:

@Macrura - I implemented a fix based on my assumption mentioned above. I have disabled the "Rename Without Title Change" option when the title field is locked. I think this is a reasonable approach. I guess the only scenario where this isn't perfect is if a title is changed via the API such that the name is different. Could you please try the new version and let me know if it works as expected for your needs?

foreach($subjects as $subject) { echo "<option value='".$sanitizer->alpha($subject->title, Sanitizer::translate)."'>{$subject->title}</option>"; } Check out the inspection of the select options and you can see it's working as expected.

Looking at this now and it seems like it's only an issue if you have the "Rename Without Title Change" option checked. Can you please confirm that you are using that option?

They will be removed as you'll see in my example - isn't that what you want?

If you don't care about keeping the uppercase, then why not use the alpha with translate option that I posted above? Doesn't that take care of everything you need?

I was all set to suggest that you do this: but apparently the Sanitizer::translate option forces lowercase (https://github.com/processwire/processwire-issues/issues/643). Here's another interesting thing I just found: https://github.com/processwire/processwire-issues/issues/644 which doesn't seem expected to me. If Ryan agrees that the first one is a bug, then the alpha sanitizer with translate should result in this:

@AndZyk - nice catch - I am seeing that problem with users also.

Good catch Ian - please grab the latest version which fixes this.

Sorry, I didn't actually test it on a blog page tree - it was more of a theoretical question/consideration. So long as siblings() sorts automatically everything should be good. This is weird - it has that error when installing it via class name, but it works fine when installing from an uploaded zip. Can you reproduce the issue when installing via class name?

I see you have a limit=25 which is a great idea, but I am wondering whether it would also make sense to order by modified date descending? I am just thinking about blog siblings as an example.

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 ?