An application we're developing for a customer is running more or less fine on our internal development servers (V 8.5.3 with UP1 and FP5 as well as a secondary V 9). Our development is done using V 9 designer clients.
Yesterday we pushed a test version onto the customer's server (V 8.5.3 FP5 / UP1). The result rendered by their server however is completely different from what we get from our servers. It turns out that only custom style sheets are rendered while everything that usually should be coming from the server's webstandard theme is completely missing: no xsp.css, xsp_ie.css and the likes. Thus the pages are completely unusable: tabbed panels are rendered as standard elements, rich text editors are completely broken, just to name a few things.
We had the local admins check the server file system: webstandard theme appears to be there, and accessible to everyone.
Has anyone ever come across something like that? In 4 years of developing Xpages I've never seen something like that, at the moment I'm completely clueless in what to try next.
I really hope that this is just a minor flaw easy to be resolved.
Lothar
Have you checked the installation? I have seen servers that were upgraded the wrong way by copying the data directory, then upgrading and then moving back the data old directory, thus overwriting some important files or even loosing important files and directories...
This is hilarious: for security reasons the customer's admins deleted all files from the server's file system that they thought weren't needed. For some reasons they left the themes but removed all resources like css and js files (including all dojo dirs). No, I won't tell any names.
Lesson learned: never just assume a customer's setup to be fully functional until this fact is properly proved ;)
Related
Last week I tried to update my Notes client installation from 9.0.1 FP9 to FP10 IF 3. For technical reasons I had to roll back which proved to be quite difficult, and I ended up completely uninstalling Notes and doing a fresh installation of 9.0.1 (standard) then FP9 IF 2.
Everything's fine (and much more responsive than before, too) with one serious exception:
Within the client help popup window for Notes client and Domino Designer help is hardly usable now; obviously there's no CSS style or whatever applied to the nav page / frame:
As you can see in the screenshot styling of the main window part (green frame) is fine. But everything that is releated to navigation (red frames) appears to be raw html. Javascript calls are apparently working but it's really hard to navigate the "chapters". Same applies to Designer help, of course.
Here's what I tried to solve that riddle:
uninstalled and re-installed full client 3 times; sometimes I ran the
installation as local Admin other times I didn't (no difference)
just installed plain Notes 9.0.1 from scratch then tested Client help before updating to FP9IF2 (no difference)
restored the entire [Notes-Programm]\framework directory from a
backup I took when Notes help still was working as expected (no difference)
copied over the entire \Notes\ folder from a different PC where popup help is still working fine (no difference)
Problem with that is: being a Developer I need to have a functioning help window in my Domino Designer. The navigator as it is right now however is plain useless. And designer_help.nsf isn't of help at all when it comes to Java, LotusScript etc. objects and classes.
One of my co-workers has the same phenomenon while another one hasn't.
Question: did anyone else experience something like that? Where you able to solve it? How?
This seems to be related to an issue with the embedded browser windows that Domino Designer uses to open the Help website.
Try to open following link in a modern browser (such as Chrome or Firefox) and the navigation should be fine.
http://localhost:50970/help/index.jsp?topic=%2Fcom.ibm.notes.help.doc%2Ffram_getting_started_c.html
Bookmark it and use it when you need it.
Try using the IBM Nice tool to see if it can fix your issue
https://www-01.ibm.com/support/docview.wss?uid=swg21459714
Meanwhile I restored my entire Windows system partition from a backup created just before all that began (lucky me that I have both regular local backups plus a separate system partition). And that finally helped resolve the problem.
Meanwhile I'm 99% sure that this is due to a rather new registry and/or firewall setting not yet known to IBM's NICE tool.
Greeting, brethren,
So I inherited this app (yes, XPages can be legacy now ;-). It is meant for the Notes client only and one process takes a convoluted route via what I understand is called a Managed Bean (the Code/Java design element).
The database resides on a server.
When editing said bean.java, I meet two issues.
If I test immediately thereafter, I'm greeted with an Error 500 that won't go away unless I close then restart both Notes and Designer
In some cases, changes made to bean.java are not immediately available. So far I haven't been able to characterize those cases. For example, yesterday afternoon I could no anything, nothing would bring a change to the Notes client. (Yes, I cleaned & rebuilt and autobuild is disabled). This morning changes are apparent immediatly (save for the quit/relauch bore).
I've tried to set xsp.application.forcefullrefresh=true in the app's Xsp properties but haven't noticed much effect.
What am I doing wrong ? What could I do to fluidify the modifying of a bean ?
When working in XPiNC, after every change you have to close and restart designer. If I understand things correctly, it's trying to access class files that have been discarded. That's why whenever I've had to develop for XPiNC, my initial testing during development is on a browser, I would recommend this approach.
There are minimal differences in syntax, usually only encountered if manually creating URLs to files etc or using the bad practice "" to specify database location in #DbLookup. Wherever possible, avoid #Formula approaches, their performance is worse than object orientated methods (e.g. view.getAllEntriesByKey())
It's the same for the bean. There are only two ways to speed up picking up updates - use a browser or use XPiNC on a different PC.
I'm making a webpage in Drupal 6.26, and I blocked in a strange thing. I develop both in Localhost, and online, and the strange is that some how in online the primary links are empty (but there's element on it I can see in /admin/build/menu-customize/primary-links also in this page the menu elements appeared in the place, but in the other pages they don't), but in Localhost everything is ok, and i checked all of the settings and they are the same, the theme files are the same to,(and i didn't change anything in the other drupal files), the only difference is that the online page is set in offline (because the under maintenance), and I tried it to make it online, but the problem is still there, so I don't really have any idea.
That might be a theme problem. Make sure your local configuration has the same active theme as the installation on the public server. Try switching to a default theme that comes with Drupal.
Another cause might be one of your modules. Try disabling all but the system modules and then start re-enabling them one-by-one to see which one changes your menu.
am I just stupid or does Drupal have a big flaw? (probablt the former of the two..)
I have built a site with some public content and some private content. The problem is that even though menus can be hidden from public, unauthorized users, there is no stopping a visitor from just typing in node/5 (if node/5 were one of the private, hidden pages).
And I am baffled by how troublesome this is to fix. there is no basic functionality to fix this, and having tried two modules simple_access and access_control none of them work! Currently trying to fix a drupal 6 site. Any suggestions on modules that might fix this VERY BASIC functionality? Is Drupal not meant to handle corporate pages where you have external pages and internal sensitive content?
By the way, Drupal 7 is in the .9 stage, there are still VERY limited module availability, mostly everything is in an alpha stage and has been like forever, is there no development being done for D7?
The module that'll fix the problem for you is Nodeaccess; this is the opening text from the module page:
Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role.
So that will do exactly what you want. Also the way Drupal's access system works means that any menu link that points to a node to which the user does not have access, will not be shown for that user. So you won't even have to hide your menu items any more, Drupal will do it for you :)
Regarding Drupal 7 contributed modules, the 'major' modules (Views, CTools, Devel, etc.) are all coming along nicely and are stable, in RC or at least beta. Because Drupal is open source the sole maintainers of smaller modules may not have the time to devote to bringing the Drupal 7 version alongside maintaining the v6 module (a lot of people still use D6 and there are still issues to attend to there).
Personally I've developed quite a number of D7 sites now and have found the contributed modules to be available and of a good quality (for the most part). I guess it just depends what specific functionality you need at the end of the day.
I think there's just a gap between your expectation and how Drupal actually works.
Drupal doesn't limit access to content based on whether or not that content is in the menu. On a site with thousands of nodes it would be overwhelming to have a menu of thousands of items.
Drupal has a rich node access system and there are dozens of modules which can help solve this problem. See the list of content access control modules for ideas on which you might use.
When I run into specific problems with modules I tend to follow a few steps:
re-read the README.txt file and INSTALL.txt file
re-read the project page to see if it links to any further documentation
read the issues for the project to see if any of them have similar descriptions of problems (click on the number links in the right sidebar of the project page)
create a new test site where the only thing I install is the module in question and then walk through the steps I think I should, documenting them in a new issue in the project issue queue as a "support request", and then ending the post with "expected results" and "actual results" - maintainers will usually get back in a few days time
nodeaccess module (http://drupal.org/project/nodeaccess) should work perfectly for you.
Before I start pulling my hair out on any "known issues", is there any quirks or problems that I should be aware of.
Specifically with cookies, JavaScript, HTML, CSS and images.
PS I have a copy of the docs provided by RIM, but I'm hoping others know of some lesser known issues.
Here are a few that I've noticed:
For some reason, the BB browser doesn't seem to handle underscores in the hostname correctly. I don't remember what happened, but if you hostname is like this: http://some_host/blah, I remember it having problems.
This can be corrected with a DNS entry that removes the _
Another thing we've seen is serving up .jad files for Java downloads. If your module contains _ or other special characters, the BB browser displays a HTTP 500 error when trying to fetch the .jar or parse the .jad. This is especially annoying because it's not actually an HTTP error, the server is serving up a file, but the BB browser just can't parse it, so it blames the server.
We fixed this by using Fiddler to hit the .jad URL and view the contents of the HTTP response. If your .jad has any special characters (or sometimes URL/HTTP encoded strings) you might need to simplify your module name to only use A-Za-z0-9
I know those aren't exactly html/css things, but thought I'd post this anyway!
I had used the blackberry browsers on emulator versions to test my web pages.
These are some i would like to point out.
Please forgive me in case of any deviation with a real case because these are specific to emulator versions on windows 7 OS. I dint have the devices to check and verify.
When we are coming down to a BB OS version below 5.X (eg. BB 9630), the browsers support for java script will be turned off by default. So you need to go browser options turn on it manually.
When we go further down to BB OS version 4.2, the style sheet support will be turned off by default. Causing your webpages to render without applying style sheet. So that time you need both the java script and style sheet supports to be turned on manually.
Even when i was on a OS version 7.X or 6.X, the internet connection was working and i could connect to pages. When i went down to version 5, those emulator browsers shown issues for connection. On googling i found that MDS is a requirement when we go down the versions and seek internet access.
I installed MDS, still it was not working for versions below 6, reason being the JAVA_HOME environment variable was not set in my advanced system settings in my-computer properties. But it was not even pointing out the issue and the MDS was closing instantly.
So after setting my JAVA_HOME to "C:\Program Files (x86)\Java\jre1.6.0_07" the place i installed JDK(we need JDK for MDS), internet connection started working.
Also if you are using g zip compression for your pages, below Blackberry OS version 6, the browsers no longer requests for a compressed one. (found it on OS version 5 emulators BB 9700,BB 8520).
Also when you are going to use a css property or html entity that you doubt support, be sure to go to the corresponding OS version content developer guide and find from which version are they providing the full support and partial support.
Check out the BlackBerry Browser Version 4.2 Content Developer Guide. It is for the older 4.2 browser but still has lots of good info about what HTML, CSS, and javascript is supported.
My experience with BB 8700 is that you should not use JavaScript, neither depend on CSS to be rendered correctly. It also has no flash player by default so you're off to plain server-side HTML form processing/ASP/CGI. Also beware of size, as internet can get pretty slow while on the road.
One known issue is that the Blackberry browser completely ignores the css display property, so you can't use display:none to hide content.
We've also had trouble with basic form submittal - sometimes, the POST doesn't happen at all, other times it happens but some or all of the form fields go AWOL. We haven't been able to get to the bottom of this issue, but it seems to occur mostly with the BB Curve series.