Menu
▾
▴
phpwebsite-developers
|
From: <php...@li...> - 2002-11-21 20:08:07
|
As I spoke of earlier, Boost and Setup have been rewritten. The division of tasks for creating a new installation are now clearly defined within their own modules. I changed all the install.php files for all the modules in the system so you shouldn't have to touch anything. I have tested the modules and they all appear to work. Please test however. Here are the changes: Layout is handled by its own file: layout_info.php It is still the same format as what you had in mod_info.php You can't define what your install/update/uninstall files are in your mod_info. It is just install.php uninstall.php update.php The update scripts have been started but they need more testing. I have it working with Calendar. Once I get nailed down, I will supply a demo of how it works and we can start updating regularly via CVS or downloads. I will now concentrate on the branch module which won't work BTW until I fix it, but I figure no one is really using it so... CYA Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: <php...@li...> - 2002-11-21 20:28:12
|
You truly are the King of kings. Excellent. Don. On Thu, 21 Nov 2002 php...@li... wrote: > As I spoke of earlier, Boost and Setup have been rewritten. The division > of tasks for creating a new installation are now clearly defined within > their own modules. I changed all the install.php files for all the modules > in the system so you shouldn't have to touch anything. I have tested the > modules and they all appear to work. Please test however. > > Here are the changes: > > Layout is handled by its own file: layout_info.php > It is still the same format as what you had in mod_info.php > > You can't define what your install/update/uninstall files are in your > mod_info. It is just install.php uninstall.php update.php > > The update scripts have been started but they need more testing. > I have it working with Calendar. Once I get nailed down, I will supply a > demo of how it works and we can start updating regularly via CVS or > downloads. > > I will now concentrate on the branch module which won't work BTW until I > fix it, but I figure no one is really using it so... > > > CYA > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Email: ma...@tu... > URL: http://phpwebsite.appstate.edu > Phone: 828-262-6493 > ICQ: 141057403 > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > > |
|
From: Eloi G. <el...@re...> - 2002-12-01 06:08:43
|
How do I get my module displayed under "Your Modules"?
After I install ArticleManager (new module -- you'll see it after I get this
fixed), it doesn't show up in "Your Modules". I tried tracking the problem
but I reached a deadend when I thought that it was because module display
is hardcoded into mod\users\templates\forms\admin_menu.tpl
I used Adam's PageMaster framework & setup files as a template and as you
can see, they show up identical in the Modules table. The module -is-
installed. When I call up it's index.php manually it works. It just won't
show up in the module list.
Generation Time: Nov 30, 2002 at 09:25 PM
Generated by: phpMyAdmin 2.3.0
SQL-query: SELECT * FROM `tb_modules` LIMIT 11, 30;
mod_title articlemanager pagemaster
mod_pname Article Manager PageMaster
mod_directory articlemanager pagemaster
mod_filename index.php index.php
admin_op &MASTER_op=main_menu &MASTER_op=main_menu
user_op NULL NULL
allow_view a:2:{s:4:"home";i:1;s:14:"articlemanager";i:1;}
a:2:{s:4:"home";i:1;s:10:"pagemaster";i:1;}
priority 50 50
mod_icon articlemanager.gif pagemaster.gif
user_icon NULL NULL
user_mod 0 0
admin_mod 1 1
deity_mod 0 0
mod_class_files a:3:{i:0;s:18:"ArticleManager.php";i:1;s:11:"Artic...
a:3:{i:0;s:14:"PageMaster.php";i:1;s:8:"Page.php";...
mod_sessions a:3:{i:0;s:14:"SES_ART_master";i:1;s:15:"SES_ART_a...
a:3:{i:0;s:13:"SES_PM_master";i:1;s:11:"SES_PM_pag...
init_object NULL NULL
active on on
version 1 1
update_link NULL NULL
branch_allow 1 1
|
|
From: Eloi G. <el...@re...> - 2002-12-01 06:08:46
|
I found it! Module display -is- hardcoded into admin_menu.tpl. I had to logout and log back in for the template change to take effect. But why? Do I have to register with someone before I can release the modules? Eloi George |
|
From: Matthew M. <ma...@tu...> - 2002-12-01 15:32:39
|
> I found it! Module display -is- hardcoded into admin_menu.tpl. I had > to logout and log back in for the template change to take effect. > > But why? Do I have to register with someone before I can release the > modules? Not at all. There is a tag to automatically show all of the modules. However, then they cannot be placed within certain windows. To get the orderly effect that you see, we had to place the modules one by one. If they are all listed in a row without text, it was confusing. If the text is included, it looks horrendous. I am open to a standard if you guys/gals can agree on one. There could, by default, be subsections. They need to be kept down to a minimum however. Currently I suggest: 1) User Modules 2) Deity Modules 3) Site Admin Modules 4) Content Modules (which is how it is currently set). We could set it so that you could chose what category your module should appear within the layout_info.php file. Let me know how you would like to do it. Matt Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 phpwebsite.appstate.edu ess.appstate.edu > > Eloi George > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: Eloi G. <el...@re...> - 2003-05-01 06:50:47
|
Hey all. I had the weirdest dream. At one point I'm riding a bicycle (badly) through the surf & this narrator kept repeating over and over something about every time a query is received the mySQL server has to parse, optimise, build tables, access, analyze & report data. When I woke up, I trundled over to my system & inserted this line in database.php @line 92: echo $sql.'<br />'; What I saw next really troubled me. My 0.91cvs testbed homepage queried the server 1,061 times! I next called up an Announce article (http://www.realvidreams.com/testbed/index.php?module=announce&ANN_user_op=v iew&ANN_id=42) and the query count dropped to a still hefty 462 times! I could understand if the server was busy pulling up relevant data, but a lot of the queries were duplicates! Take this for instance: select * from 4_modules where mod_title = 'calendar' Did that really need to be done 63 times to create 1 homepage? This was almost rivalled by: select * from 4_cache where mod_title = 'calendar' and id = '4124aabad14bfcc1d0d0b8840b98b0b1' which showed up 29 times! MenuMan was another area of concern. If we need to build a tree it would be better to load all data into memory, assemble the relationships and immediately unset() whatever data we don't need. Especially if your SQL server is on a different machine or (Oh God, No!) behind an ODBC driver. That method would also cut down significantly on the 206 queries that were generated. The cache table was queried 717 times. Of that, stuff was selected 120 times, inserted 149 times, & deleted 299 times. My sleep-addled brain didn't want to find out what happened on the remaining 149 queries. Would phpWS still work if it wrote to the cache -after- it finished working with all the data? Menuman & Calendar seem to be the biggest culprits, but I'm also seeing duplicates of queries like these: select * from 4_modules where mod_title = 'fatcat' select * from 4_modules where mod_title = 'comments' where just doing a global SELECT and storing the values in memory can reduce the query count by 74. All this leads me to believe that phpWS's performance problems are more due to excessive database usage than classes. -Eloi- |
|
From: Don S. <do...@se...> - 2003-05-01 12:06:58
|
While yes that is disturbing, I thought we were trying to cut down on memory usage? Or do you mean store them in memory just for that page load and then destroy them? Don. On Thu, 1 May 2003, Eloi George wrote: > Hey all. > > I had the weirdest dream. At one point I'm riding a bicycle (badly) through > the surf & this narrator kept repeating over and over something about every > time a query is received the mySQL server has to parse, optimise, build > tables, access, analyze & report data. > > When I woke up, I trundled over to my system & inserted this line in > database.php @line 92: > echo $sql.'<br />'; > > What I saw next really troubled me. > > My 0.91cvs testbed homepage queried the server 1,061 times! I next called > up an Announce article > (http://www.realvidreams.com/testbed/index.php?module=announce&ANN_user_op=v > iew&ANN_id=42) and the query count dropped to a still hefty 462 times! > > I could understand if the server was busy pulling up relevant data, but a > lot of the queries were duplicates! Take this for instance: > > select * from 4_modules where mod_title = 'calendar' > > Did that really need to be done 63 times to create 1 homepage? This was > almost rivalled by: > > select * from 4_cache where mod_title = 'calendar' and id = > '4124aabad14bfcc1d0d0b8840b98b0b1' > which showed up 29 times! > > MenuMan was another area of concern. If we need to build a tree it would be > better to load all data into memory, assemble the relationships and > immediately unset() whatever data we don't need. Especially if your SQL > server is on a different machine or (Oh God, No!) behind an ODBC driver. > That method would also cut down significantly on the 206 queries that were > generated. > > The cache table was queried 717 times. Of that, stuff was selected 120 > times, inserted 149 times, & deleted 299 times. My sleep-addled brain > didn't want to find out what happened on the remaining 149 queries. Would > phpWS still work if it wrote to the cache -after- it finished working with > all the data? > > Menuman & Calendar seem to be the biggest culprits, but I'm also seeing > duplicates of queries like these: > select * from 4_modules where mod_title = 'fatcat' > select * from 4_modules where mod_title = 'comments' > where just doing a global SELECT and storing the values in memory can reduce > the query count by 74. > > All this leads me to believe that phpWS's performance problems are more due > to excessive database usage than classes. > > -Eloi- > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > |
|
From: Matthew M. <ma...@tu...> - 2003-05-01 12:14:09
|
> Hey all. > > I had the weirdest dream... I will run the same test today and see if I can eliminate some duplicates. Matt |
|
From: Matthew M. <ma...@tu...> - 2003-05-01 12:45:47
|
Some of the reasons you are seeing all these extra SQL calls is that we received another warning a few months ago. That warning was that we were using far too much memory. So we reduced the dependance on the GLOBALS array. For example, the Cache used to store the information in the GLOBALS array so it would not have to be called more than once. This was removed to reduced the size of the GLOBALS array. Now the DB is called each time. So the question is, which is it? Do we want to depend upon the database each time to get our information? Or do you want offload some of the work by storing results in GLOBALS? Now that we know that classes eat up most of the memory, we may decide to place some data back and reduce DB calls. Matt |
|
From: Eloi G. <el...@re...> - 2003-05-01 20:07:20
|
Wow. You got on that immediately. Every day you find more ways to impress me! > Some of the reasons you are seeing all these extra SQL calls is that we > received another warning a few months ago. > > That warning was that we were using far too much memory. So we reduced the > dependance on the GLOBALS array. Yes, but I thought the warning was more about -duplicate- information being stored. > So the question is, which is it? Do we want to depend upon the database > each time to get our information? Or do you want offload some of the work > by storing results in GLOBALS? I personally feel that the DB always needs to be treated as a bottleneck by encapsulating the work to be done in each - the DB should handle ordering & filtering and the accesses should be as gross or greedy as possible. All other manipulation should be done on the front end. All data retrieved should be freed from memory as soon as it's not needed - if I query data and fetch_ it into an array and then pass it by value to another function to write to other variables, then there's probably 3 or four copies of the data hanging around before the PHP compiler starts garbage collection. Others may feel different, so I agree with your choice to let us select our method in the cache config. > Now that we know that classes eat up most of the memory, we may decide to > place some data back and reduce DB calls. That'd be great! -Eloi- |
|
From: Eloi G. <el...@re...> - 2003-03-19 03:34:52
|
$_SESSION["OBJ_approval"]->unregister_module() seems to be missing. Eloi George |
|
From: Matthew M. <ma...@tu...> - 2003-03-19 12:56:50
|
> $_SESSION["OBJ_approval"]->unregister_module() seems to be missing. Ah correct. I think I missed it because there isn't a register module anymore, but you certainly might want to dump pending approvals if you are uninstalling a module. i will add it. |
|
From: <ad...@tu...> - 2003-03-19 20:20:07
|
Since approval is a core module and will always be present, why not have Boost automagically remove any pending approval requests for the module being uninstalled instead of having module writers put the call to unregister_module() in their uninstall.php file? Adam >> $_SESSION["OBJ_approval"]->unregister_module() seems to be missing. > > Ah correct. I think I missed it because there isn't a register module > anymore, but you certainly might want to dump pending approvals if you are > uninstalling a module. > > i will add it. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink? > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > -- Adam Morton Developer - Electronic Student Services http://phpwebsite.appstate.edu Founder - Appalachian Linux Users Group http://alug.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2003-03-19 20:22:09
|
> Since approval is a core module and will always be present, why not have > Boost automagically remove any pending approval requests for the module > being uninstalled instead of having module writers put the call to > unregister_module() in their uninstall.php file? Sounds like a plan. Matt |
|
From: Matthew M. <ma...@tu...> - 2003-05-01 13:16:14
|
Update: I have added another variable to the cache config file. Setting GLOBAL_CACHE to TRUE will create a global variable that will store that page's cache calls. Information in that array will be returned instead of accessing the database. If you prefer to always use the database, setting this to FALSE will allow it. If you prefer not to use caching, turn it off. If you prefer not to use page caching (caching templates instead of accessing the files) you can turn this off as well. Matt |
|
From: Matthew M. <ma...@tu...> - 2003-05-01 14:01:02
|
Update: Found some repeaters. Some old code that need fixin'. Matt |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X