datdesignguy

So, after some more research, I realized this could be caused by my CPT having publicly_queryable, and exclude_from_search set to FALSE. So I removed all arguments for the post type except the labels and supported fields…

This still hasn’t fixed the problem. Here is a quick snippet of the current Custom Post Type definition:

public function action_init_register_post_type() {
		global $wp_rewrite;

		register_post_type( $this->post_type, array(
			'labels' => array(
				'menu_name'          => __( 'Certified Partners',        'ibpartnerpages' ),
				'name'               => __( 'Certified Partners',        'ibpartnerpages' ),
				'singular_name'      => __( 'Certified Partner',         'ibpartnerpages' ),
				'all_items'          => __( 'All Certified Partners',    'ibpartnerpages' ),
				'add_new'            => __( 'New Certified Partner',     'ibpartnerpages' ),
				'add_new_item'       => __( 'New Certified Partner',     'ibpartnerpages' ),
				'edit_item'          => __( 'Edit Certified Partner',    'ibpartnerpages' ),
				'new_item'           => __( 'New Certified Partner',     'ibpartnerpages' ),
				'view_item'          => __( 'View Partner Landing Page', 'ibpartnerpages' ),
				'search_items'       => __( 'Search Partners',           'ibpartnerpages' ),
				'not_found'          => __( 'No Partners found',         'ibpartnerpages' ),
				'not_found_in_trash' => __( 'No Partners found in trash','ibpartnerpages' ),
				),
			'menu_icon' => plugins_url('img/certified-partner.png', __FILE__),
			'supports'      => array( 'revisions' ),
		) );

		maybe_flush_rewrite_rules( $this->post_type );

	}

Still working on a solution here… Anyone with some insight?

I’m going to try switching over to manual $wpdb queries, as that seems the only other viable option to get this project out the door on time.

Oh man, Tom. That is a pretty unique case there. Man… Your prob was def a real head-scratcher.

I have 1 or 2 sites on hostgator that have Attracta activated. Gonna delete that fastinclude file on each of them before they can cause me any problems too! So far no problems though, but then the sites are just straight up blogs.

Glad you got your problem fixed

Greg

Have you made any modifications to the display templates since installing? Also, is this the GetShopped.org plugin?

You can’t access wp-admin, but can you access the front-end of the site?

try visiting /dashboard as well… another 404?

Are you using the english version of wordpress? ( May be a silly question, but I was reading here… that localization could be a factor )

can you also check file permissions and ownership of the options-general.php file? Do you know how to do that?

Your permissions on the file should be 644, and the ownership should match that of the other documents, index.php for example.

Hey

My first guess would have been mod_sec… Crap! Lol.

My second thought is you might have some old paths stored in your db. I ran into this very same problem once after migrating a local installation to a client’s website.

I had to comb through the wp_options table, and whereever it had paths to my dev machine stored, I updated the options so that it had the proper linux path.

something like: SELECT * FROM wp_options WHERE option_value LIKE '%/old/system/path%';

Of course, if you the site hasn’t been migrated from one place to another, then this won’t be the problem. I’ll dig around and see if I can find anything else of use…

Are you running 3.4.2?

-Greg

Heya Tom,

Nice headline… ??

I had a look at the site, and I’m not certain, but if its working on your local environment, but not on your live site, my guess would be it’s a mime/type issue.

I’m not familiar with the woocommerce codebase, so I’m afraid I can’t be more help other than to say, perhaps the server is misinterpreting the response as text because it doesn’t have a mime type installed to understand JSON. You may want to ask your host if the server supports JSON as a mime type. If not, you may have to find the php ajax handler function for the place_order call (that’s the javascript event triggered by the place order button) and add a line like this that explicitly tells the browser it’s getting a json response…

<?php header('Content-type: application/json'); ?>

I’m not sure if this IS indeed the problem, but at a 2-min inspection, that’d be my first guess. Hope this helps at least point you in the right direction!

-greg

Have you double-checked to make sure that the RSS feed you are reading from contains more than 10-items?

Sorry if that seems a silly question…

-greg

Hi ravalde,

I believe you just need to go into the backend and set a variable…

Garbage collection is how the Caching plugin cleans up after itself. It will go through and delete expired items in the cache so that they can be updated with a more-fresh version of the content (if any)…

To fix this just go to: (of course replace “yourdomain.com” with your actual wordpress domain)
https://yourdomain.com/wp-admin/options-general.php?page=wpsupercache&tab=settings

On the Advanced tab, scroll down until you see a section called “Expiry Time & Garbage Collection”…

Set your cache timeout to a value like “3600” (1-hour)

Set your scheduler value to like 1800 seconds (1/2 hour)… this will tell WP Super Cache to look for and clean up any “Stale” cache files every 30 minutes.

Then click save options…

In THEORY, this should fix your problem.

Good Luck!

Greg

It sounds like, and I’m just guessing here, that your form is posting directly to the my_processForm.php file?

If that’s the case, and you want to use WordPress functions, you would need to include the file ‘wp-blog-header.php’ from the root directory of your wordpress install.

I’m not so sure that the way you’re doing things is necessarily best practice however. If I were you I would just have the form post back to itself (you can leave the action attribute in the form tag blank) and add in a nonce, as well as a hidden field that identifies your form to WordPress and secures it from CSRF or XSS attacks.

This article provides a pretty decent example:
https://voodoopress.com/how-to-post-from-your-front-end-with-no-plugin/

I hope this helps!

-gj

Yeah, I remember reading somewhere (a “crowd favorite” blog post I believe) that twitter had retired the API urls used in the original twitter tools plugin. I believe embedding your timeline in a widget is now supposed to be support by the Social Plugin by Crowd Favorite. Don’t quote me on that though.

I don’t know of any plugins, but color me interested. Seems like a lot of moving parts. The javascript for it is pretty straightforward, you could probably hack it together from scratch using something like flexslider from woothemes, and some custom code.

You should be able to eliminate the redirect by going to gravatar.com and simply claiming your email address (the one that you is associated with your wordpress login) and uploading the picture you want for your gravatar directly to gravatar, using their interface. If you continue to use a URL instead of uploading the image directly, you’re going to encounter the redirect.

I hope that helps

-greg

*edit* I didn’t realize that your users weren’t already registered on both sites. In that case, you may want to add a hook into your webapp that automagically registers users with both webapp and wp site on registration. OR, using one of the methods below, you can have wordpress create the user on the fly, and just send the user_id back to your webapp, and your webapp could store the wordpress user id for future use. Just a thought…*

Aren’t cookies locked down to a specific domain? I’m not sure if an htaccess is going to do the trick from one domain to the other. You might look at authenticating the user on both the webapp and the wordpress site at the same time, that’s how I’d handle it.

Do you have the ability to hack some of your “webapp’s” code to perhaps make an http post request to your wordpress site during the user login process?

If so, then you could just write a function that receives data only from your webapp’s domain, containing some sort of encrypted key that only your webapp would know as well as the email and or user id of the person you want to log in, and just run a “set_user” function call on the wordpress side.

Not sure that this is a very secure method though, as the call would have to be made through an iframe.

Alternatively, I think you could also try making a call from your webapp site to your wordpress site that sets a transient containing a nonce and a user_id after a person logs in on the webapp side. Then, you just add a filter to your webapp that appends the nonce as a GET parameter to all of your links to your wordpress site. When the user clicksthrough from your webapp, wordpress looks up the transient and then runs set user.

Maybe one of those two approaches will help you out?

Great question though!