So recently I've discovered that my mediawiki pages are not functioning correctly. For example, when I edit MediaWiki:ipbreasons-dropdown in an attempt to add extra ban reasons to the dropdown.
The wiki recognizes the edit, even showing a link and diff in RecentChanges, but for some reason the extra dropdown item never shows.
The same is happening with MediaWiki:Grouppage-staff. Obviously this is a huge problem. Anyone know any way I can fix this without re-installing mediawiki?
Sounds like a LocalisationCache problem. There are no magic wands for such issues, you need to debug a bit e.g. issuing wfMessage( 'ipbreasons-dropdown' ) in eval.php. If the message doesn't contain what expected, go over the documentation for localisation cache again, it might be something simple like file permissions.
Related
In pre v9.5 websites I used realurl.
When you change the site-title from tileV1 to tilteV2 the page could be accessed with domain.tld/titlev1.html AND domain.tld/titlev2.html.
The realurl path of titlev1 was marked as MovedPermanent (and redirects) to titlev2 and an expire date for the v1 is sent to the browser (+30 days).
My editors don't care a lot about SEO and the rest. They copy pages, deleting the content, moving them around the pagetree - nobody cares about the slug, often this is default-titlexx.html.
With realurl this was less painful compared to the native URL-handling in TYPO3.
I could not find any documents/websites discussing the problem.
Am I missing some option to set? How do you solve this?
Training the editors to double check the slug, but this only works for 2 days then I get the next error report: The page is broken cause a page has moved...
Thanks for any help in this issue!
There are some differences between TYPO3 9 and 10. In 10 you have additionally functionality which handles this:
when changing a slug, TYPO3 offers to change the slugs of the subpages - the editor gets a choice to do this or not
redirects will get created automatically, here you also have the choice to allow redirects for subpages as well.
You might also want to look at the extensions that are available for TYPO3 9 which try to enhance the Slug handling, e.g. sluggi. (I have not used this myself, but it looks like it may be helful).
There are also a number of open issues about Slug handling and redirects.
What I would recommend
Think about updating to 10. There are not quite so many breaking changes and you might find the update quite painless. Or look at the slug extensions.
Familiarize yourself with the slug and redirect handling (in v10). (Yes, the documentation may be incomplete but a lot of it is self-explanatory. Just test changing Slugs on some pages with subpages and move a page and the functionality should reveal itself).
Using permissions (possibly also workspaces) you can restrict what editors may do. You might also want to restrict editing to some pages (e.g. editlock, permissions). If they can't handle something responsibly, maybe they should only have restricted access. (I realize this is not so easy to solve, we have the same problem and defining very fine-grained permissions makes it impossible to handle at some point. Also, the editors should be able to create new pages).
Sorry, I don't have all the answers right now. To be honest, our site is a little messed up in this respect currently, because of using TYPO3 9 for a while and not handling this problem. At some point, the URLs of subpages start to deviate and then it is difficulty to get it cleaned up.
What is better now, though: In realurl the editors often did not fill out the URL segment and then the URL changed every time the page title changed. This is now handled in a better way, I think, where you explicitly have to define the URL.
Hello StackOverflow community,
I've just started having an issue with hyperlinks stored within an MS-Access table not behaving as expected.
I have a small database which, among other things, records links to documents hosted on a company Sharepoint site. Until a few days ago, all was working fine with both the database and the hyperlinks.
For some reason, within the last few days, whenever I (or any of my users) click on these hyperlinks through an Access form (or me clicking directly from the tables), I am getting strange behavior:
Clicking the link does open a new instance of the default browser, as desired. And that browser does navigate to the company Sharepoint site. But none of the links actually open the specific document that they are intended to point to.
Instead, all links are bringing up a general file/folder menu within the Sharepoint site. It is almost as if these links point to a non-existent file within an existing folder.
The very strange part is, if I "edit" any of the hyperlinks in my database, and simply select and copy the "address" text from within the edit hyperlink window, I will always immediately pull up the correct desired document if just paste the address directly into a new browser window.
I would have thought that this type of cutting/pasting would necessarily be equivalent to simply clicking the link. But that is obviously not the case.
I feel like I can safely rule out the possibility that any changes to the Sharepoint site itself would be causing my issue with simply clicking the links (otherwise cutting/pasting the addresses would not bring up the correct documents), but I have to admit I am simply stumped as to why just clicking the hyperlinks directly used to work, but no longer does.
I don't believe there is any code or other relevant information that might be helpful that I am neglecting to include, but would be eager to provide any clarifications/etc if anyone has any idea as to what might be happening here.
Thanks in advance for any thoughts or suggestions!
~JQN
EDIT: I had deleted this question because the issue described above had simply stopped happening. I was unable to explain why, but was also unable to reproduce the issue again after a certain point within a day or two of making the original post.
Since then, the issue has returned. I've been able determine the following:
As described in my note below, when I am getting this odd link behavior, I do NOT get the standard warning from MS-Access indicating that hyperlinks may be harmful, etc.
Strangely, simply opening up a file dialog/file picker and then navigating through that dialog to any location on the (sync'ed) Sharepoint site seems to make the problem go away. I do not need to actually select or open any location on Sharepoint, simply navigating within the sync'ed folder structure seems to do the trick.
Once this happens, all links behave as intended again (ie. they open the correct linked file directly instead of landing on the root folder page). They MS-Access hyperlink warning returns as well. The file/link behavior will remain in that state for several days. Only after, I'd estimate, a week or more of inactivity since the file dialog was last run will the issue return.
FURTHER EDIT: New update...Enough time has passed so that the issue is recurring again. As suspected, links to pages outside of Sharepoint are not affected, and open as expected without issue. Once again, the standard Microsoft hyperlink warning dialog is not coming up for any links.
Obviously, now that I've found the work-around with the file dialog, it's easy enough for me to fix the issue when it arises. I'm hoping that this rings a bell with somebody, though, and perhaps one of you could point me in the right direction for a more complete fix for my users.
Thanks again for any help with this!
YET ANOTHER EDIT: Ok....based upon all the things I've learned in the last couple of weeks (as captured in this post and the comments below), I was about to delete this question and re-post it as "Why is Sharepoint redirecting my URL requests from MS-Access?" As I tried to search the forum to make sure that that question hasnt already been asked, I stumbled across some info that I think gets at the underlying issue:
It looks like this is related to the (very opaque) way that Office processes URL requests. It apparently doesn't simply open the document at the specified link, it first "pre-tests" (I suppose that's the right word) the URL by sending a "Microsoft Office Protocol Discovery" request first.
Apparently, it is possible for Sharepoint to somehow not like the particulars of that MOPD request, and if that happens, then Sharepoint redirects to the file directory page -- and that directory page ends up being opened in the browser instead of the intended link/document.
Again, this only happens sometimes and not others. When it does happen, I've found a clumsy workaround that will correct the issue for about a week or so. I can't reproduce the issue during that week, I just have to wait for the workaround to expire (I obviously don't fully understand why my clumsy workaround works).
It doesn't seem possible to manipulate the particulars of the MOPD request. If possible, I'd love to be able to dispense with MOPD entirely, since I want all the files I'm linking to via Access to be opened as read-only anyway. Unfortunately, I don't think that that is possible either.
I've found some info on this in another SO thread HERE. I still am not quite at the point where I feel I'm ready to submit an answer to this question, but I have some ideas as to what sorts of things may function as an acceptable workaround.
It would be helpful if anyone had any ideas as to how I might be able to reproduce the issue on demand, rather than simply waiting another week for whatever keys/cookies/settings/etc to expire again. I'd need to implement any possible solutions entirely on the Access side of things if possible, rather than on the Sharepoint/server side. Thanks again for any suggestions!
I'm posting this as an answer now, but will avoid accepting it until I've had a chance to verify that it actually works.
I am inserting some code that will run on DB startup. It will open a (an invisible) form that has an Access WebBrowser control included. I'll have that control navigate to a specific file on the Sharepoint site. I believe that it is actually this action that somehow causes the link problems to resolve for a week of so.
This form will run silently in the background, navigate to the sharepoint file location, and then close. This should hopefully refresh whatever characteristics of the MODP request that are present when the links work properly (and are absent while they aren't working properly).
In essence, I'm hoping this approach will have the effect of resetting my (approximately) one week window of desired link functionality to start anew each time the database is opened. In other words, I'm thinking that this will work, although I still don't fully understand why.
Wish me luck!
;)
Just updated Pycharm, and now it won't recognise any of my HTML tags. Do you also have this issue, or have I messed with some settings? A few days ago I changed a few of the HTML settings, but can't really remember what I did...
So, all of the yellow marked tags are not recognised by Pycharm anymore? I have no idea what I've done to cause this, unless its an update issue, but I searched online and could not find others with the same problem.
Had the same problem. Reading through this bug report I tried the following:
File | Invalidate caches
Worked like a (py)charm ;)
Delete your .idea folder, and then restart pycharm.
If you can refine your post, we'll be able to help you; can you point to a hi-lighted tag with your mouse and read the warning on pycharm status bar. Also you can do this by pointing to the warning indicators on the right in front of each line. Here are some things you can check:
settings/code style/html bring it back to defaults
settings/inspection bring it back to defaults
settings/file types choose html and check the registered patterns, it may be broken, you should find *.(htm, html, sht, shtm, shtml)
you could also un\re-install html tools plugin.
I upgraded my website to wordpress 3.4 and it's caused an enormous amount of damage to my site. Half of my posts weren't accessible on the site and 404d, and pages 3 and 4 of my posts on my website 404d as well.
I backed up before upgrading (thank god I had a gut feeling there'd be headaches) using PressBackup. After restoring, I managed to finally be able see my other posts that were missing before, but there's a still a problem. Pages 3 and 4 still don't work ie http://www.winvenue.com/page/3/. Interestingly all the posts that disappeared were from page 3 and page 4.
I'm not sure why I got all these issues, and it's really annoying because this is an active website will hundreds of readers. I'd really like the get this fixed, any help is really appreciated. Thanks
Without knowing about your specific setup, there's some general things you can try.
I'd check the database to see if the posts are really there. If they are, see if the ones that show are any different for the ones that aren't shown.
Then disable all plugins etc to see if any of those can cause problems with the new version. If it works without plugins, turn them on one by one to see which one(s) cause problems.
Restoring from backup probably dosen't include the .htaccess file which responsible on the permalinks.
Try and regenerate your .htaccess file using settings->permalinks->save or manually
Try setting the following field on Settings->Reading (wp-admin/options-reading.php)
Blog pages show at most [5] posts
It could be that your pagination thinks there are 2 posts per page when there are actually 4 (for example) which would cause this effect.
I've also experienced the same issue when upgrading, seems like others as well, when I did a search on Google. Try searching for a draft version of the missing pages, usually WordPress will backup automatically while your typing. Also try the Trash folder, you never know. You may also need to possibly revert back to an older backup file, which may contain the missing pages.
Plugins maybe change your permalink rewrite rules. So, try to deactivate your plugin, all of them. Then reset your permalinks: Setting > permalinks, don't change anything but saving it. Check your site, if it's normal, then it must be one of the plugins.
If it doesn't work, before reactivating the plugins, change to default theme (twenty eleven) andd see if it works with it.
For all I can see, this kind of problems most often come from misconfigured internal rewrite rules.
EDIT: Have you tried to not use pagination?
You can also try to debug by deactivate the canonical redirection by adding:
remove_action( 'template_redirect', 'redirect_canoncial ')
on your functions.php. This will disable the internal URL redirection.
upgrade your permalinks settings
I see sfdocready in some footers of pages I have been working on. I cannot find anything about this?
For example:
<sfdocready id="sfDocReady"></sfdocready>
Thanks!
This has to do with Superfish (the <sfdocready> and <sfmsg> tags).
I just determined what was doing it in my case. Using Safari, I have (well, had, it's gone now for this bizarre behavior) the Awesome Screenshot extension installed. There is a checkbox in its settings called "Enable similar product search powered by Superfish" which looks for images on the page and uses them as search parameters to provide comparison shopping deals for you.
In its defense it did prompt me if I wanted to see price comparisons, but it did so on Amazon in a way that actually looked like the prompt came from Amazon.
To the answer above me about Firefox inserting it when you save the document, that's only because an extension or some JavaScript inserted it first, it has nothing specific to do with Firefox. It also has nothing to do with Wordpress.
Somewhat sleazy stuff, imo.
This looks like it's got something to do with Wordpress themes.
I have, an assumption, that this tag means: "safe document is ready", so something is running only after whole document has been loaded. But what exectly does it mean and how does it work, it`s a big question.
Near this tag I have also also often seen <sfmsg> tag.
This tag is inserted by Firefox when you save the page as an HTML document.
I issued this problem yesterday. I have firefox with a plugin named Awesome Screenshot. In order to solve this you need:
Click over the Awesome Screenshot
Select options
UNCHECK/DISABLE the option: "Enable similar product search powered by Superfish"
And that is all!