MODx 2.2.6 Manager Not Working Correctly. Missing Items & Blank Pages. OMG!

☆ A M B ☆
24,524 Posts

sottwell Reply #51, 12 years, 2 months ago

Quote from: mmcgee at Jul 22, 2014, 03:01 AM

Not sure if this is normal or not, but each time I delete the core/cache, the number of items is different. 12 earlier, now 14, and for a while it was 13 files deleted. Perhaps that's normal?

Yes, that's normal. A cache file isn't created until the object being cached is accessed for the first time. And accessing a resource with a logged-in Manager user doesn't count.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

1,078 Posts

mmcgee Reply #52, 12 years, 2 months ago

Mine is 94 through 125 and has much more content that you are showing. So I remove the entire set of code or just part of it?

  public function getUserImage()
    {
        /** @var modUserProfile $userProfile */
        $userProfile = $this->modx->user->getOne('Profile');

        if ($userProfile->photo) {
            // First, handle user defined image
            $src = $this->modx->getOption('connectors_url', MODX_CONNECTORS_URL)
                .'system/phpthumb.php?zc=1&h=128&w=128&src='
                .$userProfile->photo;
            $userImage = '<img src="' . $src . '" />';
        } else {
            // Fallback to Gravatar
            $gravemail = md5(
                strtolower(
                    trim($userProfile->email)
                )
            );
            $gravsrc = $this->modx->getOption('url_scheme', null, 'http://') . 'www.gravatar.com/avatar/'
                .$gravemail . '?s=128';
            $gravcheck = $this->modx->getOption('url_scheme', null, 'http://') . 'www.gravatar.com/avatar/'
                .$gravemail . '?d=404';
            $response = get_headers($gravcheck);

            if ($response != false) {
                $userImage = '<img src="' . $gravsrc . '" />';
            } else {
                $userImage = '<i class="icon-user icon-large"></i>';
            }
        }

        return $userImage;
    }

1,078 Posts

mmcgee Reply #53, 12 years, 2 months ago

I see what you mean. Working on the edit now.

1,078 Posts

mmcgee Reply #54, 12 years, 2 months ago

Still unable to see items in the Tree, and inevitably getting the blank page.

I'm zipping and downloading all of the site files and will do a search for any base64 or @eval files just to see if I have missed something somewhere.

Manually deleting the core/cache with the file manager always seems to at least bring the front end of the site online, and allow me momentary access in the manager.

1,078 Posts

mmcgee Reply #55, 12 years, 2 months ago

Question: Is all base64 bad?

I have not reviewed each doc, but a quick search found that these docs contain "base64"

setting.inc.php
CssCompressor.java
FileAPI.js
ext-all.js
wayfinder.class.php
visualblocks.css
wayfinder.class.php
function.fetch.php
phpthumb.functions.php
snoopy.class.php
xmlrpc_wrappers.inc
xmlrpc.inc
xmlrpcs.inc
class.phpmailer.php
class.smtp.php
cloudfront.class.php
ec2.class.php
jsonrpc.inc
jsonrpcs.inc
modconnectorresponse.class.php
modpbkdf2.class.php
modphpmailer.class.php
modprocessor.class.php
policy.class.php
s3.class.php
s3browserupload.class.php
sdk.class.php
ses.class.php
setting.inc.php
setting.inc.php
setting.inc.php
utilities.class.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php
setting.inc.php

1,078 Posts

mmcgee Reply #56, 12 years, 2 months ago

Well, many of the files with base64 seem normal. No gibberish strings of code next to them.

A search for @eval resulted in 6 resove.core.resolver files and a modoutputfilter.class.php
resolver files want to be opened by Terminal, so I am just leaving them be. Don't know whether these could be causing the manager issues.

What about ht.access. Would changing to .htaccess help? Clearly I am grasping at straws at this point.

1,078 Posts

mmcgee Reply #57, 12 years, 2 months ago

I found this string in core/model/phpThumb/phpthumb.functions.php

fwrite($fp_tempfile, base64_decode('R0lGODlhAQABAIAAAH//AP///ywAAAAAAQABAAACAUQAOw==')); // very simple 1px GIF file base64-encoded as string

Is this OK or a Hacker?

☆ A M B ☆
24,524 Posts

sottwell Reply #58, 12 years, 2 months ago

.htaccess is instructions for the Apache web server. If you aren't using Apache, then it's useless. And if you are, MODX primarily uses it for rewriting page.html to index.php?q=page.html so that MODX gets run and passed the alias of the resource being requested.

As far as base64, on a fairly new installation of 2.3 I only have a bunch involving .js files for the Ace editor plugin, and three files involving the manager, all .js files and one java file for the manager's js and css compression utility. No .php files with it at all.

Ah! stupid! I keep forgetting I've moved my core outside of the web root! Plenty of them in the core, looks like the same ones you see.

The one in phpThumb is fine. Just a handy way to provide the tiny 1px image without having to go and fetch it.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

1,078 Posts

mmcgee Reply #59, 12 years, 2 months ago

I have that list of files, each containing base64. Most seemed normal to me... for what that's worth.

However, modified my search to base64_decode and yielded fewer files, most seemed normal except for the one in the phpthumb file. But maybe that one too is OK. Seems to me it has something to do with writing a small gif / placeholder type file.

1,078 Posts

mmcgee Reply #60, 12 years, 2 months ago

Well that was a long night.

Still having issues with the manager and not sure what to do next. This could be a remnant of the "core services" hack. Then again, could it just be an issue with goDaddy and any problems they've been having over the past few days.

I do have one question related to my other MODx site that I recently moved from 2.2.8 to MODx 2.3 and also migrated from older hosting over to cPanel. I think / hope its clean. No sign of the core services plugin or the cache.php files in assets. However, in the assets directory is a file named .listing I can only see it within the MODx manager though, but not in the cPanel. However on this goDaddy cPanel, I was also not able to see .htaccess within the cPanel file manager.
I have another new, clean MODx2.3 install for a third site over at skytoaster and do not see the file .listing.

Does the prescence of this file called .listing mean the site has been hacked? There is also another one out in the root of the site that is an even longer list? This .listing have been some kind of a cheat sheet the goDaddy techs were using for migration purposes. Some of the dates could possibly match file dates.

The contents of the file look like a permissions setting:

drwxr-xr-x 6 3394 inetuser 4096 Jun 20 2013 .
drwx---r-x 13 3394 inetuser 8192 Jul 10 19:30 ..
drwxr-xr-x 5 3394 inetuser 4096 Jul 2 2013 components
drwxr-xr-x 5 3394 inetuser 4096 Jul 6 2013 images
drwxr-xr-x 2 3394 inetuser 4096 Jul 4 2013 javascripts
drwxr-xr-x 2 3394 inetuser 4096 Jul 4 2013 stylesheets

All plugins/snippets on the site are as expected. The only one I'm not that familiar with is one called "If" I don't remember installing it, and I know I don't use it.

No unknown or added Users to the manager. So all good there. [ed. note: mmcgee last edited this post 12 years, 2 months ago.]

Answered MODx 2.2.6 Manager Not Working Correctly. Missing Items & Blank Pages. OMG!