Here’s the a quick fix for the loadExtension:
<?php
// loads an extension from the extenders folder
function loadExtension($extname){
global $base_path;
global $database_type;
$xpath = $base_path.'/manager/includes/extenders/';
$objName = strtolower($extname);
$clsFile = $xpath.$objName.'.class.php';
if($extname=='DBAPI' && !isset($this->db)){
include_once($xpath.'dbapi.'.$database_type.'.class.inc.php');
$this->db = new DBAPI;
}
else if($extname=='ManagerAPI' && !isset($this->manager)){
include_once($xpath.'manager.api.class.inc.php');
$this->manager = new ManagerAPI;
}
// support for addtional extensions - by Raymond
elseif (!isset($this->{$objName})) {
if(!file_exists($clsFile)) return false;
else {
include_once($clsFile);
$classname = $extname.'_Extension';
$this->{$objName} = new $classname;
}
}
return true;
}
?>
It’s also available in SVN.
@susan: I think MODx (in it’s current state) does not need to connect to the DB when working with cached documents that does not require a DB connection. The system is designed to connect to the database whenever the $modx->db->query() function is called. This means that any call to the $modx->db select, insert or update functions will automatically connect to the database with requiring an explicit call to the connect() function.
This whole db thread
Surely MODx needs to look up what FURL is what ID so it knows which cache to load in?
Capitalisation
I was concerned Raymond’s fix would break "getUserData.extender.php", but I see that’s in the code as:
include_once $this->config["base_path"]."manager/includes/extenders/getuserdata.extender.php";
(around line 1476 of document.parser.class.inc.php). So the file needs changing case - either the file itself or the reference. It looks like it should be the file itself, if only to stop others from thinking mixed-case files will work as extenders.
Picking oneself up in a bucket
Quote from: rthrash at Aug 21, 2006, 08:05 AMWhy would writing a manager in MODx be a potentially bad idea based on an early beta test of brand new functionality?
Because I would be unable to log in and less able to ascertain the fault (given that error messages only appear to manager users). I was too harsh, I think that the theoretical issue is relying on one manager. We may ultimately need some kind of emergency manager that we could upload for debugging purposes. In fact actually that idea’s growing on me.
Recursive Parser Documentation
In a few places says Italian plumbers’ nemesis BOWSER rather than the less easily conquerable BROWSER.
0.9.5 is looking good!
-
MODX Staff
- 12,272 Posts
What all changes need to take place from a case perspective now? I’m a bit confused on that topic. I’ll make them and get out a test build pronto.
Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
File "manager/includes/extenders/getUserData.extender.php" to "manager/includes/extenders/getuserdata.extender.php"
Change the actual file.
Ah, that reminds me there’s a bunch of spelling changes I need to commit. I have some notes on the content/snippet calls, I think that side of things is worthy of a separate thread, so I’m starting one.
OK, I’m not starting a new thread just yet, primarily because my snippet cache keeps gnarlsing up which makes checking the site annoying, but also because I’d like to agree what the objectives are first.
I think there are three areas that need changing with the default content:
1) Update snippet usage to Ditto, Wayfinder etc.
2) Replace textual references to DropMenu etc with brief introductions to Wayfinder.
3) Improve the content so that there is greater consistency in level of detail given and knowledge assumed.
Here’s a list I knocked out earlier, which should hopefully help with 1).
SNIPPETS/CHUNKS USED BY DEFAULT CONTENT
key: (documentID) {chunkID} tTemplateID
Line 36: (3) NewsPublisher {FormBlog, FormBlogComments}
Line 39: (2) NewsListing {FormBlogComments, nl_blog}
Line 42: (4) WebLogin
Line 45: (6) ContactForm
Line 48: (7) DropMenu, FlexSearchForm
Line 51: (5) WebSignup {FormSignup}
Line 54: (8) FlexSearchForm
Line 60: (11) NewsListing {FormBlogComments}
Line 66: (15) DropMenu
Line 90: (15) WebLogin {FormLogin}
Line 96: (39) DropMenu
Line 140: {10} UserCommentCount, UserComments
Line 200: t3 DropMenu
Line 203: t1 DropMenu, DropMenu, AjaxSearch, NewsListing, WebLogin
Line 206: t4 NewsListing, ListIndexer, WebLogin, AjaxSearch, MODxHostMenu
Line 57: {9} {FormBlogComments}
Line 87: {26} {FormBlogComments}
Line 96: (39) {styles}
Page 22 (DropMenu Examples) contains a snippet call example that will also need changing.
--
I like the aim of the default content: "an adequate starting configuration for many small business, organization or personal websites; just change out the template and you’ll be good to go!"
I like there being a demo of each snippet.
However, the home page says "Click the bold title links to learn more about the following features", and then has a very varied set of ways to learn more. Some are an example of the feature in action, and I think these work best. Others are very dry, and they don’t particularly related back to MODx. The Scriptaculous page doesn’t sell the benefit of it being included in MODx, and I’d rather this linked to MODx examples (or pointed out how it was used in the default site). The QuickEdit page is ludicrously long - this needs replacing with a quick guide to how to find it and a reminder that there’s an FAQ on the module page.
I’m much less keen on the two links that highlight parts of the page; it’s not clear what is happening, particularly if you’ve scrolled past the search bar. This is also inconsistent. I’d rather these were links at the end saying "Highlight feature".
MODX Staff
