Posts by dtbaker

I’ve had customers figure out how to use WooCommerce and Jigoshop with no problems, these are very easy to install and setup. Slightly more complicated to setup is Prestashop but I’ve had customers figure out how to use this themselves as well. Try WooCommerce if the site is running on WordPress.

Yerp. Digging through some code now, using the latest EAP 129.196

May, ouch! gonna see some wicked talent shine here if someone starts building from scratch.

getting sneaky with this request >> what about a new WP plugin that integrates with the existing newsletter features of my UCM system? ie: Install UCM, install WP plugin, use UCM to send newsletters normally (like current) or to send newsletters to the WP customer base (new feature). and some new WP widgets like subscribe, past newsletters, dashboard newsletter stats etc…
It wouldn’t be a new “newsletter” item per-say, but a new way to integrate with the existing newsletter feature of UCM.
Could an entry like that be considered (gonna be making it anyway)?

Cheerio,
Dave

the Input with error style is win

Got it working. Hooked into the ‘query’ filter and regex’d the raw wordpress SQL so it would support multiple nested post types.

nasty.

but now wordpress will:

• generate nice URLs, like /pages/sub-page/custom-post-type (eg: http://ultimateclientmanager.com/support/documentation-wiki/change-request/ )
• automatically highlight any ancestor menus ( see left and top )
• allow custom post types to be grouped under multiple different pages, which would not be nice via the old filter nav css method

phew

Turns out it’s impossible to nest multiple post_types using the built in post_parent wp feature.

The wordpress get_page_by_path() will only return a valid page if all of the nested items are of the same post_type. There are no filters or tricks or hooks at this low level. Meh

Same here.

Solution is to wrap a fixed height div around the item a links that do not have the tooltip-magnifier.

problem thumbnail

  <a href="/item/swift-a-wide-screen-responsive-theme/4404959"><img border="0" width="80" height="80" title="" src="http://3.s3.envato.com/files/52603815/swift_80.jpg" data-preview-width="" data-preview-url="http://0.s3.envato.com/files/52603820/Screenshots/00-Preview.__large_preview.jpg" data-preview-height="" data-item-name="Swift: A Wide Screen Responsive Theme" data-item-cost="45" data-item-category="Wordpress / Corporate" data-item-author="MDNW" class="landscape-image-magnifier preload no_preview" alt="Swift: A Wide Screen Responsive Theme - ThemeForest Item for Sale" data-tooltip="Swift: A Wide Screen Responsive Theme" style="" /></a>

fixed thumbnail:

<div style="height: 84px; position: relative;">
  <a href="/item/swift-a-wide-screen-responsive-theme/4404959"><img border="0" width="80" height="80" title="" src="http://3.s3.envato.com/files/52603815/swift_80.jpg" data-preview-width="" data-preview-url="http://0.s3.envato.com/files/52603820/Screenshots/00-Preview.__large_preview.jpg" data-preview-height="" data-item-name="Swift: A Wide Screen Responsive Theme" data-item-cost="45" data-item-category="Wordpress / Corporate" data-item-author="MDNW" class="landscape-image-magnifier preload no_preview" alt="Swift: A Wide Screen Responsive Theme - ThemeForest Item for Sale" data-tooltip="Swift: A Wide Screen Responsive Theme" style="" /></a></div>

Good idea, I’ll give that a shot and try to tackle manually highlighting multi level page parents as well.

Almost! The issue is when I select a parent on a “wiki” the URL changes from to:

and gives a 404 error lol

If the custom post type rewrite slug is changed from ‘support/documentation-wiki’ to just ‘wiki’ then the generated url looks like this:

and this still gives a 404 error, and an incorrect url.

So I’m trying to tackle the permalink generation when a parent is selected, along with current menu highlighting. I think menu highlighting will be easier once URLs are generated successfully.

Currently all wiki articles have no post parent, that’s the only way I can get it working.

Yep it saves post_parent in the db just fine, but it treats the “wiki” post_parent different to a “page” post_parent when generating permalinks and automatically highlighting menu items (even when a wiki post_parent points to a page).

Yep manually highlighting menu items is easy when hardcoding the page ID’s eg:

add_filter('nav_menu_css_class' , 'special_nav_class_bbpress' , 10 , 2);
function special_nav_class_bbpress($classes, $item){
         // highlight menu item ID 456 when viewing page ID 123.
         if(get_the_ID()==123 && isset($item->ID) && $item->ID==456 )
            $classes[] = 'active';
}

but I’m trying to avoid any hardcoding of ID’s/slugs. Basically trying to trick wordpress into thinking a “wiki” post type is a normal “page” when it does the behind the scenes magic (permalink generation and menu highlighting). Still digging through the WP code, but so far this low level stuff doesn’t seem like it has any available hooks to mess with

more on stackexchange: http://wordpress.stackexchange.com/questions/94517/custom-post-type-nest-under-a-normal-wordpress-page – hopefully someone can assist