Would someone be able to test my website checkout in IE7? It is www.FoundersTelecom.com. Please add any item to your cart and try to check out. A military customer with super old browser just reported that the checkout screen formatting is all messed up and unusable. I am unable to test on that browser. Thank you so much!!
Denise
Best practices dictate that you shouldn't cater to users that are still running browsers that are no longer supported. Microsoft dropped support for IE7 a long time ago, and allowing users to use deprecated browsers will open you up to security issues.
That being said, check out IETester if you are a Windows user. It will emulate older versions of IE.
Related
Someone asked me to create a website for his sportsclub, I decided it try and make this webpage in ReactJs.
https://complexbjj-2a19b.firebaseapp.com/ this is the outcome, looks pretty and
works well on desktop.
It's pretty responsive layout wise.
So I was pretty happy untill I decided to build and deploy for production.
Sadly I found out that the webpage wasn't optimised for phones at all, leaving random blank spaces.
I tried allot of things, changing to PureComponents, Using React.memo.., etc etc.
Nothing seems to help, so now I'm here after hours & hours of trying to find a solution with my hands in my hair.
Does anyone know what could be causing this problem?
If you have the Google Chrome browser installed on your machine, you can try auditing your app in the inspector Audits tab (here is the doc). That could help you spot possible improvements.
We tried more time to find badges with android using codename one, but I found some comments in stackoverflow is only working on IOS and not working on android, if true so when will it become available on android?.
Thanks in advance
When we created the badge code Android didn't support that UI paradigm. Arguably it still doesn't but some vendors include that functionality with a special API.
Currently the main thing holding this back is that no one asked for it or implemented it. First of all I suggest filing an RFE which will give you a way to track the schedule for adding this. You can add an RFE on http://github.com/codenameone/CodenameOne/issues/
You can also just implement this yourself and submit a pull request as explained in this post: https://www.codenameone.com/blog/how-to-use-the-codename-one-sources.html
This should be relatively easy although you will need to be careful with using the right API level options and might need to use reflection to avoid SDK dependencies which we don't want.
Other than that it's just a matter of interest if we need to implement it. If you have an enterprise account then make sure to let us know through the account of your interest in this feature. We also take pro account requests more seriously when assigning a feature.
I am using DNN 7.4.1 Community Edition and I would like to have a specific security role ("Editors") to have the ability to edit the content of every module, but not be able to edit the settings of every module. I know this SO question addresses this, but the answers are quite outdated and I would like to see if there is any more recent knowledge related to this issue.
I believe DotNetNuke Professional edition is now called, EVOQ Content, and due to the specificity of my issue, I would rather not upgrade for one little piece of additional functionality (also might not be an option financially). However, upgrading would seem to allow me to have more freedom over permissions.
As far as Oliver Hine's Enhanced Permission Provider for DotNetNuke, it hasn't been updated for several years. I have installed this extension, however it seems to add more headaches. As soon as it is installed, entire pages are no longer visible for any users other than the administrator role. Even after adjusting page permissions to allow "All Users" to "View Page", all of the modules are still not visible. After fumbling around with individual module permissions, certain modules were visible for certain users only after ALL permissions were granted to that role. This extension would be perfect if it worked as described (and without setting tons of individual module permissions).
So, is there any method other than the ones mentioned above that allow me to prevent the "Editors" role from accessing module settings, but still allowing them to edit the module content?
Thank you kindly
There is a slightly newer version on github which you might have better luck with. I haven't had the time to fully test it but it's an improvement over what's on codeplex.
https://github.com/ohine/Dnn.Enhanced-Permissions-Provider
If you still run into issues, contact me on my website and I'll get things fixed up.
Unfortunately my answer on that other post still stands as the current solution. Though Oliver might show up here and provide some insight.
This can be achieved with DotNetNuke Professional (EVOQ) edition using the
extended granular permissions.
So I wired in Prettify.js and Prettify.css into my new Tumblr blog. It works out great in chrome, IE, and Firefox but I was astonished when I went to my Android Phone and suddenly the code inside ... looks like an atrocity.
I was about to go digging but figured before I spend hours trying to solve a problem someone else already fixed I would see if my ol' Stack Buddies have anything to say on the matter.
aquamoogle.tumblr.com
Any solutions will be greatly appreciated and if none are posted I'll likely toss up a solution by the end of the weekend.
Clarification EDIT This is viewing the post through the Tumblr Android application. I don't think it has anything to do with phone version but because someone is bound to ask it's a Motorola Droid Bionic running Android 2.3.4
Alrighty, since nobody came along with this one I'll throw the answer out there. The Tumblr application after decompiling it off the APK does not use a standard web frame. This means that javascript execution is not embedded in the view for the mobile application.
Sucks I know... Another possible solution would be to use straight CSS for formatting but alas this doesn't even work in the mobile version as the CSS sheets are overridden with mobile style sheets for more compact formatting.
So this one goes down as "unsolvable" due to the mobile application not operating within the same boundaries as the web driven blog does.
If someone does by chance have a solution to this that will work however, I would be interested in hearing it but at this time I don't have a valid solution. But, it's good to know.
I am working on my first DotNetNuke website and there is a requirement for all the custom module functionality I am developing to be available with JavaScript disabled.
However, when I create a module that contains a simple submit button, i.e.<input type="submit" />, DotNetNuke displays a critical error with JavaScript turned off but works as expected with JavaScript turned on.
When I attach to the running process using Visual Studio, the unhandled exception is thrown from admin/Skins/Nav.ascx.vb line 177. The inner exception message is "Invalid JSON primitive: ."
My research online only managed to turn up this forum post (Postbacks are not working when Javascript is disabled in the browser) that appears to be the same problem as mine, but no solution is provided.
Can anyone shed any light on this issue? Is it viable to be attempting to write non-JavaScript functionality in this version of DotNetNuke?
Update: it turns out that another website designed recently with Dot Net Nuke by the company I am working for is having the same problem with non-javascript postbacks when using DNN version 5.1.4 but it does not have the problem (i.e. it can postback without javascript) in DNN version 5.0.1.
So perhaps a hard dependency on javascript has been introduced at some point after version 5.0.1. We are investigating this possibility further and I will keep this question updated as we go. Obviously I still welcome anyone's input on the subject.
Update: i've started a thread on the Dot Net Nuke forums to see if I can get any help there. If any solutions come up I'll post them here. Trying to find official DNN stance on support for javascript disabled functionality
One of the developers in the office found a workaround to get postbacks working with javascript disabled. Unfortunately since he does not have a Stack Overflow account, I will try to translate his solution as best I can for those who are interested. Bottom line is postbacks with Javascript disabled is possible once you make a few changes to the Dot Net Nuke environment.
Step 1 - Change the menu module. In our case we used the Telerik RadMenu.
<dnn:NAV runat="server" id="dnnNAV" ProviderName="DNNMenuNavigationProvider" IndicateChildren="false" ControlOrientation="Horizontal" CSSControl="mainMenu" />
becomes
<dnn:RADMENU runat="server" id="dnnRADMENU" MaxLevel="2" EnablePageIcons="False" PagesToExclude="" ShowPath="True" />
Step 2 - Remove the actions and visibility modules.
<dnn:ACTIONS runat="server" id="dnnACTIONS" ProviderName="DNNMenuNavigationProvider" ExpandDepth="1" PopulateNodesFromClient="True" />
<dnn:VISIBILITY runat="server" id="dnnVISIBILITY" minicon="images/DNN-minus.gif" maxicon="images/DNN-plus.gif" />
Step 3 - Download the DNN source and make two changes in the LibraryUI\Utilities\ClientAPI.vb file.
Line 155:
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
becomes
If Not objButton.Page.IsPostBack Then
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
End If
Line 355:
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
becomes
If Not objPage.IsPostBack Then
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
End If
Step 4 - compile the Dot Net Nuke library.
Note: Also make sure you are not logged in as an admin or host, as the admin/host panel at the top of the page will also break if you attempt to postback with javascript disabled.
Hope this helps someone else. If you feel like I'm missing some important details, let me know and I'll try and fill in what's needed.
DotNetNuke relies heavily on JavaScript and I doubt there is a real easy way around it - at least considering you need to support all functionality. Perhaps you can clarify that?
The the bottom line here is that you're going to need to modify DotNetNuke to meet your needs. It certainly isn't impossible to get it working, but I would venture a guess that it just plain isn't worth it for most people.
If, as you said, you need to retain ALL functionality without using JavaScript, you're going to have a pretty substantial amount of work to do.
I'd suggest, to get started, you download the source package, set up a development environment on your local machine, turn off JavaScript in your browser and start taking notes. This will help to determine the level of effort involved.
I'm guessing you won't get a lot of responses out of this one (as the poster in the forum thread you linked to didn't) as very few people have sat down in front of DotNetNuke with this as a requirement.
Also, keep in mind that any time you're making substantial changes to the DotNetNuke framework, you're interfering with your ability to easily perform upgrades in the future. Just another thing to think about.
I believe that I've seen the leadership in DNN say that they've taken a hard dependency on JavaScript, and have no intention at this time of considering a non-JavaScript compatible scenario.
That being said, being able to do a simple postback shouldn't be too difficult to support. I would look around in the Client API area for the error that you're describing. A lot of the Client API code is in the DotNetNuke.WebUtility assembly, which is a separate download from CodePlex to get the source.