SimplePortal
Customization => Custom Coding => Topic started by: Arantor on December 22, 2014, 12:46:28 PM
-
I'm working on my gallery, and I've built a custom integration for my gallery to expose a block to SimplePortal - I didn't have it patch PortalBlocks.php and extend sp_gallery() because everything else is done without file edits, and while I can provide code for SP to add to sp_gallery(), I'd rather not have to ask for it to be added when I can provide the support on my end (meaning that if I change APIs or anything, I can worry about maintenance myself without having to expect SP to do any maintenance or expect users to upgrade)
So, I found myself adding it to the database manually (which is fine), but of course there are going to be problems when uninstalling the gallery when there is a block in place.
What happens is that I expose a new function, sp_levgal(), which is added to smf_sp_functions, which is fine right up until the gallery is uninstalled, because sp_levgal() no longer exists and the portal throws a fatal error because of it on any page that it runs. (Including the admin panel if you try to edit the block because the function still doesn't exist)
Part of me thinks it might be an idea to have a function_exists call before running any block function because this does seem a bit fragile, though I'm aware that most mods don't bother to extend SP and expect SP to do the work (or use sp_php blocks)
In the meantime I can have my mod remove any such blocks on uninstall, I was just hoping I could figure out how to preserve the block settings in the interim.
Of course, if the SP team would prefer that I don't try to maintain such a block myself and would prefer to have the code I use integrated into sp_gallery, that's doable too, I just thought I'd keep all the workload on my side.
Would appreciate thoughts.
-
Hello and welcome to SimplePortal!
Unfortunately the parts of SimplePortal that deals with the blocks haven't gone through a real refactoring since the first time I coded them, like 5-6 years ago, at a time when I knew a lot less than the little I know today. So they aren't really pretty. We have been meaning to move towards a plug-in approach, which would make sharing and installing custom blocks a lot easy, but it never happened.
If we were doing more frequent releases, I would have wanted to add support for your mod in sp_gallery() function myself. In case of the other mods, I just get the data and output the data the way I want. For your mod, I could have made it more a like a wrapper, letting you decide what to show and how to show. However, I don't really know when we'll have the next release - it maybe in a few weeks or a few years.
So at this point, the best option seems like you handle everything with your mod. I'll certainly add a check to make sure the block functions exist before we use them. I'll be sure to let you know before we're releasing a new version too, to see if you have any ideas to make SimplePortal easy to work with when you are adding custom blocks.
-
Yeah, a plugin approach would be good :) Lemme know if there is anything I can do to help.
I have no problem handling everything in LevGal itself, it's more the interfacing and assumptions made that need to be born in ind, though I totally get how come the assumptions were made. And I figured keeping it on my side would minimise the workload on the SP team.
Adding to smf_sp_functions has some interesting consequences if not maintained; in addition to the function existing, it might also be an idea to check the language strings existing at least for the add-block page (since they seem to be made for the block list page, as it reports 'Unknown block type')
I'm also finding a side issue related to the calling of functions, which has consequences for testing for existence; large parts of my mod are in classes with an autoloader, in this case LevGal_Portal_SimplePortal, and for some reason the autoloader wasn't kicking in when I tried to set up LevGal_Portal_SimplePortal::execute as the function name. The language strings were fine, it existed and everything looked like it should work, but it couldn't find it when it tried to run, because for some reason it wasn't loading. I've solved it by creating a wrapper function but it is possibly something to bear in mind. Though it wouldn't surprise me to have made a mistake last night while tired (and now I have it working, I haven't changed it to try it out)
-
Fun fact, after examining both TinyPortal and PortaMX, SimplePortal remains the easiest to add support for new blocks/block types :)
-
That's good to hear, I know [SiNaN] will be proud.