I just want to jump in here and add my own two cents.

I was able to sift through your theme code and modify the mega menu to support both custom post types and custom taxonomies. It took me about two business days to get it all sorted out. I’m under a tight budget though, so I have a few hacky things in place (hard-coded custom post types, the admin selection could be improved to clearly separate the taxonomies).

It was mostly just an issue with WP_Query where, instead of passing in a ‘cat’, you must nix that and pass in ‘tax_query’ options instead.

I’m not much of a WordPress developer, but I imagine that someone with more experience in WordPress and the Newspaper theme could add this feature in only a few hours. Certainly not more than a full business day.

I had originally purchased this theme thinking that it had full support for custom post types and was a bit disappointed when I had to jump in and edit code. Perhaps my vetting process was not sufficient, but your seemingly partial support of custom post types is what threw me off. More and more websites are using custom post types, so I imagine I (and the original poster of this thread) are not the only ones who would like this functionality added (to the mega menu, at least).

Chris, you’re right on the money with that one. I just checked and it appears that WP engine offers free SSL certs via Let’s Encrypt.

Thanks for the heads up!

I just thought I’d follow-up with the solution to my problem.

For context, I host my WordPress website on WP engine, which takes many precautions to prevent hacking and make WordPress more secure. One of the things it does is force HTTPS in the admin dashboard, even if the WordPress Address (URL) and Site Address (URL) options are set to HTTP URLs.

Unfortunately, the tagDiv Composer plugin loads the iframed version of the site (in the whole drag-and-drop editor interface) via the protocol specified via those WordPress options (found under Settings -> General), and not via the protocol that’s being used to access the dashboard.

Changing the protocol in both of those WordPress settings appears to have resolved the issue, but it seems that I’ll likely need to purchase an SSL certificate for the front-end of my website when it eventually goes live, so the change I made to those options doesn’t produce insecure content warnings.

I’ve asked tagDiv to just modify their plugin slightly to load the iframe via the same protocol as the parent (of the iframe) page, as that would resolve the issue in code, rather than having to do so via a particular setup of options (which are stored in the database).

As of now, I haven’t received a response on that, so who knows if that change will be implemented.

[EDIT] I also realized that once my site goes live at the real domain (and not a subdomain of wpengine.com), the admin interface will revert back to HTTP (unless I purchase and implement an SSL certificate, which could be used on the front and back end anyhow), so this is only really a problem during development, but that’s when I will be doing most of the work in the tagDiv Composer plugin anyway.

• This reply was modified 8 years by airdailyx.

Thanks Simion. I’ve just sent that email.

Some additional information. Since we host with WP engine, we are provided two different environments to work with (production and staging). Both are available for you to troubleshoot with and use the same access credentials. I’d recommend troubleshooting via the staging environment, as that doesn’t use a forced HTTP -> HTTPS redirect for the WP dashboard, as the production environment does.

You’ll notice that using the staging environment, you can switch between HTTP and HTTPS at will and the tagDiv Composer will work, and not work, respectively.

We’ll stay out of the website for now, so you can do your thing. Please let me know what you find out, and if you find a fix, please let me know what it was. I’ve created backups of each environment moments ago so I can restore them following your troubleshooting process, if need be.

Thanks very much!

Simion,

Thanks for your reply. I might have to hold off for the moment. I have a commitment to a client to start customizing the template a little bit so they can review it (by end of day today), so I wouldn’t want two people in the backend at the same time, or someone futzing with stuff when I know a client will be looking at the site.

If you’re confident that you could jump in there and investigate (and potentially resolve) within the next two or three hours, I’d be happy to provide those credentials. Otherwise I may have to hold off for a day or two.

Let me know. Thanks!