hixsonb

Good Morning,

Just checking in real quick to see if there as an update on this issue.

Thank you,

Hi Cais,

Thank you for the feedback.

When I try to go to Gallery > Other settings, the error “Exception thrown not defined for ExtensibleObject” occurs.

I just submitted the bug report from the link you provided.

Thanks again!

Jonny cakes, if this helps… this is what I do when moving a WP site from one domain (URL) to another domain.

As you mentioned, copy all files in the wp-content folder from SITE A to SITE B. This ensures all plugins, uploads and etc. are the same. (Of course, the rest of the WP core files should be there).

Export DB from SITE A to an un-compressed SQL file. Run that SQL through a script changing all instances of https://siteone.com to https://sitetwo.com.

Then, import the updated SQL file into the DB for SITE B.

The only issue that I have seen with this process is that if there are any TEXT widgets, they will NOT be copied over. Be sure to make note of them.

Never mind, I figured it out. I will put the fix for my instance in case anyone else ever comes across.

I finally realized there was an .htaccess in the wp-includes directory that I had put there awhile back to help prevent directory browsing. I simply removed it and that fixed the issue.

Never mind… isn’t that it can be. Once I open a ticket I figure it out.

The problem actually was in the CSS believe it or not. The styling for that menu was calling an image that didn’t exist. I just modified the CSS and now the menu works.

Thanks.

Getting Closer.

Adding this code to my functions.php enabled the ability for the custom post types to show in categories and archives.

However, the archive-services.php and categoreis-services.php still don’t work.

(services is the name of my custom post type).

<?php add_filter(‘pre_get_posts’, ‘query_post_type’);
function query_post_type($query) {
if(is_category() || is_tag()) {
$post_type = get_query_var(‘post_type’);
if($post_type)
$post_type = $post_type;
else
$post_type = array(‘post’,’services’,’nav_menu_item’); // replace cpt to your custom post type
$query->set(‘post_type’,$post_type);
return $query;
}
} ?>

(I had to add the line ,’nav_menu_item’ because when I first added the code, my nav menu went away.

Just as a quick update, I can add the following code to the archive.php and/or category.php and it WILL return results of the custom post type.

<?php query_posts(array(‘post_type’ => array(‘post’, ‘services’))); ?>

(services is the name of the custom post type)

HOWEVER, it still doesn’t seem to be working right with because if I create a archive-services.php or category-services.php, it isn’t recognized.

So, still looking for help.

Thank you.

Hi Pross,

Thank you! I will do that.

Take care

Never mind, I figured it out.

There was a section (like below except it had his credentials) in the client’s wp-config.php that I have not noticed in other wp-config.php files. By putting in the right credentials, I was successfully able to upgrade within the WordPress admin panel.

By removing the lines all together, the input sections were not grayed out anymore.

/** FTP SETTINGS FOR AUTO-UPDATE */
define(‘FTP_HOST’, ‘localhost’);
define(‘FTP_USER’, ‘ftp_id’);
define(‘FTP_PASS’, ‘ftp_password’);

Hi,

I was having the same problem for a client’s site. The solution I found may not work for you, but it did in this case.

Make sure to make a backup copy of your wp-config.php file before doing any editing.

Edit the wp-config.php and look for a section as below. The FTP_USER and FTP_PASS should match your domain FTP access. I have not noticed this section in most wp-config files but it was here in my client’s case so I changed it to match the credentials and it worked.

/** FTP SETTINGS FOR AUTO-UPDATE */
define(‘FTP_HOST’, ‘localhost’);
define(‘FTP_USER’, ‘ftp_user’);
define(‘FTP_PASS’, ‘ftp_password’);

After the change, upload it to your server. As stated… MAKE SURE YOU BACKUP YOUR WP-CONFIG.PHP before making any changes.

I too was experiencing this problem on a client’s site but not my own. All the permissions were exactly the same.

The solution that DID work for my client was what bbuxton mentioned. Thanks bbuxton!

I just disabled “safe mode” on that domain for the client. He is hosted on Plesk. All of the other settings within the WordPress Admin Panel stayed at the defaults.

That is what I was afraid of but just wanted to hear it from someone else.

As stated, the way you mention works just fine but I was trying something new in a theme I am creating.

Thanks stvwlf.

I am having the same issue even with the default theme so it must be a bug like DaMsT said.

I have noticed however, if you place the <?php comment_id_fields(); ?> in a specific area i.e. by replacing id=”comment” in the comment textarea of the form with id=”<?php comment_id_fields(); ?>” it WILL show the name but it throws the reply box down to the bottom of the page instead of leaving it on the specific comment.

The bad news is that the “how to” notes on this topic however do say that id=”comment” must be present.

I’ve tried moving the <?php comment_id_fields(); ?> to specific points within the form and nothing works. I guess we will have to wait for 2.71.

Thanks

“Bars” are gone. ??

I can certainly see now they were not appealing but for some reason I felt something should be there. I know I stated it was my intention to keep this theme clean but the links on the left just like they needed something.

It’s been a great experience building my first theme from scratch and will start on another soon.

(Still would like more feedback is someone feels so inclined).

Thanks.

Thanks everyone, I definitely appreciate the good feedback.

Believe it or not, the list-style is set to none, that is actually a 6px border left; when hovering, it just changes the border color.

I’m definitely going to come up with something else since it seems, at least so far, that the “yellow bars” wasn’t such a good idea. I think the light blue is a better idea but I may just get rid of them all together.

Thanks.