Late Sat Night and All is Sort of Well
Posted on Sunday 14 August 2005
I just posted this in the PN forum for developers:
As a learning exercise I’ve been making some small changes to the Example module – added columns basically at this point, changed the name of some variables. Anyhow I couldn’t get it to initialize at first because of a T_ENCAPSED_AND_WHITESPACE error. Which in searching the forums I realized is basically a typo type error.
But I combed over it against the original Example module and could find anything. Because the error was in the upgrade function I decided to delete all of the upgrade functionality in my module and — it worked! (other problems abound but it initialized fine). I guess my question is – the .760 example module is much updated but there was some text to the effect that the upgrade function hasn’t been (”/ This is the old form to make an update. It depends on the data // base that we are using.”).
Any chance that there is something that needs to be reworked with the upgrade code in the example module? (Or is it just likely I did mess something up and couldn’t find it)
As for pnLibrary tonight – it initialized and I was able to enter an entry. I see the entry in the database (via PHPmyadmin). I need to change pnINIT not to make the tid column an index – that’s already covered by the fact that it’s the primary key. What is messed up tonight is that the display side of the module isn’t showing the entry at all. Hmmmm….
Well better progress than last night’s slide off track. Baby steps, baby steps.
Properly Using the Postnuke Prefix
Posted on Saturday 13 August 2005
When you install PN you give it a “prefix” – usually nuke or PN which is tagged to the beginning of all the database tables. I believe this is to allow for multisite installs so that other sites can use tables with other prefixes. I think anyhow.
In any event I knew this needed to go before table names but was unclear on column names. This forum thread seems to state that it is not a requirement for column names. Looking at this and also the treatment of the $prefix string in the third-party “databases” modules I think I have a handle on multiple table mods for the pntables and pninit files. (Databases was written by the cold-rolled steel guy – I’ll find a link for it later. Interesting mod but ultimately couldn’t make use of it at this point. I think the idea behind it and the guy’s database display module and also I know there’s a form module out there – well those three together could mean complete and total flexibility for administrators if they were robustly featured and user friendly to administer. Probably a pretty challenging job to do all of that though…)
Properly Using the Postnuke Prefix
Posted on Saturday 13 August 2005
When you install PN you give it a “prefix” – usually nuke or PN which is tagged to the beginning of all the database tables. I believe this is to allow for multisite installs so that other sites can use tables with other prefixes. I think anyhow.
In any event I knew this needed to go before table names but was unclear on column names. This forum thread seems to state that it is not a requirement for column names. Looking at this and also the treatment of the $prefix string in the third-party “databases” modules I think I have a handle on multiple table mods for the pntables and pninit files. (Databases was written by the cold-rolled steel guy – I’ll find a link for it later. Interesting mod but ultimately couldn’t make use of it at this point. I think the idea behind it and the guy’s database display module and also I know there’s a form module out there – well those three together could mean complete and total flexibility for administrators if they were robustly featured and user friendly to administer. Probably a pretty challenging job to do all of that though…)
First A Single Table But I Will Need A multi-table Module
Posted on Saturday 13 August 2005
Here’s a great post from Mark West showing how to loop through multiple tables in the pninit file in .760.
Reboot Module Work – This Time From the .760 Example Module
Posted on Saturday 13 August 2005
First off – I’m going to restart this effort using the Example module included with the .760 Release Candidate 5 – this is supposed to be the last pre-final version and we should see a production ready version of .760 in release very soon. Hard to imagine I will finish module work before that.
Cruising through the PN developers forum I found a link to a possible cause of my “blank page after trying to run pninit” last time.
Might have been as simple as a few stray spaces at the end of the file.
Also with .760 there’s a different terminology for describing the MySql columns that I’m not familiar with – it uses I, C, T (integer, character, text I assumedatetime or timestamp) and L (what’s L? Boolean integer field, i.e, “1″ or “0″) and possibly more. So far I can’t find any quick reference to this.
UPDATE – found a good forum thread which points to a file included with the PN install that shows the list of calls to make. This is all about working with the ADODB layer I guess (something I’m not familar with at all).
And a huge document on ADODB can be found here at phplens.com.
Nothing Doing: POSTNUKE STILL BAFFLING
Posted on Friday 12 August 2005
I’ve made strange and unknowable errors at this point. I realized I was being very ambitious to try and build the module I want on my first go. So I back off – aiming simply to rewrite the EXAMPLE single table module to include more fields.
Lots of errors so far. TO start off with lots of blank screens. I wasn’t expecting that – it looks like from the code that you should get success or error messages at every step. So NO idea why I’m getting blank pages.
The mod did initial properly but I’ve no idea why. I tried to initial it several times and got blank screens. Then at some point backing up or reloading or something I did get the intialization successful message. Activation worked ok after that.
But right now – I can pull up the admin new function but it goes to a blank screen when I try to send the form input and that’s that.
I’ll have to take a step back and look over everything again I guess. I wonder if there’s an obvious mistake I’m making?
Conceptually the POSTNUKE Module in a Nutshell (PN Part 2)
Posted on Friday 12 August 2005
Just a warning – I’m figuring this out so read these entries with a little caution. I’m a total newb at all of this. On the other hand that might be where you are right now too so we can sink or swim together…
Conceptually I think I understand now how a POSTNUKE mod works. Sort of. Putting aside the file to initialize the module you’ve got four key functional files. User, Admin, UserAPI and Admin API. User and Admin handle the interaction with people and their API cousins help do the actual behind the scenes work. Maybe – actually I’m not sure I really understand how these all work together exactly. However I do see how the User and Admin files have basic default view, view items and display of individual items. Admin is where you add items, modify and delete items as well as change any configuration settings for the module as a whole. Both of these files work in tandem with pnRender template files that pull in user-generated info from forms and/or display the information to the user.
So POSTNUKE seems to have a pretty good separation between the functionality of moving around information from how it’s displayed (i.e., templates) to the public. This certainly makes more sense to me now that I’ve read through all of the EXAMPLE module files and begun to rewrite to reflect my table structure for my Library Module (unless there’s another one out there already named I’m going to call it pnLibrary).
UPDATE – a good explanation of admin relationship to adminapi:
Well taking a look at the above I am not sure you are following API standards. Ok so the above function is yes indeed and Admin fucntions, but it would appear you are trying to do work in the Admin function and not in the AdminAPI function. The standard method is to break things into sections so you should have an Admin function that would produce a form to the user and then that function should call to the AdminAPI fucntion where you actually do your DB work and then return you results to the correct Admin function for a display message like “Hits cleared and Reset to X”. Can you post both sections of your code if you do indeed have your hack setup as being fully API compliant??
Into the Postnuke Wilds (part 1)
Posted on Friday 12 August 2005
I’ve used Postnuke for Comixpedia since that site was started in 2003. And I’ve gotten by without having to write a lick of code (I’ve tinkered with some blocks though for presentation purposes). Well there just wasn’t anything like the creators library I wanted to add to the site. So it’s been a summer of learning PHP, casting about for scripts and ideas and really anything that would have let me avoid writing a POSTNUKE module from scratch. No dice.
So now I’ve been going through the EXAMPLE module for POSTNUKE and flipping between a couple of recent modules with multiple tables and the POSTNUKE .750 API (please don’t let .760 change too much for me!) and while I’m not 100% confident that this will workout without hiring help at some point I had a definite moment this week where the php code went from looking like gibberish to actual language. Literally I went from looking at a foreign language where I had to translate each word to something in english.
Anyhow I think I’ll post anything interesting I learn from this – while POSTNUKE and other open source projects are awesome they’re not always the easiest to navigate in terms of learning how to add to. The programmers I’ve encountered on the POSTNUKE forums, so far, have been pretty cool though (I’ve kept my questions narrow – that’s probably helped not annoy anyone). Right now I’m working the administration functions. In this first version I’m only including a limited set of functions to see if I can pull that off. If so I’ll go back and rewrite the full module I need.