Unable to Edit Article After System Plugin Install - plugins

I have developed a front-end system plugin for Joomla 3.0 which replaces keywords for HTML formatted objects. This works perfectly in my local lab environment but when installed on the hosted site (WHM/cPanel) it causes issues with the administration area and prevents the administrators from editing the articles.
When the administrator clicks on a article to edit the page attempts to load then appears to go back to the same page. I have developed this as a front-end plugin only so I shouldn't affect the administration area.
The problem is also preventing admin from creating anything new (news, blogs, content, menu items etc.)
As this does not happen within my lab I can only assume the issue is with some server settings which I may need to enable/disable. I have complete administrative access to both WHM, cPanel and Joomla so can change settings where ever needed...
Things I have observed:
The article URL changes from:
/administrator/index.php?option=com_content&view=article&layout=edit&id=7
to:
/administrator/index.php?option=com_content&view=article&layout=edit&id=7
when the plugin is enabled. Notice the ampersand has changed to amp;. This makes me think it could be something to do with UTF-8 character encoding has been set in MySQL to utf8general_ci.
Any pointers on configurations I may need to change would be greatly received.
Question: How do I prevent this from occurring (without removing my essential plugin).

If you create System Plugin that should work only on front-end you have to check in your plugin if current page is front-end. You can do it using this function: JFactory::getApplication()->isSite() or JFactory::getApplication()->isAdmin()
Example usage (I assume you use onAfterRender event):
function onAfterRender() {
// Exit if current page is from Administration panel
if( JFactory::getApplication()->isAdmin() ) return;
/* your plugin main code goes here*/
}
It will prevent your plugin from modifying administration panel output. If you already done it and it does check like it should to, there is no way that reason of your problems is that plugin.

Related

Disabled touch-ui but unable to find sidekick when i switched to classic-ui

Is there any way that i can do it for whole site?
For individual user instance, Go to user account settings > Preferences > Author mode, select classicUI
more info here: https://docs.adobe.com/docs/en/aem/6-3/author/author-environment/user-properties.html#Account Settings
Alternatively, to have all users of an AEM instance use the Classic UI by default, start off by going to the AEM Web Console Configuration (/system/console/configMgr). Make sure you’re signed in as an admin and do a find for “WCM Authoring UI Mode Service.” If the service is not visible, click on the OSGi button at the top followed by Configuration, and then do another find. Click on “WCM Authoring UI Mode Service” and change the “Default authoring UI mode” to “CLASSIC” (or back again to “TOUCH,” depending on what you want to do). You must enter “CLASSIC” or “TOUCH” in uppercase letters or an error message will show up when opening a site. Changing this setting will make the chosen UI the default for all sites of the AEM instance. When opening a site with /siteadmin, or /sites.html/content, the site should now open using the Classic UI. This should be the case for all users.

IBM Worklight 6.0.0.1 - Rich Page Editor blocks

Problem - As the project was growing from some point on I cannot use anymore Worklight's Rich Page Editor. It looks as on the picture.
Configuration:
Eclipse Juno EE
Worklight 6.0.0.1
Project details - All pages are packed in the same HTML file. At the moment HTML file contains 6-7 pages in about 1100 lines. Compiling and all the rest works.
There should be no problems at all with that page size or number of views, so the appearance is likely tied to recent changes in the application logic itself. In your screenshot the editor has already finished loading the page into the embedded browser (otherwise you would still see a "Loading..." message in the editor's toolbar). The circular icon in the middle does not come from the editor itself but from something in that page or an associated script. In fact it looks a bit like a jQuery Mobile loading indicator to me.
One thing that may be happening here is something in the application's startup code has been added to call out to server-side logic (ex. a Worklight adapter call). Within the editor, the full preview server is not available so generally only the browser-side resources of an application will be functional. This allows you to use the editor for UI design work and then once you start hooking up to server-side features, previewing of the app would typically switch over to the Mobile Browser Simulator (Run As->Preview) or even native browser testing.
The best recommendation is to look for something in your app initialization process that's expecting data back and put in some temporary development-time mockups for such data. As an example, instead of making a service call to retrieve some JSON data just point to a test .json file in your project instead.
Could be related to this: Worklight Studio Rich Page Editor fails of WL.* call in page load
The short answer is that if you put just about any WL.* calls (even WL.Logger.*) in a page loading handler, it causes the Rich Page Editor to lock up.
If the problem is that you are calling backend resources that aren't available, then the normal timeouts and error handling in your code should keep the editor from locking up. You do have timeouts and error handling in your code, right? ;-)
If this problem can't be debugged easily, weinre (http://people.apache.org/~pmuellr/weinre/docs/latest/) works in the Rich Page Editor. You can see what is in the JavaScript console and if there are any exceptions thrown when it locks up.

SilverStripe CMS times-out when changing pages in the CMS

I have installed SilverStripe on several servers successfully in the past (but I'm not a SilverStripe expert). This time my SS install fails to work and I'm at a loss how to fix it.
The Problem
SilverStripe 2.4.6 installed correctly on the server (AFAIK).
The front-end works as expected. (Show default theme. Pages all load correctly.)
I am able to log into the CMS admin section succesfully. The CMS loads but when changing site pages in the CMS using the browser pane on the left, the CMS shows the circular loading symbol. The new page load never completes.
Using the console of Firebug in Firefox - When attempting to change pages in the CMS (by clicking on the page browser pane) the CMS tries to load two pages. The second page request 404s.
The first GET request is from the initial page loads.
The following POST+GET requests fire when clicking on the page tree to change pages.
Attempting to Find the Solution
I've tried deleting and re-installing silverstripe twice. (2.4.7 and 2.4.6) Both times the problem recurs.
A strange thing is that this server is already running two other silverstripe sites (both of which I installed without a hitch). All three websites are accessed via different domains. I tried accessing this install via another domain thinking there might be something wrong with how this third domain is configured but that didn't help either.
What should I try now? I'm stumped.
Thanks in advance.
Responses to Comments
Check your root .htaccess file. Make sure RewriteBase is set to /
Checked. Full .htaccess on PasteBin
Indeed the javascrip URL is strange. Check if there is anything unusual about what's being returned from the previous POST request. Is the site running in dev, test or live mode?
I can't see anything unusual in the POST request.
Clue Found: The site is running in DEV mode. Switching to LIVE mode and the problem disappears. Also the second GET request only shows up in DEV mode.
Example Post request with response.
Example Get request with respones.
This is a work around more than a fix but if you'd rather be coding than bug hunting it might be worth a go! (remember to log out of SS before doing this fix)
In your mysite/_config.php file change
Director::set_environment_type("dev");
to
if(!isset($_GET['isDev']))
Director::set_environment_type("dev");
else
Director::set_environment_type("live");
Then you can develop the website in dev mode normally and to use the admin in live mode and avoid the bug you just go to: http://{your_domain}/admin?isDev=0
N.B. might find a proper answer when pastebin.com isn't overloaded and I can see your responses!

Issue with publishing a new page in CQ5

I have installed both author and publish instances of CQ5.5 on my PC. But when I add a new page and publish it, it does not appear in the publish instance. Only a blank page is rendered.
I have tried activating it both from the siteadmin and from the Replication page in Tools. Only the navigation item appears in the Publish instance.
I checked the Request logs also. But it only gives a
200 response(OK)
Can someone please help me on this ?
You need to activate/replicate your /apps/site folder where all of your templates and components are located to push it from your author instance to your publish instance. Activating a page doesn't automatically activate the components and templates it uses.
Go to:
http://localhost:4502/etc/replication/treeactivation.html
Browse to or type /apps/[your site] in the path field
Set the check boxes to fit what you want to activate (Unchecking all will make everything under the selected path activate)
Click 'Dry Run' to see what will get activated without actually activating. (This is more of an informative step to help ensure you don't activate something not intended in a production setting)
Click 'Activate' to activate.
You can then check your publish instance to see your templates and code are there.
It is easy to miss activating your apps folder as there is no ui like the website admin for pages where you can activate.
Activating a page/folder/asset does not activate sub-pages/folders/assets. This can cause confusion especially when working with folders.
Generally if you need to activate a tree the best way is to use the tree activation utility
The only time I've ever seen this is when the code is not installed. That would be the first thing that I'd check. Go to (assuming you have your publisher on port 4503)
http://localhost:4503/crx/de
You should have your the code in /apps and you should be able to find the content page in /content too.
The reason this happens is that the sling:resourceType property points to a component that doesn't exist so it uses the default which is an empty output.
You have to build the code to both the environments (author as well as publish). This way both the environments will have the same copy of source code installed in the form of cq5 packages and felix bundles. Then if you create a new page or drop any component on any existing page, it will appear the same on publish environment after activating the same either through 'Activate Page' link in sidekick or through replication tree activation page.

Detecting what &gwt.codesvr should be set to in non-gwt pages in a GWT/servlet app?

We have an application that is built exclusively in dev mode using the embedded jetty server that comes with GWT. We also host on jetty.
There are a number of pages we use for development only to do things like simulate SSO requests, view emails that were sent through the system, and check what files are uploaded.
When we try to link from these pages into a GWT page the problem becomes that &gwt.codesvr=192.168.0.101:9997 is not included in the URL and we get the error message "GWT module 'YourApp' may need to be (re)compiled". Obviously I can paste in "&gwt.codesvr=192.168.0.101:9997" manually but is very annoying. Does anybody know of a way to detect you are in the embedded Jetty dev mode server and auto generate links to have the correct "&gwt.codesvr=192.168.0.101:9997" added on?
Try this solution: https://stackoverflow.com/a/9122167/970308
I've updated this bookmarklet. It isn't perfect, but makes it quick while developing.
I suggest you create a Filter which will simply redirect you to an address with &gwt.codesvr=192.168.0.101:9997 as soon as you navigate to the one of the "development pages". If codesvr parameter is specific for each developer, each developer will have to set it in some cookie and filter will simply take this value from cookie.