I have a few pages that I recently renamed (and updated all of the redirects), and ever since that time none of their redirects have been appearing in {{#ask}} queries based on their pagenames. For example, I have a page that I renamed from Infliximab to PF-06438179, and it has 26 redirects. Before, a template on the page with a query of the form
{{#ask: [[category:clinical studies]] [[compound number::{{PAGENAME}}]] ... }}
listed 53 pages, but ever since the move it only lists the 6 that direct-link to the page (and ignores the 47 that link to redirects).
I've performed dummy-edits on all of the redirects multiple times to try to refresh the index
I've performed dummy-edits on the page and the template to try to refresh the {{#ask}} function
I've performed dummy-edits on a few of the pages linking to redirects to try to refresh the semantic tags
I've completed a data repair cycle via the SMW admin panel
I've had my sysadmin run refreshLinks.php
None of these has corrected the problem. How do I make SMW rediscover these redirects? Thanks!
Semantic MediaWiki 1.8
MediaWiki 1.20.2
PHP 5.3.19 (apache2handler)
MySQL 5.1.30
It think you have to set
$smwgQEqualitySupport=SMW_EQ_NONE;
See Help on $smwgQEqualitySupport
Related
I tried looking for a solution to this problem (tried cleaning cookies and cache from my browser already). The problem is, I am trying to publish my first website on Github (I am a newbie web developer) and whenever I go to the published link, only the name of the repository shows up, on a blank page (instead of displaying my html+css). And yes, I have commited the files to the Master branch and all that. Would be very thankful if someone helped since I am stuck on this (:
Tried cleaning cookies and Cache
I followed all steps from a tutorial
I uploaded archives (HTML + CSS + Images)
I included a README document on the repository
Expected results would be my webpage showing up (My page has no issues and it shows up locally, but not on the github pages link)
The actual result: sometime si get error 404 and sometimes I only get the name of the repository on a blank page
Is your homepage named index.html?
GitHub pages check for this index term to render html. If found it does render, otherwise page not error pops up.
I faced the same issue(404 on a newly set up GitHub pages website). I tried many methods such as switching a new theme etc. But it seems that it still did not work on my case. I finally solved it by switching the branch of GitHub pages website to another branch first, click save. Wait for a while and switch it back again. Then the 404 problem was suddenly solved.
In one of the online documents that talks about appcache for HTML5, it indicates that the cached files get updated once an offline user reconnects. I checked the original HTML5 appcache definition by W3, and I am not able to find anything that supports this statement.
Does anyone know if this is to be true?
Thanks in advance
MDN says the following, although if you scroll up on that page it says it's being deprecated.
If an application cache exists, the browser loads the document and its associated resources directly from the cache, without accessing the network. This speeds up the document load time.
The browser then checks to see if the cache manifest has been updated on the server.
If the cache manifest has been updated, the browser downloads a new version of the manifest and the resources listed in the manifest. This is done in the background and does not affect performance significantly.
And logic tells me that it would also depend on the app you're using, server you're trying to connect to and any special settings it might have, how long your browser keeps it's history, what it keeps, and if you saved the page to view offline - whether or not you have all the code/images saved in the right location(s).
Example:
Imagine you saved a page to view offline, and that page has a JS event handler that ran a while loop that did an ajax request every n seconds to do something, like make a number on a page change as long as you were online... As long as the loop is running, you suddenly connect to the internet, and it makes the request to the proper url with the right arguments, then it should go through, even though the url in your browser might say something like file:///C:/Users/you/Desktop/....
I've done this before, even though my url was like the one above. One time I was using braintree's drop-in javascript to a website, and using it's api on my backend. Trying to load the page when offline = Nothing. Online = Updated the spot on the page just fine when I had the required arguments, and it was pointing to the right url. If I got offline again, I could refresh the page, see the same images loaded in the <div>, but I couldn't send any data with it.
Cross-posted in a Github issue at https://github.com/SeanKilleen/seankilleen.github.io/issues/189
Digging into an issue with GitHub pages that appears like it might be recent.
I noticed an up-tick in 404s via Google Analytics. It appears that posts with trailing slashes are becoming 404'd, but appeared just fine without the slash.
My local Jekyll instance generates the following structure for how-to-leave-a-company-well.md from Feb 2015:
/2015
/02
/how-to-leave-a-company-well.html
/how-to-leave-a-company-well
/index.html
So, the following URLs work just fine locally:
http://localhost:4000/2015/02/how-to-leave-a-company-well
http://localhost:4000/2015/02/how-to-leave-a-company-well.html
http://localhost:4000/2015/02/how-to-leave-a-company-well/index.html
http://localhost:4000/2015/02/how-to-leave-a-company-well/
Those last two URLs that I've bolded do not seem to exist on my published site after GitHub Pages generates the documents.
I cannot reach http://seankilleen.com/2015/02/how-to-leave-a-company-well/ or http://seankilleen.com/2015/02/how-to-leave-a-company-well/index.html
This seems to indicate to me that GitHub Pages is doing something differently than my Jekyll installation. Given that the 404 spike is recent, I'm wondering if there might have been a change related to this.
Does anyone have a thought on how I might be able to diagnose this? It's a bit of a black box for me when my local is doing what I expect and I can't see the Github Pages process.
Jekyll 3 changed the way the permalinks worked, and dropped the trailing slash if your permalink setup did not contain one - yours does not contain a trailing slash at the end of your permalink in the config file. Jekyll 3 now respects that and thus your page is a 404 when there is a trailing slash in the url (since you want it without it).
https://jekyllrb.com/docs/upgrading/2-to-3/#permalinks-no-longer-automatically-add-a-trailing-slash
You may want to check which version of jekyll you have installed - you may be on 2.x and GH is now 3.x
When working locally, are you telling jekyll to use the GH pages gem? if you
don't do this you may get different behavior on GH than local. I do not do this, so I can't tell you how to do it (or if this particular issue would happen), but I do know that you should do it if you want to preview locally what you will get when serving via GH.
I embeded a gist using {% gist octocat/0831f3fbd83ac4d46451 git-author-rewrite.sh %}, then I ran jekyll server, came this warning:
Regenerating: 1 file(s) changed at 2015-08-28 19:43:12
Warning: The tag for your gist octocat/0831f3fbd83ac4d46451
could not be generated. This will affect users who do not have JavaScript available or enabled in their browsers.
Warning: The tag for your gist octocat/0831f3fbd83ac4d46451 could not be generated. This will affect users who do not have JavaScript available or enabled in their browsers. ...done in 7.157032 seconds.
And the page generated looked strange: extra word displayed. Reason unknown.
Gem jekyll-gist has been installed already. What can I do with this? I googled for several hours, but with no luck.
Edit: Hmm, add pictures to show why this question came out:
noscript tag warning:
extra word 'true' displayed:
To close this issue, let me add something.
Yes, this is related with proxy, and the jekyll (my version is 2.5.3). In my case, I ran jekyll server just behind the http proxy, and jekyll threw out a warning, generated this html code (I thought there may be something wrong):
<p>true<script src="https://gist.github.com/octocat/0831f3fbd83ac4d46451.js?file=git-author-rewrite.sh"></script></p>
So you can see the extra word 'true'.
To avoid this, I just insert the script instead of embedded gist (retrieved from the generated code):
<p><script src="https://gist.github.com/octocat/0831f3fbd83ac4d46451.js"></script></p>
I recommend the audiences to use script instead of gist. There's another reason: if you want to run jekyll and overview site offline, the embedded gist will cause a connection error.
We fed up with duplicate links of Joomla and we converted our website from Joomla to Html. Because in Joomla we have only (approx) 80 pages, but Google indexed 1970(!) pages. That means duplicate content for Google. So we converted it to Html. But what we can do for the old pages?
Our new link structure is domainname.com/article.html
But the old structure was domainname.com/index.php/article.php
So, which is better for the old pages, 301 redirect or 404 not found? What should we do?
If the content has moved then it is 301 Moved Permanently (coupled with a Location header to say where it has moved to).
If the content has been removed then it is 410 Gone.
404 Not Found is for content that never existed or can't be found for unknown reasons.
It sounds like you want to 301 all the URLs where the duplicate content used to be available to the one place that it is now available.
404 Not Found: The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
301 Moved Permanently: The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
In my opinion, if the page you are removing has a suitable alternative page on your web site, then 301 it. Do not always 301 the page to your home page. If there is no suitable, and by suitable I mean, a page that is very similar to the page you are removing, then 404 the page.
301 if there is a related and similar page to the page you are removing. 404 if there is not.
You can see complete blog here: http://www.seroundtable.com/404-301-web-page-16773.html