First run of the brand spanking new Intellij 13 – and I get createComponent() returns null for: class com.intellij.execution.RunManager – it turns out to be an issue with plugins, so remove your .IdeaIC13\config\plugins directory and restart you’ll be good to go (sans plugins) – no more createComponent() returns null for: class com.intellij.execution.RunManager issues on Intellij 13!
Visual Studio has come a long way since I used it last, and the Git integration is a powerful new addition. While the interface is a bit tricky to navigate, Linux command line makes you think in keywords not mouse clicks, overall it’s a great new feature that introduces an amazing source control system to the VS range. I’ve muddled my way through it for a while until this evening when out of the blue I received an error:
“The origin remote is set to fetch tags only (tagopt = –tags). This may be due to a bug in a previous version of Visual Studio Tools for Git. Fix my configuration or don’t prompt again.”
Clicking “fix my configuration” did nothing and there was no solution to be found. So going back to Git basics I took a look at the git config file – this will be in:
/.git/ folder (in your solution root folder)
and in the “config” (no extension) file.
Make a backup of the file (after closing VS) and scan down the file for:
tagopt = –tags
Remove this line (and this line only)
Restart VS and try again – you should nolonger receive “The origin remote is set to fetch tags only (tagopt = –tags). ” and your commits/pulls/merges should work just fine.
There’s no visual editor in Visual Studio Tools for the config file that I can see (please add a comment if this isn’t true) – so going back to core Git config is the way to go.
If there’s a better more VS way to resolve the The origin remote is set to fetch tags only (tagopt = –tags). Please comment below!
For some reason wp_redirect/wp_safe_redirect in WordPress can be a total pain, whether it be when writing custom front end code, plugins or widgets I seem to come across an issue with redirects periodically, with the utterly frustrating “Cannot modify header information – headers already sent” error. As a heads up, this is caused as the name suggests by content in a header being pushed down before the redirect is called, this is a generic issue not one that is specific to WordPress. More often than not it is simple to identify, if any of the involved PHP files have leading or trailing white space, and or there’s some hidden debug output you have forgotten. Occasionally the issue is WordPress however, in my case the issue of wp_redirect not working on a custom admin page, was caused by a function in
/wp-admin/includes/template.php:1636 or so, whereby headers/html, quite a lot of them are indeed sent as part of the page load process.
Having ensured all of my files were trimmed and there was nothing wrong with my plugin code, I discovered here that there’s a little workaround for forms being called in custom admin pages, that is simply to append:
To your action, e.g.
<form method=”POST” action=”?page=your-plugin-page&noheader=true”>
This resolved my problem instantly – understandably given it suppressed the content being produced in template.php!
Hope it helps anyone having problems with wp_redirect and wp_safe_redirect on custom admin pages in WordPress.
Aptana for Eclipse is brilliant, an amazing plugin, that for the most part really gives a productivity boost. Something that I’ve never quite understood however is why they keep messing with their FTP integration. I’ll be honest this was one of the main reasons I started using it instead of the older eclipse PHP tools. For some reason though whenever I do an update it seems to work slightly differently – either location in the context menu, or what can be uploaded from where or whatever. So in the latest version it’s known as “deployment” – ok that makes sense, but it’s also broken. For ages I was living with “Opening file for write failed” errors, just switching to Filezilla when I needed to do FTP, this however is such a pain and really slows you down when you’re making small regular changes to test or whatever. After yet another “Opening file for write failed”, I decided to sort it out, I found a few references to it, none of which really helped, so I resorted to the age old process of just trying different settings until I found one that worked. Form me, the resolution of the Eclipse Aptana Studio 3 – FTP “Opening file for write failed” error was just to change to SFTP rather than non SFTP. Nothing exciting in this, but worth noting simply because a number of references I found suggested the opposite also worked. So the tip, if you’re getting “Opening file for write failed” in Aptana FTP, is just experiment with variations in your SFTP settings, one of them should work!
I’ve just spent tow frustrating hours going around the houses, trying to work out how to link my brand new Facebook I-frame app to my fan page. I’ve done this successfully before, but it was a while ago so this is a note to self. I’m constantly amazed at how despite such comprehensive documentation it can be so difficult to find things that are so fundamental to how a Facebook app works. So, in case it helps, to link a Facebook app to a fan page (other than the page you create for the app) you need to use this url:
Obviously replacing the capitalised details. The app ID is easy – found here in your app settings, the url as far as I can tell can be anything, just cut and paste your app url here and it will redirect you to it afterwards. When linking your Facebook app to the fan page, the link above will allow you to select which page you want to link to, submit this.
From here, go to your fan page > edit page > apps (in the left nav) and the new app should be listed, from which point you can choose to “link to this tab” and it will appear in your menu on the left.
The information for this was sourced from https://developers.facebook.com/docs/appsonfacebook/pagetabs/ hopefully it will help you with how to link a Facebook app to a fan page.
WordPress is fantastic, what else can you say. The new custom post types and taxonomies make it a super powerful system that can handle the vast majority of average web content management requirements simply and quickly. It does have its quirks to be sure, and one of them is the tendency for it to screw up it’s permalink cache at times producing random 404 errors on pages that were working to that point. This often happens when you change slug values in your functions.php but it can certainly happen at other times. If this happens the quickest way to sort it (normally) is to reset your permalink structure to the default then reapply any custom paths you have defined. Volia, old pages back on track, no more random 404s on WordPress.
I’ve spent the last couple of nights working through Centos rebuilds, solr installations, and hook_blocks that just weren’t working the way I wanted them too, so this morning on booting up my newly restored system on encountering “Call to undefined function zen_menu_item_link()” I was just about ready to punch something!
After ranting a bit and the only references online to Call to undefined function zen_menu_item_link() being the error itself on unmaintained sites I took deep breaths and went through my “broken drupal” checklist. Fortunately on this occasion the problem was fixed by flushing out all the cached variables. In SQL paste the following:
update system s
set s.status=0, s.throttle=0, s.bootstrap=0
where filename = ‘modules/update/update.module’;
And the drupal issue Call to undefined function zen_menu_item_link() should be no longer!
Just one of the various niggles in the SQL Server Management Studio 2008, if by mistake you set up a user and fail to uncheck the “enforce password policy” box (you may have good reason for this, but if you’re on a dev machine as I was it’s a bit of overkill I think), you may encounter access problems when accessing the system from for example a scripting language like Coldfusion or PHP. In the case of Coldfusion the error looks like:
[Macromedia][SQLServer JDBC Driver][SQLServer]Login failed for user ‘cf_user’. Reason: The password of the account must be changed.
At this point it’s reasonably obvious that you must go in and change the user properties under Security > Users in SSMS. However, havign created the user when one tries to remove this check box you will encounter (always I think)
The CHECK_POLICY and CHECK_EXPIRATION options cannot be turned OFF when MUST_CHANGE is ON.
This is a bug in the software, and while it is possible to actually change the password programatically thus:
ALTER LOGIN [somelogin] WITH PASSWORD = ‘samepassword’
ALTER LOGIN [somelogin] WITH
CHECK_POLICY = OFF,
CHECK_EXPIRATION = OFF;
If you want to just reset this policy the easiest way is to just delete the user and then create it again making sure to leave the enforce password policy unchecked first time around. There will be no problem saving it initially thus.
OK if you’ve installed Apache on Windows of any flavour you’re used to the occasional weird thing happening and preventing it from working, one of the most annoying is the ubiquitous “Cannot open logs” error in the System event log. This invariably means that something is listening on Port 80. To prove this for yourself you can go to your run command and enter:
netstat -o -n -a | findstr 0.0:80
The last number here is the process ID using it. This is most often IIS or other web relates service and is easy to resolve, but every so often (very often it would seem looking around on google) it appears to be PID 4 – which according to the Windows Task Manager is the NT Kernel and System. Not very helpful given killing this will result in a blue screen of death. Anyway tonight after much fiddling around I discovered that the thing that was hogging port 80 was nothing to do with IIS or web anything, it was SQL server reporting services. I turned off anything that resembled a SQL server services and voila Apache started again, no need for a reboot which had hitherto been my only solution. So problems with PID 4 listening to port 80? Check your SQL services and turn them off!
Addendum to PID 4 listening to port 8 – Apache cannot start
Thanks to Tauseef below who has also mentioned that “A new service called “Web Deployment Agent Service” (MsDepSvc) can also trigger “System” with PID=4 to listen on port 80.”
Bharat below (thanks Bharat) has also contributed “Web Deployment Agent service was triggering “System” with Port id= 4 to use Port 80. I disabled it in Services, changed back to Port 80 in Apache config and bingo, Apache started working on its default port. Then I uninstalled Microsoft Web Deploy 2.0 to permanently remove this problem.”
Sanoop says (Thanks!) – ‘For me the service “branch cache” had hold of port 80.’