WordPress Integration - Plugin or Theme creator

I’m guessing you have heard about this type of request before. I’m going to bring it up again because I believe that Tumult would make a BOAT LOADS of profit if you figured out a way to integrate Hype with WordPress.

The following capabilities would be Earth shattering in the WordPress community.

  1. Theme export
  2. Plugin export (example, exported slideshow becomes installable plugin that grabs content from a post type.)

If Tumult created software that would do this it would SHAKE the WordPress community. I’d buy this app for $300 without blinking an eye.

Hire three programmers. Offer them 90K / year + healthcare. Explain the task get a program up and running. Sell it for $300. Within the first week I guarantee 1,000 buyers. Boom! software built programmers paid.

I don’t think you guys realize how much money you could make from this. I’m not kidding. It’s a huge opportunity.

Here a plugin for WP
in this page some demos for the iframe

the iFrame embedding directly in a theme is not easy and if you change the template you loose also the iframe. maybe better an external plugin to manage the iframe in all most important plugin like visual composer, elementor and so on.

So. the best way is improve tools in WP and not in Hype, an intelligent iframe with responsive behavior and the view-point detection of elements during the scroll ( in iframe) would be the best solution

I’m not convinced your on the same thought as me. I’m not looking for a way to show a Hype animation on WP. I can do that all day long. I’m fully aware of that plugin for WP. It really does not work but that’s not really the topic at hand.

My desire is to establish a database connection with HYPE and WP. For example, you build a cool slideshow with interesting transitions. You click a button and a plugin zip is created. The plugin creates a custom post type that allows you to add images from the media library.

Understand where I’m coming from? Hype would be HISTORIC I mean EARTH SHATTERING if it had this kind of capability.

If you could design it to grab data from a table in the WP database Hype would be a win.



What could be done is to write an exporter script that adds some “envelope” so that a Hype animations is packed as a plugin and has some stubs to write variables to HTML that renders directly in the plugins output. But this script would require you to have a local PHP environment and continuously overwrite it in your local plugin folder to develop it. To test and develop it’s functionality online would be even worse as you would need to continuously reupload the exported file over and over again to your server and that wouldn’t be nice.
As most don’t run a local PHP/WordPress (MAMP does the trick here if your interested) the later would be the workflow for most… undesirable.

Either way there is a simpler solution. Just load the data through the WordPress API (see PHP wordpress / Database integration) and test your Hype file as usual in your Hype editor using “preview”. Once all is good with the dynamic data publish using the Hype WordPress Plugin (we need a Gutenberg Block).

Also have a look at the “HypeCMS” thread discussing ways to replace images and text How to make a whole editable website with Hype

One thing missing in Hype is dynamically adding symbols to generate multiple instances based on data you receive (for example cards, rows etc.). Hype itself can only work as a “static” template meaning fixed amount of interactions, pages or slides etc you position beforehand. You can overcome this with code and render or duplicate content manually as HTML but that doesn’t support the Hype goodies as timelines, actions and layout.

1 Like

Quote from other thread moved over here.

You actually don’t really need to optimize the .oam file as it gets unpacked and takes up some space on WordPress. But only the needed files are actually referenced in the rendered output.
I’d like an option that in it’s simplest form allows to overwrite the location of the runtime for all uploaded widgets. This could be a folder on your own library or a CDN folder. Surly it doesn’t override the version but you can change the folder containing runtimes. Also when unpacking… the runtimes in the .oam files could be all additional copied to a single folder on your wordpress installation. Potentially you accumulate all runtime versions of uploaded files and then could point all your widgets to that folder to load their respective runtime version. This would benefit sites with multiple widgets as they start profiting from cached calls.

I was just investigating this on a site and each runtime is referenced only once per version even though Hype widget specific instances are referenced. The HYPE_DocumentLoader (loadScriptIfNecessary) is seeming to look if the runtime version (string) is defined in the page (window) already and discards double request. Nice Job. So this feature request seams actually resolved. Correct me if I am wrong.

One thing to consider is that if you edit widgets over time is… you will have to render all widgets with the same Hype version and re-upload them all. Otherwise you will be accumulating around the full size (around 60-100) KB for each runtime version needed for older uploaded Hype .oam widgets. There is currently no way around this “bug” other then re-uploading all Hype .oam file after a fresh export (assuming that the most current runtime isn’t always backwards compatible).

This is correct. To be more specific, it is correct as long as one is using a <div> method of embedding the animation in wordpress. If you use the iframe method it won’t know about the other runtime.

The document version is explicitly tied to the runtime version, so uploading both files together is required as you say.

My thought is that in general we want to be very efficient across the network, but web server storage space is cheap and spacious so having extra/redundant files on disk isn’t the end of the world given the other tradeoffs Hype makes.

True, that’s not the ‘bug’ I mean. It’s rather an “notice”. I use Hype on a client site with multiple individual widgets and had to update them over time so I started accumulating more runtimes as. To all widgets have been updated at once. I got 9 widgets on the site and in the end I had around 4 runtimes loading.