Linux Mint – Min, Max, & Close Buttons Disappeared

Recently I installed LinCity, a sim-city clone, on Linux Mint. It didn’t run, so I uninstalled it.  After uninstalling the package, my minimize, maximize, and close buttons disappeared on all my windows.  It wasn’t just that. My mouse cursor became a big “X” and right-click stopped working!

I knew some setting had changed during the uninstall but I wasn’t sure what it was.  A quick Google search showed results from 2012 which didn’t seem to apply to my version of Linux Mint. I tried them anyway with no success. Another poster said they had luck re-installing some of the core packages.  I tried re-installing all of the GNOME and Cinnamon packages that were already installed. That did nothing.

Eventually under “Preferences” I found the “Desktop Settings” application.  In that app, under “Windows” I discovered that my Windows Manager setting was blank.  I set it to “Metacity” and bam! everything started working again.  I tried switching to Compiz, but then all my buttons disappeared again.  Luckily there’s a “Reset Compiz Setttings” button on the same screen. After pressing that my desktop was back to normal.

Not sure why this happened, but hopefully this post helps someone else!

Advertisements

Symfony 4 get all POST data

“How do get all the submitted form data?” When I was learning Symfony this was something I couldn’t find a noob-level answer to. All the tutorials want to introduce you to the Symfony form module right away. But if you’re like me and want to understand how things fit together before using some overly complicated object to build a simple form then the below information may be useful.

How to get all values from a form submit in Symfony 4.

/**
* @Route("/", name="form_submit",methods={"POST"})
*/
public function my_form_action(Request $request)
$everything = $request->request->all();

Best practices – a poem

I.T. took away my remote server access today
Now I can only code local-ly
Though I don’t blame them, I’d just like to say
If my code hygiene needs washing
These bugs that I’m squashing
Weren’t found in Q.A.

‘Best practice’ was my first and my middle name
I agiled my scrums, I sprinted my days
Test-driven delivered a build to throw away
But the users don’t understand it
And they simply demanded it
Be fixed right away

Pear's mail_mine not working with Outlook

In a WordPress plugin I am developing, I am using Pear’s mail_mime to generate an HTML email and send it with an attachment. This worked fine for me during testing with my gmail account. However once I started using the plugin to send emails to others, Outlook users were getting a garbled mess. Outlook could not properly understand the generated multipart/mixed message and was showing the raw text. It took a bit of digging to discover the solution, but the root of the issue goes back to an age-old C.S. problem.

Windows uses ‘rn’ to define a line break, while Unix-like systems use ‘n’ to define a line break. Gmail doesn’t care which kind of line break you use, but Outlook requires line breaks to be in the ‘rn’ format.

Mail_mime allows you to pass the default for line breaks as a constructor argument. However, this didn’t work correctly for me. The Mail_mime code uses the End-Of-Line constant (PHP_EOL) and passing the EOL value in was not enough to change the value in all places.

What I had to do to finally get Outlook emails to display correctly was to first define the PHP_EOL constant and then pass it in as well.

// define the PHP_EOL constant
if (!defined('PHP_EOL')) define ('PHP_EOL',"rn");
// pass in the value on create
$mime = new Mail_mime(PHP_EOL);

I had to define the constant AND pass in the value to catch all the places the linebreak characters were used. This seems like a bug in Mail_mime.

I used the comments on this bug report to solve this issue. Unfortunately since this work-around was discovered, the maintainers don’t seem willing to fix this issue.

Apache RewriteRule for Changing Your Permalink Settings

I recently updated my blog’s permalink settings and did away with the year and month in the url structure. I’m experimenting with placing the post name more prominently in the url as it is better for SEO.
Here’s the Apache rewrite rule I used to move my blog posts from /yyyy/mm/post-name to /post-name. The rewrite rule uses a 301 redirect so this should not negatively affect the post’s Google rankings.

# Redirect moved blog posts
RewriteBase /blog/
RewriteRule ^20[0-1][0-9]/[0-9][0-9]/(.*) $1 [R=301,L]

Breaking the RegEx apart:

RewriteBase /blog/
This tells the rewrite engine that we are only going to look at URLs that are under the /blog/ directory

^20[0-1][0-9]/
Since we indicated our RewriteBase is “/blog/” on the previous line, “/blog/” will be chopped off of the URLs;
“^” says that our string should now start with the following pattern
I started this blog in 2009, so I only need to target years after 2000. I started my year RegEx with “20” to simplify.
“[0-1]” indicates I’m looking for a number range between zero and one. Since I only need to target between 2009-2013 the next digit could only be a zero or 1.
“[0-9]” indicates that the last digit in the year could be any of these.
“/” the next character should be a forward slash

[0-9][0-9]/
This RegEx targets the months: any digit zero through nine, followed by any digit zero through nine
“/” the next character should be a forward slash

(.*)
The rest of the url is our post-name. “(.*)” says take the rest of the url string and remember it as the first variable.

 $1 [R=301,L]
“$1” is the first variable that we got from the (.*) statement above. “R=301” says to 301 redirect this request to whatever url is in the $1 variable. It knows to prepend ‘/blog/’ to the request because we indicated our URLs should start with “/blog/” using the RewriteBase command. “L” indicates that this should be the Last rewrite rule it processes.

Regex can be confusing. Its is often easiest to build up your RegEx bit by bit until you have the completed statement.

WEB-INFcftagsMETA-INFtaglib.cftld (The system cannot find the path specified)

Recently I moved a long running process inside a cfthread and began to get this error during testing: “WEB-INFcftagsMETA-INFtaglib.cftld (The system cannot find the path specified)”

The issue is that getPageContext().getServletContext().getRealPath(“/WEB-INF”) returns the incorrect path when inside a cfthread.

If you use cfthread you may eventually run into this bug, but maybe not as I think its a very rare bug. There doesn’t seem to be a fix for this issue, at least not in CF9, but I did find a workaround.

A demonstration of the bug

The results:

C:ColdFusion9wwwrootWEB-INF
C:wwwrootWEB-INF

Inside the cfthread Coldfusion has forgotten where /WEB-INF is!

In my case I had:

in the code inside the cfthread.
“New Query()” corresponds with the custom tag C:ColdFusion9CustomTagscomadobecoldfusionquery.cfc.
Query.cfc extends C:ColdFusion9CustomTagscomadobecoldfusionbase.cfc.

To create this object Coldfusion calls “getSupportedTagAttributes” in base.cfc which looks up the attributes in taglib.cftld. That file is located under the /WEB-INF directory. If we dig into the guts of base.cfc we find the offending code is on line 228. Coldfusion tries to find “/WEB-INF/cftags/META-INF/taglib.cftld” but since we are inside a cfthread the code fails to use the correct path.

Creating a mapping didn’t help and neither did creating a virtual directory in Apache.

The workaround

Code similar to this was working fine in the production environment, but how was it avoiding this error? The solution was found when I stepped back and read the entire function. Wrapping the offending line is the code:

if(not isdefined("server.coldfusion.serviceTagAttributes.#tagName#"))

Coldfusion will look up the attributes only if they are not already cached in server memory. This is why this bug is hardly seen: normally all these attributes have been cached before being encountered inside a cfthread. My testing was very specific and so the Query attributes were never loaded prior to entering the cfthread. The trick is to make sure the attributes are cached before entering the cfthread.

For testing I added the line:

before entering the cfthread and that forced the attributes to be cached and the error went away.

I hope this post helps someone else with this issue!

The method matches was not found in component:Ensure that the method is defined, and that it is spelled correctly.

I recently updated my local CF build to 9.0.2. After installation I reloaded my app and everything worked fine. I then went back into the admin and enabled robust exceptions and a few other things for my dev environment. I also saw an option to turn off CFC type check. I had never tried this before so I turned it on to see if there was a speed difference. Instead my app stopped loading and displayed this error:

“The method matches was not found in component C:/wwwroot/MyApp/myComponent.cfc .:Ensure that the method is defined, and that it is spelled correctly.”

Digging into the code, the issue is inside Coldspring. “Matches” is a function used by Coldspring in the ProxyFactoryBean.cfc. With CFC type check turned off it seems that Coldfusion can no longer follow the CFC inheritance and does not realize that this function exists. Turning CFC Type check back off in the CF admin solved the issue, though I am still unsure why this was a problem.

The only other info I found on this issue was this Google Groups thread.