I'm in the middle of moving an EE 2.4 site to a new server. I pulled down the current site, moved it, and I noticed the tags in the page templates were no longer parsing. But, template parts (header, footer) parse correctly. I then set it up locally no my machine with MAMP to debug and found the same thing was happening there. Has anyone else ever run into this? I've seen some strange EE bugs before, but this one is new. You can see it at http://192.241.176.212/.
I have a hunch it's a permissions issue. Any ideas?
Related
all! I have a Joomla site (http://wired-ar.com) that I attempted an upgrade to 1.5.26 just a while ago. The upgrade went a bit awry, and I was forced to revert to a backup copy of the site using 1.5.15. Was upgrading with the intent to then upgrade to 2.x and then the latest.
I'm new to Joomla, but I believe I've reattached all the necessary components and modules. However, I'm getting 404 errors on EVERY page. Homepage, interior pages. I'm also having some problems with my editor, as only the top-portion of the editor appears and no TinyMCE. I've re-uploaded all editor files just to be safe, but no luck.
I haven't got a clue what's going on here, and I'm all out of leads. Most other problems like this involve the home page working, and nothing else. On my end, the back end works a-okay, and no visual pages are coming through. Changing different themes does not help, nor modifying any of the SEO areas, like mod_rewrite. Disabling plugins returns no results, either.
I would love some help with this, please! Any thoughts, options, or possibilities would be great.
Try to disable SEF url from backend, and figure out from the links, which articles/comp. are assigned to the menu. (maybe languages arent set correctly - you have assigned another lang article/category for ex. to an En lang menu)
As it turns out, and this may be the case with others, if you can access the back-end and nothing else, you likely have a corrupted file tree that's missing components or modules.
In my case, the really old files on this server had very wonky permissions, which made a smooth re-upload nearly impossible. The solution was to check and double check all components, adding the missing ones where needed. Took a lot of CHMOD work, too, for me.
Hope that helps someone, if you're in a similar pickle with an old Joomla site!
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 ;)
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.
I'm having a very bizarre issue. I have been building a website locally on my linux box and all was well until I uploaded the site files to a place where i have some hosted space. Everything renders exactly the same except one element in my footer which i think is affecting some jquery animation i am using. I thought maybe I was missing files or hadn't uploaded the latest versions of everything, so I deleted the server directory and re-uploaded everything exactly as is from my local copy. And yet, the problem remains. I'm not sure how this is happening. Has anyone seen this before, or does anyone have an idea what could cause this? I'm baffled! Thanks everyone!!! I am attaching screen shots.
Seems to be a cache problem. Try to force a refresh with F5 or CTRL+F5.
Try clear your cache in your browser settings.
If that don't work, use Firebug (an Firefox browser addon) to check actual css at your footer. This will show the problem.
BTW: don't use spaces in your URL if you can. Don't use spaces in your filenames/folders.
A couple sites of mine recently got "hacked". Someone was able to add a line of JavaScript to the bottom of every page on the site.
The server is a Windows Server 2003, and has Cold Fusion 8 and MySQL 5.x installed and running.
Looking into the code on each page shows that none of the pages were modified. The JavaScript is not in the code files themselves. This leads me to believe it is an IIS problem, but I am unsure and cannot find anything that would be able to do this within IIS.
The JavaScript being added redirects a user to another page only when they come from Google, or at least it appears to work this way.
Any help on how someone was able to accomplish this as well as removing it would be greatly appreciated.
Another way to word the question thanks to #Jeffrey Hantin
How do you systematically modify output from IIS without modifying individual pages?
EDIT: A bit more testing has shown that only the .cfm pages add the extra javascript. Added a new .cfm and the js was there but a .html did not have it.
Edit2: Turns out to have been a coldfusion problem after all. Somehow the pages OnRequestEnd.cfm were created on the sites and added that js.
Looks like someone exploited some latest Adobe CF vulnerabilities.
Please see these blog posts for details and try to search symptoms on your server:
Image upload
FCKEditor bug + this post
Hope this helps.
Turns out to have been a coldfusion problem after all. The page OnRequestEnd.cfm were created on the sites and added that js.
If you only want to use IIS to modify output, the ISAPI filter is probably the best answer. If you would like to use Coldfusion, you could utilize the application.cfc to modify output during certain parts of the request cycle or wrap all of your pages in a Custom Tag to consolidate the like portions of your page templates.
I have used both. In cases where my page headers and footers are all the same, the custom tag is fast and easy to use. To make changes to all the pages, you edit one custom tag file. In cases where I have a more complicated web application I'll use the application.cfc to store and insert common components where they are needed.
They might have guessed your password. You should change it immediately.
It's possible that an ISAPI filter is used to do this. I once used one myself to perform compression before IIS supported it natively.
In your specific situation, you may want to check for ISAPI filters you don't want installed. Of course, if your server has been compromised, you will likely be better off rebuilding from a known good image rather than trying to fix it in situ.