Help with MySiteMyWay theme

I’ve installed a theme from MySiteMyWay on my DH website. I’ve used the theme many times on other hosts, but not on DH before.

If you’re familiar with MSMW themes, then you know they have an excellent framework to control and modify themes. Everything thing works fine within all the theme control modules EXCEPT for the built in skinning module.

I’ve contacted MSMW and they say a required directory (on the DH server) does not have the correct permissions (777). I checked this, and set the permissions myself using the DH webFTP utility, and verified it via remote FTP using Filezilla. The directory IS set correct and recursively to all files/folders within.

So the MSMW support rep said it’s a DH problem, so I contacted DH support. It’s been nearly half a day and I’ve received NO reply from DH on my ticket.

Has anyone else had this issue with MSMW themes (or other theme frameworks) and been able to solve the problem?

Cool - I received a trouble ticket response!!!

Oh…wait a minute…hmmmm…the respondent was completely wrong, didn’t fix my issue, didn’t even address my issue, and apparently didn’t even read my issue.

And so I’m waiting…for another response…again…

Our apologies for the misunderstanding. It sounds like we could use a whole lot more detail from MSMW on what the issue could possibly be on our end. Our tech support team cannot provide support for specific themes and plugins of course, but if MSMW can provide more information on what our configuration might need, then we can definitely help. Actions like setting permissions, as you’ve said, you can take care of yourself. Since you have (I’ve confirmed) and the issue with your theme still continues, what did MSMW support come back with the second time? Please forward any further details you can from them by replying to the email I just sent you, and we will continue the investigation here. Thanks!

Directory permissions should be 700 min / 755 max. If anyone suggests altering a directory to 777 under any circumstance then you should immediately stop listening to any advice they give with respect to web programming.

^ I agree with sXi here, opening your folders to 777 is just asking to be hacked.

777 is required under extreme situations (like some PHP flavors require it). That said, our PHP settings do NOT need it, so you should only use 777 temporarily while debugging.

What folder are they saying you need to set those permissions on?

Well it still doesn’t work REGARDLESS of the directory permission settings.

Now I’m caught between Dreamhost telling me “we don’t support themes” and the MySiteMyWay telling me “we don’t support server issues.” And I’m ready to reach through this computer and ring someone’s neck!!!

Regardless, I have a problem and here’s what I know about the situation…

  1. The MSMW “skin builder / editor” does NOT load on my website hosted with Dreamhost - but it works fine on ALL other hosting companies that I run MSMW themes. I even tried loading another MSMW theme just in case it was a glitch with the one I had loaded. Same problem persisted with the new theme.

  2. When attempting to load the MSMW “skin builder / editor” on the Dreamhost website, I see the following script error in Firebug…

{"success":"skin_edit","html":"<div class=\"skin_generator_create skin_generator_option_set\"><div class=\"mysite_option_set skin_generator_error\">There was an error loading the following skin "_create_new.css", please make sure the following folder is writable by your server: "cms\/wp-content\/themes\/modular\/styles"<div class=\"edit_skin_button\"><span class=\"button cancel_skin_edit\">Return to Skin Manager<\/span><\/div><\/div><\/div>"}

Note this line:

There was an error loading the following skin "_create_new.css", please make sure the following folder is writable by your server: "cms\/wp-content\/themes\/modular\/styles"

To address this, I personally set the permissions on that folder from 755 to 777, and DH tech support ALSO set the permissions on that folder, and it has been verified multiple times by me and them. (I realize “777” is not the best solution, and if I ever get this issue fixed I will return it to “755” but for now I’m trying to solve a problem.)

Point is, changing the permission made NO difference, and the SAME message continues to be returned in Firebug despite all the changes (above and below) that have been made.

  1. After multiple support contact attempts, and posting on Facebook because no one would help me on DH support, someone actually READ MY FREAK’N SUPPORT REQUEST and did what I told them to do to replicate the issue. And FINALLY I received this response…

[quote]The only thing I was able to find in regards to the issue was a 503 error
being thrown in apache:

w.cs s

503 usually relates to mod_sec rules being thrown but I did not see a
specific mod_sec rule being thrown. You may want to disable the Extra
Security option at the Manage Domains page by clicking on Edit for the
domain. If you have any other questions or concerns, please do not
hesitate to contact us.[/quote]

So I DID disable the “Extra Security” option (which they specifically tell you NOT to do in the help wiki) and guess what happened…NOTHING. The skin builder / editor still does NOT load.

  1. Back in the MSMW theme options, I tried another function which loads the CSS file directly into an editing window and received THIS message…


503 Service Temporarily Unavailable

Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.


Once again we see a 503 error cropping up, and interestingly enough it seems that ALL the errors are pointing to the same directory: theme / styles

Well, that’s where I’m at and I really do need someone to help me figure this out. So I’m turning to the forum where most of the REAL experts are.

Could I work around the issue? Yes. I could upload/download the css file and edit in Dreamweaver, or overwrite the css in the “custom css” function of the MSMW options. But that is NOT the point. The point is I like DH (for the most part) and I like MSMW (for the most part) and I have clients that need websites, and need website hosting. So I’m inclined to put my clients on DH and use MSMW themes. Unfortunately, there is a function provided in MSMW themes that I need to use, and there is a DH server conflict with that needed function.

ANYONE’s help would be GREATLY appreciated…

Well. We don’t support theme design. And debugging a theme is not a simple prospect, which is part of why it’s outside our scope. We just don’t have the manpower or skills to reverse engineer all the themes and plugins out there to fix problems.

My first thought is “No self-respecting theme EVER writes your data to the themes folder!” That folder is overwritten when you upgrade the theme!


What’s your domain or ticket number? I can’t promise that I can fix it, but I may be able to see what’s wrong in that theme. They’re already doing something really annoying, so it’s possibly more than ‘just’ permissions.

Here’s my latest message number: 5654063
Here’s my first message number: 69583636
Here’s the subject line reference number in the original auto-email reply: 70367243

And again, here I am caught between the host and the theme developer, both pointing fingers at the other.

I have NO idea if the theme is “built” right or wrong. Obviously you have an opinion about the theme having a flawed implementation, and obviously the theme developer has an opinion because that’s how they built it.

On the other hand, the MSMY themes work perfectly fine on every other hosting company I use, and this particular function seems to work fine for thousands of other websites running this company’s themes.

If this theme function was truly “broken” then there would be a HUGE outcry on the MSMW forum about the problem. But there are no such threads. Trust me, I’ve LOOKED hard for them to figure this out!!!

Rather, it seems Dreamhost has implemented a default policy, procedure, or protocol - for whatever valid reason - that is generally in our best interest (as DH hosting customers) and generally doesn’t present a problem with most WP themes. (Otherwise there would be a lot of threads on HERE about the issue, which again there are not.) But in this particular case, it does prevent a useful function of this theme from working correctly.

So please understand I’m NOT trying to be obnoxious, but from my perspective DH is blocking a theme function that works perfectly fine everywhere else; and that just doesn’t seem like making a special exception to troubleshoot a theme.

I’ve followed all the instructions given to me and went through all the communication channels made available to me to fix this. The problem persists and I’m simply asking you to support ME as a customer, who routinely sends new clients to DH for website hosting.

And I DO sincerely appreciate your help…

Oh the theme isn’t ‘broken’, sorry, it’s just not doing_it_right() … I get that probably sounded like semantics to someone, but there’s a line between ‘Dead down busted’ and ‘This is not the best way to do this…’ The short version is this: A theme and plugin should never ever ever write to it’s own theme folder. We reject plugins and themes from the repository outright when they do this.

Anyway, that’s really beside the point. It’s not broken when it does this, it’s just not good. Moving on.

I turned on debugging on your site (editing the wp-config.php and change the value of WP_DEBUG to true) to see if there was actually an error going on. There is. The ‘headers already sent’ error is usually indicative of blank lines in your theme or core WP files.

I would copy up a fresh version of the theme and see if those go away. Just delete the folder, upload a clean one.

Of course it didn’t. Never set anything to 777 under any circumstances.

Check that all directories in the entire path are set min 700 / max 755.

Don’t wait. Change them back immediately and never, ever set perms to 777.

Not a good idea on the face of it, but disabling it temporarily for troubleshooting purposes was a good call by Support. “Enhanced Security” is a User security setting tho, so just check that you’ve flipped the right switch. The thing that controls mod_sec is under Web Options in Manage Domains and is labeled as “Extra Web Security”.

[quote]Back in the MSMW theme options, I tried another function which loads the CSS file directly into an editing window and received…

503 Service Temporarily Unavailable

Once again we see a 503 error cropping up, and interestingly enough it seems that ALL the errors are pointing to the same directory: theme / styles[/quote]

It’s strange that mod_security doesn’t log the cause. Again, recheck permissions (and ownership) of files/directories in the relevant path. Also take a look for any .hidden files (such as .htaccess, etc.) that might be tripping security up.

What I’d do in this situation is:

  1. Create a new SHELL user with “Extra Security”.

  2. Create a test dreamhosters sub-domain - initially without “Extra Web Security” (and definitely without any other options checked) and attach the new user.

  3. Install the latest vanilla WP and the latest vanilla MSMW. No cheating here. Brand new everything.

  4. Give it a test run and report your success.

Now we’re getting to some meat of the issue. So it seems DH has a policy, that is implemented as a server protocol, that is blocking the functionality of a theme. But apparently this is not universally accepted in regard to WP best practices because the theme developer and many other hosting companies clearly don’t have any problem with the procedure in question. It would seem WordPress also doesn’t have a problem with it as they allow themes and plugins that do this very thing. Doesn’t that make DH a bit isolated on this issue…???

[quote]Anyway, that’s really beside the point. It’s not broken when it does this, it’s just not good. Moving on.

I turned on debugging on your site (editing the wp-config.php and change the value of WP_DEBUG to true) to see if there was actually an error going on. There is. The ‘headers already sent’ error is usually indicative of blank lines in your theme or core WP files.

I would copy up a fresh version of the theme and see if those go away. Just delete the folder, upload a clean one.

This was one of the first things I tried…didn’t help.
Then I tried downloading / uploading and entirely different theme from the same company…same problem.

But just to show I’m a team player and willing to do my part, I have just now downloaded the latest Modular theme from MySiteMyWay, and uploaded it directly via FTP (not the WP theme installer.)

And…wait for it…

Great - now the whole D@#$@# thing is jacked up!!!

When I activate the newly downloaded/installed theme, the theme “activates” but I get this at the top of the WP theme selector page…

Notice: get_theme_data is deprecated since version 3.4! Use wp_get_theme() instead. in /home/(...domain removed by me...)/cms/wp-includes/functions.php on line 2839 Warning: Cannot modify header information - headers already sent by (output started at /home/(...domain removed by me...)/cms/wp-includes/functions.php:2839) in /home/(...domain removed by me...)/cms/wp-includes/pluggable.php on line 876

What the heck??? That certainly wasn’t there yesterday and it’s the SAME theme I downloaded and installed before…???

(Yes - I completely deleted the ENTIRE directory via FTP and reuploaded it. And then I tried it again using the WP theme uninstaller. Same error lines either way.)

So I downloaded and installed ANOTHER MSMW theme and tried to activate it. Same message appeared, but now I cannot activate ANY of the MSMW themes!!!

Let me be the first to recommend a new alert message be added to the Dreamhost 1-click installer for WordPress…

“NOTICE!!! Dreamhost does NOT fully support themes developed by Use these themes at your own risk!!!”

Of course that’s just a friendly suggestion…

Looking forward to your next recommendation cause now I’m completely dead in the water… :slight_smile:

I checked folder and file permissions while I was in there and they looked fine. The right owners and everything. No errant .htaccess files.

Hang on, what’s the full error there? Is it wp-content/themes/styles?
OH! I’m really sorry. NO! DreamHost does not have a policy about that. does. Part of my role here is liason with and in that role I review plugins among other things. So … those rules I know really well. I forget not everyone knows about my many hats. My bad.

That error you’re seeing is because, as I said, I turned on the WP_DEBUG on your site. It’s the only way to see what errors are running about. And since we now know it’s not fixed with a fresh copy of the theme, two things can be done:

  1. Does it happen with another theme? Like TwentyEleven?
  2. Can you try reinstalling the WP core files?

Basically we’re trying to narrow down where the error acutally is.

Glad we’re making progress.

No, I do not get that php alert notice thing when I activate any of the default WP themes (2011, 2012, etc.) Only when activating a MSMY theme.

But maybe this entire install is getting jacked up so I just created a completely NEW WordPress installation in the directory “/cms2/”

I’m installing a brand new copy of the theme now…and installed fine via ftp.

Activating it now…and it activated fine, no alerts.

Trying the skin builder / editor function now…and we’re back to square one. It still doesn’t work and I get the same script error in Firebug…

New WP installation, new theme install, no luck. :frowning:

Okay, that’s … good and bad. You’re not getting alerts probably because you didn’t turn on WP_DEBUG. If you want to do that, to see the same errors, edit the wp-config.php file and fine ‘define(WP_DEBUG,false);’ and change false to true.

Interestingly, I see people having this exact error, with no fix from the theme vendor…

I verified you’re using the latest version of the theme too…

You could try creating the _create_new.css file yourself and see if it can write to it after that?

Nope - I didn’t turn on debugger.

Thank you for the links, though as popular as the skin builder function is, I’m surprise there are not a lot more posts if it were truly a systemic and serious issue (I had found one of those posts when searching, but the other was new to me.)

I tried creating the _create_new.css file myself, didn’t help.

[color=#FF0000]Please tell me specifically if these two quotes (from the MSMW forum) represent the same problem I’m facing with my DH hosted site…[/color]

We’ve looked into it and, like with many hosting providers, scripts are not allowed to run under 777 for security reasons. We’ve seen that the following file:


sets 666 and 777 for various functions. Would this have something to do with it? If so, what do we do about it?[/quote]

[quote]My hosting provider has had a good look at the theme and replied thus;

The permissions error message being received here appears to have been a bit of a red herring and wasn’t the actual issue. It looks as though the module uses a loopback when opening this option which is firewalled out on our systems meaning this failed and the error message in reference to this being writeable was produced. By default, loopbacks are not enabled and is not something we can allow.

In basic terms, when clicking on the option to create a new template in this module something within the script is attempting to call a file/script using as the path for this rather than the server path (eg. /home/sites/ meaning the request is made via a http request (as you would when loading a site in a browser) which is firewalled out on the server. The script/function would need to be able to use the absolute server path for this to function.

So I guess until/unless the framework is updated to amend this we have three themes that we cannot use. [/quote]

Same user? Same domain settings?

^ Loopback? /lib/admin/classes/skin-generator.php

Time to switch to a framework written by someone who knows how to program.

Yes, those two quotes (and the second one primarily) appear to be exactly what’s causing the problem here.

My personal opinion is to ask for a refund from them. They’re doing one bad thing (writing to /wp-content/themes/themename/) followed by a second (calling the file via http vs an include or anything else). These are contrary to standards.

When looking for commercial theme shops, the ones listed here are generally the ones I recommend:

[quote=“sXi, post:17, topic:59570”]

Same user? Same domain settings?[/quote]

I think so…???..are you asking for purposes of helping troubleshoot?

LOL - well that’s not particularly helpful as the theme vendor would probably say time to switch to a hosting company without all these silly restrictions.

Once again can we PLEASE avoid fingerpointing. Because my site is running DH servers, I need someone at DH to tell me the following…

  • PRECISELY what is being called by the theme that is being blocked by the server?
  • Can this be fixed on DH’s side?
  • If yes, then please help me fix it.
  • If no, then please tell me PRECISELY what to tell the theme developer so they can provide an alternative solution.

I really don’t care WHO is to blame, I’m paying BOTH companies good money and I need a solution - PLEASE!!!

  • The problem is your theme is calling files in a way that our servers don’t permit.
  • No, it’s not something we can fix (Well … CAN is a weird word, I’ll explain in a tic)
  • Would if I could
  • Tell the theme dev “Your theme is calling files directly via HTTP instead of properly using an include or calling it via other normal PHP methods. Because of this, it inadvertently creates a ‘loopback’ which causes an error 503 as our servers don’t understand the abnormal request. I’m running PHP 5.3 FastCGI on a shared server, and the default permissions set by WordPress have no issues uploading or editing other files. I can edit themes and plugins via the default WordPress theme editor, just not yours.”

To explain about CAN fix… I’m sure we could. But we won’t. The reason you block that sort of loopback is to prevent servers from crashing, and to prevent people from injecting hacks into your site. It’s a safety feature, basically. We’re not going to let you even start the car till the seatbelt is on.

The bit about finger pointing, that’s very different from passing the buck. The theme shop is 100% right, it’s our locked down permissions that are the problem. At the exact same time, we also are totally correct saying they’re doing it wrong. So please don’t jump all over me and sXi when we tell you that the problem is the theme. It is the theme doing things in a bad way that just happens to hit against the safety measures DreamHost has.

We’re both right, but the only person who can decide which is more important is you.

Both sXi and I are pretty experienced in WordPress. We know how it works, and while we may quibble about semantics or outright disagree on other aspects of the community, we both feel that the themeshop is more in the wrong than WordPress in this moment.

(I quite like sXi and not just cause I love saying the user name :wink: I disagree with people I love working with. Strong opinions and all that.)