PERSCOM local install

[Jannes Drijkoningen]

We would love to interact with PERSCOM inside of our application. Our application is developed locally, but on local installs the marketplace is disabled. Is there any way we can run PERSCOM locally so that we can use PERSCOM sources and so on to build on top of it?

I suppose licensing would be another issue we'd run into if I were to just copy the PERSCOM application files from our production environment. Has anyone attempted this before? How would I go about getting the marketplace version of PERSCOM on our dev machines?

Thanks in advance.

[Jannes Drijkoningen]

Seems like everything is fine in terms of installing without a license, I just exported the application from our production and imported into my localhost dev environment.

There's just one thing... We can't enable dev mode without having the PERSCOM dev folder. Is there any way we could get these files so that we can create hooks and interact with PERSCOM code while running IN_DEV = true?

[Jon Erickson]

You will receive a licensing error once the cache expires (30 days) due to the installation path and URL not matching your license. I would highly suggest using the PERSCOM API that is built into IPB to consume the data you have stored on your live site. 

[Jannes Drijkoningen]

I assume you're talking about the REST API? Thus far we've always just edited the templates in our theme but we want to go way more in-depth, building an expansion of PERSCOM for our specific needs, working really closely with PERSCOM code. We already migrated a big chunk of our modifications to an application, but we've been holding off on those that require template modifications. So far, it's been smooth sailing with PERSCOM code and it's a lot more semantically correct, more maintainable and a lot more comfortable for a developer to work on.

Our previous implementations used the REST API and hackish JavaScript implementations to achieve our goals, but as these modifications grew out of proportions we really needed a more solid foundation so we started developing our own application to fill the gaps.

As far as my knowledge goes, the dev folder just holds all the files that you can find in the backend/theme area anyway. It could be extracted using something like the IPS Dev Toolbox but it seems like they're not entirely compatible with 4.6 yet as it's giving me some errors at the moment that I didn't have on 4.5 so I've had to disable that application.

Getting it from the source, Deschutes, will probably be the most accurate anyway. So if you won't provide these files, we'll simply have to look at these alternative methods of extraction or manually convert what we can from the default theme.

 

As for the licensing error. On the top of our development version (localhost) we have a banner notifying us we've got a limited PERSCOM development license and limits may apply. Which is fine, it's just for development, nobody but the developer will see that. We never entered any license and didn't copy the database. It's a completely fresh IPS install and fresh PERSCOM install. If it gives issues in 30 days, we can just repeat the process to refresh it I assume?

[Jon Erickson]

Yes, I am referring to the REST API.

As far as the source files, unfortunately, those are kept in-house and are not public, including the dev folder. It would give a user complete access to rip of PERSCOM and copy the application. Obviously, this probably would not be an issue but we have to draw the line somewhere. 

Yes, PERSCOM is 4.6 compatible. IPS Dev Toolbox is not even 4.5 compatible.

Are you developing a custom IPB application or completely separate from IPB?

As for the licensing error, no, you will not get an error if you are just using the development license. You will just be restricted in the amount of data that can be added to the application.

 

[Jannes Drijkoningen]

Ok understandable. The dev folder shouldn't contain anything "secret", it's simply what builds up all the XMLs and JSONs that are then used to load the default theme files, emails and translations in the database when you install the module or revert to the default templates. So that's why I brought up that we can get them anyway, it's just be much simpler if it could be shared so 3rd party developers can run a development IPS environment with PERSCOM installed & enabled. Now we constantly need to switch IN_DEV on to do our changes, build our app, turn IN_DEV off and then see if it worked if we're working on PERSCOM hooks for example. It's a major pain to debug.

And yes, it's an IPS application, same as core, forums, pages and PERSCOM. So we can interact with everything on a deeper level and have our own controllers, templates, hooks, database schema, sources, settings,.......

[Jon Erickson]

On 7/19/2021 at 2:34 AM, J.Drake said:

Ok understandable. The dev folder shouldn't contain anything "secret", it's simply what builds up all the XMLs and JSONs that are then used to load the default theme files, emails and translations in the database when you install the module or revert to the default templates. So that's why I brought up that we can get them anyway, it's just be much simpler if it could be shared so 3rd party developers can run a development IPS environment with PERSCOM installed & enabled. Now we constantly need to switch IN_DEV on to do our changes, build our app, turn IN_DEV off and then see if it worked if we're working on PERSCOM hooks for example. It's a major pain to debug.

And yes, it's an IPS application, same as core, forums, pages and PERSCOM. So we can interact with everything on a deeper level and have our own controllers, templates, hooks, database schema, sources, settings,.......

Yes, exactly. The dev folder is the “source” for the compiled application and that’s why it’s kept out of the finished build process. Unfortunately I don’t see an easier way as well. But your case is extremely rare and not everybody is trying to develop an application to work with another. Haha. As long as you are not developing the front end, you can keep the application out of IN_DEV when you’re developing - which is where most of the work happens.