We've recently upgraded our site from .net 2.0 to .net 4.5. For SEO purposes we use ISAPI filters to convert urls which look like this:
MainSite/directory/virginia/richmond.aspx
Into:
MainSite/ProcessLocation.aspx?state=virginia&city=richmond
RewriteRule ^/((?:MainSite_Prod|MainSite)/)?directory/(.*)/(.*)\.aspx /$1ProcessLocation.aspx?state=$2&city=$3 [U]
For our ISAPI processing, we upgraded from Ionic's IsapiRewrite4.dll to IIRF.
The rewrite works like it used to, but all relative paths on the page which are processed in the code behind now have the incorrect relative path.
For example, setting the following href in the code-behind:
someLink.HRef = "#someLocation";
Now results in the following when the page is constructed:
<a href="../../#someLocation" />
Rather than the desired:
<a href="#someLocation" />
This was not an issue in .net 2.0 and IsapiRewrite4.
Does anyone have any ideas how to fix this?
Thanks!
Related
I have just updated my typo3 site from 8.7.29 to 9.5.11 following the official documentation. From technical point of view everything went fine: the upgrade wizard ran successfully in all the required steps and there are no complains from all the available checking tools (database, extensions,...).
The additional problem was that I had to migrate from css_styled_content to fluid_styled_content (because scc_styled_content is not supported anymore by typo3 9). So I modified my old template to work with fluid. After that everything is fine except the fact that all the internal links are not rendered correctly. In particular in the FE all the internal links are reported as:
<a class="internal-link" href="t3://page?uid=246" title="Opens internal link in current window">My link</a>
So obviously typolinks are not parsed correctly.
Some other users reported a similar problem when the extension frontend editing is used. In my case the problem is still there even if this extension is disabled...
Do you have any idea on what is going on?
Thanks a lot for your help!
We have one Plone site (4.3.x) using TinyMCE version 1.4.3, but we found that we should have the version 1.3.18 instead for this Plone version.
So I:
Uninstalled the TinyMCE package ( manage / portal_setup / import / Remove TinyMCE profile ).
Pin buildout version to 1.3.18 and run buildout.
Reinstalled TinyMCE package ( same procediment, but select TinyMCE install profile).
After that I notice that:
For default Plone content types it worked fine.
For the new dexterity content types defined in this Plone Site it didn't work. It load just a textarea with html into it instead of load TinyMCE.
I did many tests on this, and what I can see is that my content type should use wysiwygEditorBox macro from this template Products/TinyMCE/skins/tinymce/tinymce_wysiwyg_support.pt but instead it is using this template Products/CMFPlone/skins/plone_wysiwyg/wysiwyg_support.pt.
I tried to change order of portal_skins but it just affect Archetypes types, not Dexterity types.
What step should I do next? is there any better way to debug it instead of adding <span> tags with debug messages?
Looking in the parts/omelette directory shows the following in plone/app/form/widgets/wysiwygwidget.pt (line 21)
support_path string:nocall:here/${editor}_wysiwyg_support|here/${editor}/wysiwyg_support|here/po
My guess is that ${editor} isn't set right (ie to tinymce) so the above line is falling back to search for the wysiwyg_support.pt template.
I've recently updated my ASP.NET project to .NET 4.5 (from 3.5) . This led to ClientSideEvents not firing properly on my Infragistics UltraWebGrid.
The problem is that in my .aspx file I have configured a client side event on the UltraWebGrid like this:
<ClientSideEvents ClickCellButtonHandler="webGridSoftwareConfigurations_CellClickHandler" />
And in a js-file I have the following:
function webGridSoftwareConfigurations_CellClickHandler(gridName, cellId) {
// Do some stuff
}
Previously, when I clicked in a cell, the javascript function was triggered. But now after the update to .NET 4.5, nothing happens. I'm using Infragistics2, Infragistics.Web.dll with version 11.1.20111.2112
I think the root of my problems were actually caused by the fact that ASP.NET 4.x changes how the controls ids are generated. Before, the ids were prefixed with ctl00 and the older Infragistics NetAdvantage controls seem to be dependent of this.
My solution was to:
First, update Infragistics NetAdvantage to a more recent version (NetAdvantage 2011). There are newer version but this one still supports .NET 3.5, and I need this since I can't update all my projects that use Infragistics NetAdvantage to .NET 4.5
And then update the web.config so that we use the old way of naming controls:
<configuration>
<system.web>
<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" >
Thanks to this answer, and this blog post by Scott Gu.
I have reached a point where my ambition has exceeded my ability implementing Dojo in a Zend Framework project using an XAMPP distribution for PHP & Mysql as my dev/test environment on a Windows 7 machine. I honestly don't know if this is an ID10T issue (me) or a system failure. Should this be a failing on my part I apologise in advance.
I'm trying to implement using the V1.7 version of Dojo while remaining on a production ready environment (hence avoiding the jump to ZF 2, etc). I'm aware from documentation that in Dojo V1.7 dojo.xd.js has been superceded by dojo.js. My problem lies in trying to use a CDN source for Dojo.
The dojo content of my page renders fine, but Firebug is showing an error "NetworkError: 404 Not Found - http://ajax.googleapis.com/ajax/libs/dojo/1.7/dojo/dojo.xd.js" & the page has the following embedded in the page head:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/dojo/1.7/dojo/dojo.xd.js"></script>
Tracing the source of the problem on my page indicates it is the 'echo $this->dojo;' statement that introduces the problem.
Changing the 'setCdnVersion(1.7)' to 'setCdnVersion(1.6)' in the bootstrap file resolves the problem, but I'd really like be using V1.7+.
Pasting the embedded URI into the address bar, indeed, returns a 404 page not found.
Dogpile has no references to this specific error, that I can see.
I can't find any bug reports that appear - to my limited knowledge - relevant on dojotoolkit.org
It looks like the Dojo config I have is not recognising the need to use the dojo.js for V1.7 (although I'm not sure where the problem actually lies). So, I must confess I'm at a loss how to resolve this problem other than casting myself upon the mercy of the collective SO expertise.
bootstrap.php:
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
...
protected function _initView ()
{
// Initialize view
$view = new Zend_View();
$view->setEncoding('UTF-8');
$view->headMeta()->appendName('Content-Type', 'text/html; charset=UTF-8');
// add dojo helper path to view
$view->addHelperPath('Zend/Dojo/View/Helper','Zend_Dojo_View_Helper');
// configure Dojo view helper, disabled...
$view->dojo()
->disable()
->setCdnVersion(1.7)
->setCdnBase(Zend_Dojo::CDN_BASE_GOOGLE)
->addStyleSheetModule('dijit.themes.tundra')
->setDjConfigOption('parseOnLoad', TRUE)
->setCdnDojoPath(Zend_Dojo::CDN_DOJO_PATH_GOOGLE)
->useCdn();
// Add it to the ViewRenderer
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
$viewRenderer->setView($view);
// Return it, so that it can be stored by the bootstrap
return $view;
}
}
In index.phtml:
<head>
<?php echo $this->headLink()->prependStylesheet($this->baseUrl() . '/assets/css/site.css'); ?>
<link rel="stylesheet" href="https://ajax.googleapis.com/ajax/libs/dojo/1.7/dijit/themes/tundra/tundra.css">
<link rel="stylesheet" href="https://ajax.googleapis.com/ajax/libs/dojo/1.7/dojox/grid/resources/Grid.css">
<link rel="stylesheet" href="https://ajax.googleapis.com/ajax/libs/dojo/1.7/dojox/grid/resources/tundraGrid.css">
<?php
// Dojo plug-in enablers ...
echo $this->dojo();
$this->dojo()->enable();
?>
Version information:
Xampp dist - V1.7.7 (Apache/2.2.21, PHP/5.3.8)
Zend Framework dist - V1.11.11
From the 1.7 release notes:
Please note that if you are upgrading from 1.6 or earlier, we no longer make a distinction between dojo.js and dojo.xd.js (all versions work cross-domain with the new loader), so update your URLs to refer to dojo.js.
so the Dojo helper is using the filename dojo.xd.js (the cross domain version), but in 1.7 it should be just dojo.js. Dojo 1.7 was released after the Dojo integration into ZF, so it's possible this is a bug in ZF itself.
The following types of tags in Lift do not seem to work for me:
<lift:snippet type="MyClass:render" />
<lift:MyClass.render/>
<lift:MyClass/>
Using these tags results in a Class Not Found error. If I attempt to call a class using
<div class=lift:myclass.mymethod />
it can work. Or if I call it using span tags. For instance, the Hello World example in Pollak's Simply Lift works for me, successfully displaying the Howdy method with the following code:
<span class="lift:helloWorld.howdy">
Welcome to your Lift app at <span id="time">Time goes here</span>
</span>
Currently, my problem is coming from attempting to implement Exploring Lift's (aka The Lift Book) OpenID example in Chapter 13.1. I have downloaded OpenID4Java using sbt as well as the lift-openid library. That example can be found at http://exploring.liftweb.net/master/index-13.html. I have implemented the change to the Boot class, and created the OpenID class and the SimpleOpenIDVendor class. But creating an html file containing
<lift:OpenID.form>
<openId:renderForm/>
</lift:OpenID.form>
causes the following error to be displayed in the browser:
Error processing snippet: openid.form
Reason: Class Not Found
XML causing this error:
<lift:openid.form xmlns="http://www.w3.org/1999/xhtml">
<openid:renderform>
</openid:renderform></lift:openid.form>
The class OpenID was placed in a package that starts with the package code, which is being implicitly found by Lift. It is included in the Boot.scala file with the line
LiftRules.addToPackages("code")
So, I am at a loss. Any ideas?
Note that other lift tags such as lift:bind-at and lift:surround and the like work fine.
As dave posted under my original comment, the problem was the HTML5 parser. Lift is case-sensitive, and cannot find a class with varying case. Since the HTML5 parser automatically makes tags lowercase, you can't use custom lift tags anymore. Instead, you have to use something like
<div class="Lift:MyClass.render"></div>
Note that you CANNOT have
<div class="Lift:MyClass.render" />
as HTML5 apparently does not support such tags.
My OpenID4Java problem is therefore resolved by using:
<div class="lift:OpenID.renderForm">
</div>
Why I don't need to use openid.form still is uncertain. It could be possible I'm implementing it slightly off, but I confirmed that it will take me to an openid login page if I put in the openid link, so it is indeed functional.
Sources:
http://groups.google.com/forum/#!topic/liftweb/H-xe1uRLW1c
https://groups.google.com/group/liftweb/browse_thread/thread/3948df1eee6ec271/ (thanks fmpwizard)