my site is 1.6.3, and i just upgraded php to 8.2 today.
and I tried to updated fof/sitemap to new version from 1.0.3. But i encountered following errors
does anyone know how to fix it?
Thank you

an:/var/www/flarum$ sudo composer update fof/sitemap
[sudo] password for savip:
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Continue as root/super user [yes]? yes
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:799
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:804
Loading composer repositories with package information
Info from https://repo.packagist.org: #StandWithUkraine
Updating dependencies
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/Problem.php:320
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - laminas/laminas-httphandlerrunner 1.5.0 requires php ^7.3 || ~8.0.0 || ~8.1.0 -> your php version (8.2.0) does not satisfy that requirement.
    - flarum/core v1.6.3 requires laminas/laminas-httphandlerrunner ^1.2.0 -> satisfiable by laminas/laminas-httphandlerrunner[1.5.0].
    - flarum/core is locked to version v1.6.3 and an update of this package was not requested.

    kebindong the problem seems to be with Flarum itself, not Sitemap. One of Flarum's dependencies doesn't officially support PHP 8.2 yet, so you would have to specify --ignore-platform-reqs or hard-code the platform value to 8.1 in composer.json

    You would likely see the same error if you try updating Flarum itself or install any other extension.

        clarkwinkelmann I am currently using php 8.2 on my site with a flarum installed, there is no error log on the php fpm side, it seems stable for now. flarum 1.6.3 version.

            demirel yes, there shouldn't be any issue. It's just that one of the dependencies told Composer it has only been tested with PHP 8.0 and 8.1, so Composer freaks out when it realizes you are on PHP 8.2. But PHP versions are for the most part backward compatible so there are probably no actual runtime errors.

            To make Composer ignore the problem you have to use one of the command flags that tell it to ignore the version, or edit composer.json and tell it you want the version of Flarum's dependencies for PHP 8.1, which will most likely work in 8.2 as well.

                clarkwinkelmann I had done the cloudpanel update after the Flarum 1.6. Most likely this is why I was able to upgrade without error. Basically 8.1 was active, I chose the post-update version 8.2.

                  a month later

                  I have sitemap 1.0.3, and I am attempting to update to version 2.0.1, but I get

                  Updating dependencies
                  Nothing to modify in lock file
                  Installing dependencies from lock file (including require-dev)
                  Nothing to install, update or remove

                  Am I doing something wrong?

                    luceos

                    It does help. It says I'm not running the correct version of php. I'm surprised because I was certain I had other extension requiring php 8.
                    I'll start there and will report back if I have any other issues.

                        luceos yes as it turns out, php -v returns 7.4.33. That said, if I roll out php 8.0.27 or 8.1.14, run the command you specify here

                        update --prefer-dist --no-dev -a -W

                        And then:

                        php flarum migrate
                        php flarum cache:clear

                        The site just breaks down and gives error 500 for any and all requests. Is there a documented migration path?

                        Things play friendly with me until I clear the cache. I'm running Flarum 1.6.3

                            6 days later

                            luceos

                            Thank you, with your guidance, I was able to get on the php 8.1 bandwagon.

                            The composer why-not fof/sitemap 2.0 now gives me:

                            Deprecated: Return type of Symfony\Component\Console\Helper\HelperSet::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///opt/cpanel/composer/bin/composer/vendor/symfony/console/Helper/HelperSet.php on line 112
Deprecation Notice: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in phar:///opt/cpanel/composer/bin/composer/vendor/justinrainbow/json-schema/src/JsonSchema/Constraints/Constraint.php:48
Deprecation Notice: Return type of Composer\Repository\ArrayRepository::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///opt/cpanel/composer/bin/composer/src/Composer/Repository/ArrayRepository.php:286
Deprecation Notice: Return type of Composer\Repository\ArrayRepository::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///opt/cpanel/composer/bin/composer/src/Composer/Repository/ArrayRepository.php:286
Deprecation Notice: Return type of Composer\Repository\ArrayRepository::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///opt/cpanel/composer/bin/composer/src/Composer/Repository/ArrayRepository.php:286
Deprecation Notice: Return type of Composer\Repository\CompositeRepository::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be usedto temporarily suppress the notice in phar:///opt/cpanel/composer/bin/composer/src/Composer/Repository/CompositeRepository.php:180
Info from https://repo.packagist.org: #StandWithUkraine
Deprecation Notice: Return type of Composer\Repository\ArrayRepository::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///opt/cpanel/composer/bin/composer/src/Composer/Repository/ArrayRepository.php:286
flarum/flarum  -  requires  fof/sitemap (^1.0)

                                blueCamel it looks like your Composer version is too recent for the PHP version it runs as EDIT: I think it's more likely the opposite. You probably updated PHP but are still running an older Composer version. You can check version with composer --version

                                If everything is up to date, you could just hide those deprecation notices in your php.ini config. But I think if you have the right PHP version for your Composer version it shouldn't output any notice/warning.

                                In any case, if the Composer command reached the end, you can ignore those deprecation notices, they shouldn't prevent Composer from finishing its job.

                                    4 days later

                                    After updating composer, I was able to get fof-sitemap to the latest version by running the require command.

                                    Thanks everyone.

                                    a month later

                                    I hope I havent missed someone already addressing this
                                    I am adding sitemap to my site to help with SEO and all that
                                    /sitemap.xml has been added as a location as mentioned in the OP nginx troubleshooting. However I have it set to the multi map mode and it seems to put them in /public/sitemaps/sitemap/sitemap(number).xml, would I need to change the nginx.conf to reflect each one?

                                    and so i'm not just being completely useless and not providing anything, if you're using nginx via docker and pushing the forum out that way, change both the in-docker nginx conf and the host one. That will at least get you somewhere, and make sure the location{ is separate from the other.

                                      Lumeinshin the sitemap at the well-known path /sitemap.xml contains instructions to tell search engines where the individual map files are. It's expected for the auto-generated files to be found at a different path. All you need is to give the original /sitemap.yml URL to search engines and they'll automatically figure it out.

                                      EDIT: as to the nginx configuration, you probably don't need to change it further. The instructions in the README are because of an issue that only happens with that exact file path. If you get any error from the Google search console, please report back with the message!

                                          clarkwinkelmann
                                          thanks for the quick reply, 😃
                                          For both google and bing, both give a HTTP Error: 404. i'll give it a bit longer before I try changing more settings just to make sure the forum has had a chance to make its sitemap, although I doubt that'll do it

                                              Lumeinshin as soon as the extension is enabled, trying to access <forum url>/sitemap.xml should return an XML file with HTTP code 200. You can test it yourself in the browser. There is no file on disk with that name, that's normal. Flarum will automatically answer the URL with an auto-generated response. The change to nginx configuration is because sometimes nginx refuses to let Flarum generate an answer for that URL.

                                                18 days later

                                                hmm, for me it says Flarum itself depends on 1.0, but uninstalling 1.0 and then installing 2.x again seems to have worked.