Loading...
 
Development

Development


A little advice to the developers

posts: 19

I find that tiki sites can often be slow unless you have one kick ass server, hehehe. For example this server has a dog and we all know why. Tikiwiki intro advice is to kick your php memory at minimum of 32K!

I posted part of this in another thread, but wanted to make it a thread in itself.

There's a smart ways of having the dynamic capabilities that you presently have without killing the poor servers. As way of example, consider why computer programs are compiled. You might want to compile all the vast tags and such that the poor tikiwiki engine has to interpret on the fly. So whenever someone creates or edits a wiki page it would then be compiled. So the people visiting the site fetch the compiled version. I'm sure most of you have misunderstood what I'm trying to say, but I don't have much time.

Oh, and another trick, you should have development files and live files! For example, just the css file for tikimedia theme takes up 38K, but when you strip out all the comments you get 28K! It is a piece of cake to have a script strip out the comments. It's just common sense. In programming it's the little things that add up.

good luck amigos!
YT

posts: 1630 Canada

Hi YT,

Can you help with the source code?

M ;-)


posts: 19

Hi,

I have unfinished projects right now, so probably at a later time.

As much as I dislike wrappers, it might be a glorious easy fix for when a person edits or adds a tikiwiki page. This type of wrapper would merely be for page edits or new pages. So it's not a wrapper for page views. Some very brave programmer could write such a wrapper for the current tikiwiki. It's essentially a compiler. So site visitors would see a fast compiled/optimized version of the site. Of course the site would still use php, so I'm not talking about a static html site.

As comparison, machine language is a computer's lowest level language. So unless a client has a kick ass computer, it is wise to provide ones clients with compiled programs in machine language. Similarly, html (which includes javascript, dhtml and everything between the tags) is the lowest level language for a web browser. Therefore, it is wise to have compiled wiki pages optimized as such. This does not mean you cannot have dynamic content. You can still use php and modules. It just means that by the time the wiki page is live to the world it is optimized. The only part that is not optimized is when a person edits or adds a wiki page.

Basically the wrapper would be called whenever a page is edited or added. The wrapper would actually execute your present php pages, sort of like an on-server simulation. The wrapper would then gather the returned web page to be stored on the live site. Of course this would require some work because certain dynamic areas would have to work in parallel with the wrapper, such as the display of login name. Although you could actually make the display of login name a javascript. Also the date that is displayed on the tikiwiki site could be javascript.

As an outline
1. Replace the present edit/add tikiwiki page with a new wrapper.
2. Replace the present page viewing php code with new php code that displays the optimized page views as generated by the wrapper.
3. Any dynamic modules that could change between page views, such as displaying the date, must be modified to work in conjunction with the new page viewing php code.

Basically, visitors would never access any of the present tikiwiki php files. The new wrapper (outline 1.) would call the present tikiwiki page; e.g., http://www.yourwebsite.info/tiki-index.php. The present tikiwiki edit/add page would be deleted; e.g., http://www.yourwebsite.info/tiki-editpage.php?page=HomePage.

So this site would be modularized for optimization and flexibility. Take for example the menu bars. This could be saved in the database when ever the admin makes such changes. So if the admin adds or changes the menu then the sql database would be updated. So every time a visitor views a wiki page, the php would fetch the optimized menu from the database. Of course you would have to work out the details to get really efficient and tricky to include dynamic html content, I think you call them modules. Off the top of my head, the database could return ids of any dynamic modules so these modules could add any such html code. Perhaps the most efficient method is making this process modular so that dynamic html content would be appended to the php output variable and not a search and insert. As example, let's say that in the middle of the menu is dynamic html content. So the main php would set a variable to the top half of the menus html code, call the dynamic module which would *append* whatever html it wants, then the main php would continue to append the bottom half of the menu html code. That's how the menus html code could be generated for each page view. The main php would of course add the rest of the web pages html code, which was generated from the wrapper and continue the same process of inserting any possible dynamic html code as mentioned. Remember, the code that was generated by the wrapper would be performed only when registered users edit or add a page; e.g., http://www.yourwebsite.info/tiki-editpage.php?page=HomePage

A lot of programmers probably won't like this method as it adds extra work/thinking to design and develop, but once really understood it is truly the gurus method.

Wow! What a kick ass wiki that would be!

YT

posts: 19
Sorry, I had to reedited the above post.
posts: 1630 Canada

> Hi,
>
> I have unfinished projects right now, so probably at a later time.
>

>
> Wow! What a kick ass wiki that would be!
>
> YT


No offense but that is all vaporware & talk. Show me the code! biggrin

Tiki already kicks ass!


posts: 4656 Japan

> Oh, and another trick, you should have development files and live files! For example, just the css file for tikimedia theme takes up 38K, but when you strip out all the comments you get 28K! It is a piece of cake to have a script strip out the comments. It's just common sense. In programming it's the little things that add up.

Well, I don't know about that being a "trick" particularly. I was aware of the extra 10K in the tikipedia.css (which is downloaded once and cached), but thought the potential usefulness of the comments to the user made the "bloat" worthwhile since themes development was/is being promoted.

In general about your comments, I wonder how your suggestions would mesh with, replace, or conflict with Tiki's current Smarty template engine, using gzipped output, and other boosting methods like Zend accelerator and Turk mmcache.

-- Gary - zukakakina.com


posts: 19

> I was aware of the extra 10K in the tikipedia.css (which is downloaded once and cached)

The client's css file is cached up till they close their browser.

I think the point is that your developers can have their can and eat it. They would still have their commented file, but when they publish it then a simple script would strip out the comments for the live css file. The development file is only for developers.

So why not do it? You're giving all tikiwiki visitors a free 10K savings every browser session.


> In general about your comments, I wonder how your suggestions would mesh with, replace, or conflict with Tiki's current Smarty template engine, using gzipped output, and other boosting methods like Zend accelerator and Turk mmcache.

It's of no consequence. Remember, what I was talking about was moving the entire tikiwiki away from the live web server (away from web surfers) and making it visible only to a wrapper. The wrapper would only be accessed when visitors edit or add to a wiki web page.

You don't want gzipping to the wrapper. What you would do is move the gzip to the new php page displayer. Your web surfers (people visiting tikiwiki sites) would get the gzip, not the wrapper.

You might have misunderstood my proposal. You can still use smarty, yuk, but personally I don't like it because I know for fact I could do a much better customized job than smarty. Even so, you can still use smarty if you want.

The same goes with Zend. You can still keep it. You could build the wrapper right now and it would work because your tikiwiki would not know the difference. Again, the wrapper is only called when a wiki page is edited or added. So you're probably asking, if the entire tikiwiki is not visible to the visitors, then how are they going to view the site. Again, that would be new php code. This new code would be the client page displayers. This new code would fetch static html code from database in addition to calling any dynamic php modules.

YT


posts: 19

> In general about your comments, I wonder how your suggestions would mesh with,
> replace, or conflict with Tiki's current Smarty template engine, using gzipped
> output, and other boosting methods like Zend accelerator and Turk mmcache.

I would like to add that because of all the above is why a single page hit to tikiwiki takes so much memory. I think all these nice add-ons could kill even top end heavy hit servers. Personally I see all it as a duck tape fix. Rather than trying to cure the symptom with duck tape, the developers should cure the root cause.

YT


Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting