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.

                                          2.1.0

                                          This is a pseudo-resource, as it isn't related to any model. It contains a list of route names that can be iterated to generate URLs to static pages of the app. By default there are 2 static pages: index and tags. Tags are only present in the list if the tags extension is activated.

                                          A new Extender (FoF\Sitemap\Extend\RegisterStaticUrl) has been added, so that other extensions can add thier own static URLs to the list. Example:

                                          new RegisterStaticUrl('reviews')

                                            IanM Could I use this to register multiple URLs from extend.php?

                                            • IanM replied to this.