Latest Announcemnent
New thread

Official: WCDDL - The DDL Script

Status
Not open for further replies.
A 'search log' is built into v3 which can be outputted as recent searches, but only by your choice.

So if you want to completely avoid the new penalties, don't include it.

As for progress, i'm just doing the admin functionality now, I decided to make it all pretty much AJAX based so the actual admin page remains a single, clean file.
 
Nice so you know how in V2 you add links to the admin area

$core->admin_links = array_merge($core->admin_links, array('webmaster' => 'Webmaster CP'));

are they going to continue to be reload page or can they have the option of being ajax loaded too?

Not that it matters, just wondering and it would continue the ajax loaded theme.
 
It's a db configuration now.

PHP: 
Core::load()->config(array_merge(
     Core::load()->parseConfig('admin_links'),
     array(
           array('someURL', 'SomeText')
     )
);

Meaning you only need to call that one time, then it is stored in the db unless the user, for some reason, re-alters it (or another mod alters it in a way that removes your changes).
 
Last edited:
Right so with the admin links and other variables stored in the DB how do you suggest installing or importing mods?
Same idea for adding or modifying tables. Do you suggest mods have an install file run once to make table modifications and load these configs and then delete the install file?
 
You could either have an install file, or fetch the config each time and check if your changes still exist. If they don't, make them again.

So an admin module may look like so:
PHP: 
function myAdminPage($go) {
     if($go != 'myadminpage') return false;
}
function myAdminPageInit() {
     if(!Core::load()->config('myConfig')) {
          // check if my config is set, if not, set it
          Core::load()->config('myConfig', 'someValuesWoot');
     }
     $admin = Core::load()->parseConfig('admin_links');
     // Check here if $admin array contains your changes
     // if not, set them
}
Core::load()->hook('AdminHandleContent', 'myAdminPage');
Core::load()->hook('Init', 'myAdminPageInit');

Only slight inefficiency there is you run a query per page load.
To make it a bit more efficient you could only run it when the correct _GET['go'] is set.
This way it only runs on pages you need it to run on.

Because the Init hook runs on EVERY page, first thing almost.
 
ok forget that I cba with AJAX, im going offtrack here.

*goes in vim, presses '100dd'*

Time to start over.

RELEASE DELAYED BY A DAY
 
Last edited:
Good idea dropping the ajax. Having ajax will over complicate it and make it harder for less experienced webmasters to code mods and modify it.
The success of the script so far is in it's simplicity. If experienced webmasters want to add fancy ajax themselves they can.
 
Haha

It's because I implemented 100 lines of JS for AJAX requests and what not, but decided to scrap it and make it all standard instead of AJAX.

Now the admin page is way cleaner.
 
As I said before, 'delayed by a day', so hopefully today.

Mr Happy, here's an example admin module now:
PHP: 
function myAdminPage($go) {
     if($go != 'myAdminPage') return false;
     // output some html here
     // and handle things
}

Core::load()->hook('AdminHandleContent', 'myAdminPage');

This'll make your mod page display when ?go=myAdminPage.
 
No it is a configuration/setting in the database now.

You use:
PHP: 
Core::load()->config('name', 'value');
To set a configuration entry.

The admin_links entry contains an array of admin links, so you could do something like this in your mod:
PHP: 
function myAdminLinks() {
     $links = Core::load()->parseConfig('admin_links');
     $linksCount = count($links);
     $myLinks = array(
          array('?go=myAdmin', 'SomeThing'),
          array('?go=myOtherAdmin', 'Another Thing')
     );
     // I didnt use array_merge because it will allow duplicate entries
     $links = Common::arrayMergeUnique($links, $myLinks);
     if(count($links) != $linksCount)
          Core::load()->config('admin_links', $links);
}
Core::load()->hook('AdminInit', 'myAdminLinks');

Yes this is way more complicated than in wcddl2, but it means links are stored.

So you can either use something like the above method, or make a sort of install script, then run it once.

E.g. make an installMyMod() function and hook it so it runs on ?go=installMyMod.
 
Last edited:
I have feature suggestion JmZ. How about adding static page creator. A lot of people have DMCA, TOS, Advertise and other pages, so mod for that would be useful, I think. Also "installed by default" contact page would be nice. I know you try to keep it as small as possible but every download need contact and those pages I talked about.
 
Better idea. On the list modules pade can we have a link for each module that runs installMyMod function. Would also be cool to have a uninstallMyMod link. Maybe use if function exists so it only shows is these functions are available. That way all people have to do is upload the module and click the install link for it.

EDIT
A checkupdateMyMod function would be cool too though not necessary. If the returned code is_numeric the it checks with the version hardboard and displays the builtin message if an update exists
 
Last edited:
Hooks exist for you to implement such features.

You can make the update thing by hooking to the admin content, e.g. make an updateCheck page which loops through Core::load()->getModules() and checks each for an update method.

Example:
PHP: 
function updateChecker($go) {
     if($go != 'updateChecker') return false;
     foreach(Core::load()->getModules() as $module) {
          // $module is an array($filename, $path)
          // $filename being like 'wcddl_mymod.php'
          $name = substr($module[0], 6, -4);
          if(function_exists($name . '_updateCheck')) {
               $updateNeeded = call_user_func($name . '_updateCheck');
               if($updateNeeded)
                    echo $name . ' - UPDATE AVAILABLE!<br />';
          }
     }
}

Core::load()->hook('AdminHandleContent', 'updateChecker');
 
Last edited:
JmZ said:
Hooks exist for you to implement such features.

You can make the update thing by hooking to the admin content, e.g. make an updateCheck page which loops through Core::load()->getModules() and checks each for an update method.

Example:.....
Click to expand...

OK I know you can do that but it would be really cool if at least the install one was in by default. I remember with IPB 2.3 that you had to install a Plugin Manager first in order to be able to install and configure lots of modules. Most wouldn't work on their own. I know I could create a Plugin Manager like what the early IPB had to offer the install, uninstall, update options but I think it would be better if at least the install options were in by default.

Just do a config bit in the list modules that searches for the function eg configMyMod, as from that we can offer the other install/uninstall/update options/settings/whatever. It will only be 10-12 extra lines of code for you to have in the default script.

Let's be honest. At the moment list modules is sorta pointless. If you add the config link (if configMyMod function exists) it would give the whole area purpose and get rid of all those custom install files and other bloated crap that can come with modules.

OFFTOPIC:
Desperately disappointing that this is the only topic on WJ in the last week (probably longer) that has interested me in any way.
 
Yes but my point is, you can just hook your install function into AdminHandleContent as its own admin page, e.g. ?go=installmymod.

And if you want to set cookies, send headers, etc, in there, hook into AdminInit instead and check _GET['go'].

I don't want to make mods use a specific function name to install, i want them to hook in and make their own install page. It shouldn't be too hard.
 
That's a fair point. I see now why you don't want to do that and your probably right. I've another feature request. Again I don't mind if it's not added but I think it could be useful and I know this could easily be done as a hook but that relies on people adding it which most probably wouldn't so hear me out.


Why not include a submit api system by default that would return a json reply saying if submits were rejected and why. eg site is banned, not whitelisted etc or how many were accepted.

Then in three months or whenever you find time to update warezlinkers/auto you can have it give a far more accurate response. Right now it just says downloads submitted even if they are rejected by the DDL site. This is where rardownloads is slightly better as it tries to crawl the returned page and shows the error message if they were rejected. It's really useful.

With rardownloads and linkplz-auto now the top autosubmitters you could use this to regain ground.

It's also better for the DDL admin as by just returning a json reply it's less stress on the server.
Everyone wins. Interested to hear what you think.
 
Status
Not open for further replies.
Back
Top