it shows that article-specific URL properly and everything...
but, if you click on it, you will see it actually is displaying the content from main blog's current entry, which is here: https://ecrda.net/see/blog
NOTE: my guess is the reason the install needed to be run to even start the blog parsing again was because pulse is installed in a non-default folder. (We install to a subfolder named "see".) Running the install after the upgrade must have fixed some config file(s) pathing to help pulse understand where it lives. Is it possible all these other blog issues with paginations and tags and incorrect content links cited above are just because some config(s) is/are looking for the default install path rather than the custom path?
for example, i know a year or more ago, pagination wasn't working right for lots of users because of path issues. anyone have some insight as to what/where pagination is controlled and how to verify it is looking at the correct path? any other ideas to fix all these blog issues we are encountering? Thanks!!!
another new issue since upgrading: the admin user can add new blog posts, but, the editor user can't.
the admin user can log into the admin dashboard and choose:
blog > new and it takes the admin to:
/see/admin/index.php?p=create
where they can create a new blog/subblog post.
but, when the editor user tries to go to that link, it forces them to:
/see/admin/index.php
any clue on how to get our editor user working so they can access/add/deltee blogs posts again? thanks!!!
thanks for the response. our biggest concern right now is the broken editor user. any estimated time to fix the know bug of an editor user not being able to post to the blog?
as for the "news" link you sent, no - that is not an issue; (that news parent menu element is just a design element and is NOT to be clickable; only "in the news" and "blog" are clickable.)