while searching for a bug in a project i found many page.xml files, where the 'view-id' was showing to totally wrong pathes (old structure), or some had no view-id at all!
As far as i understood Seam it works like this:
i call in the browser.the pages/index.xhtml
then Seam looks if there is a page.xml with a view-id pointing to pages/index.xhtml
what happens, if in the page.xml are some navigation-rules and actions, but the view-id points to pages/foo/index.xhtml
And what happens to page.xml, where is no view-id at all?
The navigation rules, and the actions should never be called, because it is not connected via the view-id, right?
Related
Previously working code that downloads a csv file from our site, now fails. Chrome, Safari and Edge don't display anything helpful except "Blob Blocked", but Firefox shows a stack trace;
Uncaught TypeError: Location.href setter: Access to 'blob:http://oursite.test/7e283bab-e48c-a942-928c-fae0907fdc82' from script denied.
Then a stack dump from googletagmanager
This appears to be a fault in the tagmanager code introduced in the last couple of weeks.
The fault appears in all browsers and is resolved immediately by commenting out the tag manager. The problem reported by a customer on the production system, and then found on both staging and locally. The customer advised they had used the export function successfully 2 weeks ago.
The question really is, do Google maintain a public facing issues log for things like the tag manager?
It's not about GTM as a library really, it's about poor user implementation. It's not up to Google to check for user-introduced conflicts with the rest of the site's functionality.
What you could do is go to GTM, and see what has been released in the past two weeks. Inspect things and look for anything that could interfere with the site's functionality. At the same time - do the opposite, see all the front-end changes introduced during this time frame by the web-dev team.
Things to watch for is mostly unclosured JS deployed in custom HTML tags. junior GTM implementation specialists like to use the global space, taking the global variables, often after the page is loaded, thus overwriting front-end's variables.
Sometimes, people would deploy minified unclosured code to the DOM, thus chaotically taking short var names. To the same end.
This is likely the easiest and most common way for GTM to break front-end. There definitely still are many ways to do so besides this though.
If this doesn't help, there's another easy way to debug it: make a new workspace from Default (or whatever is live), go into the preview mode and confirm that the issue still happens. Now start disabling newest created fired tags one by one and pinpoint which one causes the issue.
Let us know what it was.
Solution was to replace the previous tag manager code with the latest recommended snippet
Using Nuxt, we need to be able to render pseudo-routes, like this:
https://server.com/non-existent-route
Where "non-existent-route" is a dynamic path.
Normally, this would render error.vue. This is fine, as we've subverting the use of this page to render what we want. But... we just discovered that Nuxt is sending a 404 anyway! This only happens when the page is first loaded in a fresh tab, for some reason. This is very bad.
So, we need a way to avoid HTTP status 404 in some cases.
We found this:
https://medium.com/finn-no/hacking-nuxts-404-logic-for-maximum-awesome-and-easy-proxying-e4efaeb03d66
which is actually not as helpful as we had hoped it would be, as it simply provides a way to proxy another URL, sending us back to the same problem.
We suspect there might be some middleware solution to this problem... but have not been able to come up with it.
Turns out the answer was right here all long:
https://nuxtjs.org/guide/routing#dynamic-nested-routes
Rather disappointing that nobody suggested this extremely simple solution.
I've got a strange senario/question for you.
I'm running drupal 6 with advanced forum (although my problem doesn't go away if I just use the forum module that comes with drupal)! Everything has been fine and so I've left it untouched (not open to the public) for about a month while I've been sorting out legal work...
I came back to it a few days ago only to find 'http://mysite.com/forum' (I'm using clean URL's) does not exist!
I've tried everything I can think of! Even silly things like 'http://mysite.com/forum s'. But it doesn't even appear to be there in Content Management > Content!
I can get to the individual posts and even the individual catergory/containers - I'm just missing the index page!
I've tried disabling and re enabling the advanced forum module, reseting it's settings and even clearing the site cache! Non of which made any difference! I was going to try typing the node in, but I wasn't sure what it was!...
Please help me as soon as possible!
Thanks in advance,
Andy
Latest
Okay, just to clarify exactly what's happening and what I've done so far after 'ax's' wonderful assitants:
Whats Happening is, I get Drupal's 404 Page Not Found message/page when trying to get to www.mysite.com/forum! The strange thing is though, by typing the URL of the individual sections/catergorys I can see them, and all the posts inside etc!
I have, been into sites/all/modules/advanced_forum/advanced_forum.module and look at the variables in the advanced_forum_page($tid=0) function.
First, I just created a post/topic in the forum var_dumping all the variables in the function! They all returned NULL.
But then in the function, I one by one var_dumped all the variables, after the line they were first used (in the function), I deleted the var_dump line for each variable after I refreshed the forum page, so there was only one var_dump in the function at once. The strange thing was nothing appeared on the page, even when I tried `drupal_set_message(print_r($variable));!
So, I don't know and I just need it fixing asap please! ... Thanks in Advance
you can try two solution:
Reinstall the module instead of deactivating and reactivating it (you will lose your current categorization, however it seems like your forum is empty right now).
Build a new installation to make some tests, enable the advanced forum module and take a look at the index page of the forum to see if it's replicable.
Take a look at the issue queue of the module too, maybe someone else had the same problem.
Just figured out what was going on, and therefore was able to sort my problem out myself!
It was the most stupid thing as well. For some reason, I had an empty folder called... you guessed, 'forum' in the root of my website and as soon as I deleted it, I saw my forum index for the first time in ages.
Obviously, Drupal was looking in the folder instead of using the module etc... (You Know...)
Anyway, thanks for your attempts to help me - much appreciated!
-- Andy
I have spent about 7 hours trying to figure this out but gotten nowhere.
This is how my fiddler trace looks like
I have two routes that look like below that are registered for this page.
[route name="DummyResultsWithMarketStateNames" url="DummyResults/state-{statename}/market-{marketname}/page-{page}/{action}"
controller="DummyResults" action="Show"/]
[route name="DummyResultsWithMarketId" url="DummyResults/market-{marketid}/page-{page}/{action}"
controller="DummyResults" action="Show"/]
For this url, the first route matches and it goes to the right action. However, the client is sending in another request a second later in which it removes the last parameter 'page-1' and replaces it with 'none'. I've traced for XHR's and there are none. I'm not sure if this is an issue with the MVC framework itself but how would that translate as a request from the client?!!! Also, I'm getting different behavior with different browsers (IE trace above). Anyone encountered such strange behavior? I'd be happy to provide more info if you'd like.
UPDATE:
I setup the site on IIS and eliminated all image, css or script requests. I still end up with multiple requests. The original dummyresults page seems to be working now after I removed the .htc's. However, I have another page (screenshot below) that is not 'co-operating'. Should I add Ignoreroutes for certain extensions? This is driving me nuts!!! Pardon the 'bleep' on the image (IP reasons). PS: I setup another site for serving up all static resources.
Q: Should I add Ignoreroutes for certain extensions?
A: Of course! By default the WCF extension "*.svc" is ignored. The first thing I add on a ne page is for instance the ignore rule for the favicon.ico.
RouteTable.Routes.IgnoreRoute("*.svc");
RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
RouteTable.Routes.IgnoreRoute("favicon.ico");
Whenever we make changes to the CSS, it generally takes 24 hours to reflect those changes on my site. I have tried clearing the server cache and browser cache but it doesn't help too. Is there any other way to make the CSS changes reflect immediately after updation?
it happens in all the browsers... when i check it in the browser , i can access my css file with two paths eg : i store my css in folder named "Cssfolder" and my css name is say 135.css
So when i access the folder paths, Cssfolder/135.css & cssfolder/135.css, one of the path shows me latest css whereas other one shows me old css.Notice the "c" is captital in one path whereas small in other path.
Thanks.
I've found this to be a pretty common problem in a lot of my projects. I would suggest two things...
If it's just an app that you are working on you can use the CSS Cachebuster during development.
Following the idea behind the Cachebuster I have found that often adding the timestamp of the CSS file as a query string off of the CSS link will help in telling the browser that the file is different... something like... whatever.css?12212009035543
You might want to use a monitoring tool, like Live Http Headers for Firefox, to see the requests and responses to and from the server. This usually solves a lot of problems for me. Take a look at the "Expire" headers and conditional requests (like: "If-modified-since"). This said, take a look at server and client local times and timezones - it might be that they differ significantly and conditional GET requests "seem to be" handled correctly, because of future or otherwise mangled timestamps.
You can force to load the current css directly from the server with appending a random unique value to the url, like http://example.com/Cssfolder/135.css?983274928374 and http://example.com/cssfolder/134.css?08973249827. There's no way that this would ever get cached unless you use the same random value twice.
This way you learn where to look further for the solution to your problem: At the server, the ISP/a proxy or your browser.
You really need to see whether this is server side or client side. If the server is still serving the old CSS then clearly you've got no chance on the client side.
I've occasionally seen times where I've had to show the CSS in the browser, and then next time I've been to the real page, it's used that new CSS. Usually just hitting refresh does it.
Do you have any web caches like Akamai involved anywhere?
If you try to go to the CSS page from a computer which has never seen the old version, which version does it show?
EDIT: Changed answer to reflect edits in question.
I have been dealing with this issue in the past, and ended up writing a httpmodule to deal with it.
It's pretty simple, it just finds all script/css links in head tag (they now need to have runat=server) and appends the assembly version number to the link, in the same way as Tim K describes. This way im sure my clients always fetches the newest css/scripts when my app is updated in production, and never have to deal with this issue again.
Maybe Internet Service Provider cache, as in this case?
I was perplexed by this issue then someone said Ctrl+F5. Worked for me :)
When I am developing and I need to be sure that I am seeing changes as I work, I stick the css in the page ie
<style type="text/css">
/* your css */
</style>
Or you could constantly change the name of the css file itself, not very useful in a production environment, but perhaps okay while developing.
I know it doesn't solve the problem, but for developing it is okay.