| Author |
Message |
ToolBox
Regular
Joined: Mar 16, 2005
Posts: 74
|
 Posted:
Sun Jun 14, 2009 10:02 pm |
|
One of great ideas implemented in phpnuke is content module which has not been improved. To look at this module, there are tons of ideas to come up your site documentations.
Unfortunately, one bad thing is the limit. Have you tried to create a content page with a relatively big content? For instance, 32K text or 64 K text?
Probably, your content will be truncated around 27KiB.
What is going on? |
| |
|
|
|
Palbin
Site Admin
Joined: Mar 30, 2006
Posts: 2583
Location: Pittsburgh, Pennsylvania
|
| Posted:
Sun Jun 14, 2009 10:26 pm |
|
Have you tired content plus which is located in the addon files folder? It will be included by default with the next release. I have no idea if this will solve your problems, but the "content module which has not been improved" got my attention. |
_________________
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan. |
|
|
|
|
ToolBox
|
| Posted:
Sun Jun 14, 2009 10:34 pm |
|
Oh, what I meant by that was 'the original phpnuke content.' There is a much much more simple solution.  |
| |
|
|
|
|
ToolBox
|
| Posted:
Sun Jun 14, 2009 10:41 pm |
|
simply change 'text' attribute to 'long text' attribute, which allows up to 2GB.
one of tricks which come from this change is that you can upload 2 GB movie files from local files to the DB. This is an extreme case to experiment. I experiemented this before and it works very well.
IF hosting services do limits the number of files (that is, the max # of inodes), then you may use DB to upload and download to stream out to end-users. Most hosting companies do not limit the DB size.
While testing this on real hosting companies (specifically, blueweb and fatcow <-- this is really sucks for phpnuke), they don't realized that I was utilizing the DB to streaming out.
Anyways, this is another simple solution to allow the max size of 2GB. |
| |
|
|
|
|
eldorado
Involved
Joined: Sep 10, 2008
Posts: 424
Location: France,Translator
|
| Posted:
Mon Jun 15, 2009 4:06 am |
|
You got a point here Toolbox , my host limits the max inodes which is very low. about 3M inodes. |
| |
|
 |
|
montego
Site Admin
Joined: Aug 29, 2004
Posts: 9457
Location: Arizona
|
| Posted:
Mon Jun 15, 2009 6:48 am |
|
It does make taking backups of your database a bit of a chore. I wonder, with 2GB movie files, how does BigDump perform on an export/import situation. I'm rather curious. |
_________________
Only registered users can see links on this board! Get registered or login!
Only registered users can see links on this board! Get registered or login! |
|
|
|
|
ToolBox
|
| Posted:
Mon Jun 15, 2009 8:46 am |
|
| montego wrote: | | It does make taking backups of your database a bit of a chore. I wonder, with 2GB movie files, how does BigDump perform on an export/import situation. I'm rather curious. |
You're right. My assumption for this funny thought does not consider back-up. However, from this thought, we may develop another enhancement of contents that includes bigger documents. Such big 2GB of streaming idea is an extreme thing for use to think. |
| |
|
|
|
|
ToolBox
|
| Posted:
Mon Jun 15, 2009 8:52 am |
|
| eldorado wrote: | | You got a point here Toolbox , my host limits the max inodes which is very low. about 3M inodes. |
That's true. Most of hosting companies limit the max # of files. For instance, Jost Host dot com simply puts their limit less than 25000 of inodes. Let me calculate the possible space.
Let your average file size be 1 MB (whatever your files will be)
Then, 1 MB x 25,000 / 1024 = less than 25GB.
However, their commercial says "unlimited." WoW.
HostGator.com put their maximal # of inodes to 500,000.
500G is max in this case.
When we think over their traffics, it might be more stupid. |
| |
|
|
|
|
montego
|
| Posted:
Tue Jun 16, 2009 5:56 am |
|
| ToolBox wrote: | | montego wrote: | | Such big 2GB of streaming idea is an extreme thing for use to think. |
|
I agree, especially when talking about just one file, but as you state, one of your concerns is inode restrictions, so from a backup standpoint, its the total size of the entire table/db not just the average file size. I know you know this... I have the knack for stating the obvious.  |
| |
|
|
|
|
ToolBox
|
| Posted:
Tue Jun 16, 2009 9:39 am |
|
|
|
|
|
eldorado
|
| Posted:
Wed Jun 17, 2009 2:05 am |
|
how about a detailed explanation on how do you upload such files in the db??
you will find the question noobish , but isn't there any php optimizer that enables you to run the CMS from an archive or from a single file?
I mean with the new internet speed/cpu's, no more B.W and filesize restriction but inodes wouldn't it be wise to compress (as an example) Ravennuke to an only *.php file and separate addons and themes? |
| |
|
|
|
|
Raven
Site Admin/Owner
Joined: Aug 27, 2002
Posts: 17088
|
| Posted:
Tue Jun 23, 2009 6:16 am |
|
| ElDorado wrote: | | but isn't there any php optimizer that enables you to run the CMS from an archive or from a single file? |
Actually I believe there is but it only runs on Windows if I remember correctly.
On the subject of hosting and restrictions, I'd like to take this opportunity to give some details concerning Raven Web Hosting, who we are, why we're here, and where we see ourselves for/in the Community.
Raven Web Hosting(tm) (RWH), a division of Raven Web Services LLC(tm) (RWS), has never limited anything in 7 years and we have never run into any problems. We are a full service web host, not just *nuke type services, although that is how we originally got started. We have a very large gaming community as well as other diverse clients. We have always tried to cater to both developers and webmasters. Yes, we charge a little bit more, but not much, especially when you consider that daily and weekly backups are still free. The free backups are not guaranteed but last year we added another large drive for more backup space and didn't cut back on any services nor increase any prices. We look at it more from the front/top view and not so much the back/down stream. What we mean is that if a client is able and willing to pay up front for the storage then we will subsidize, as much as we can, the backup protection of their data. We have always operated on a much smaller profit margin because we wanted to offer services that serious developers and clients want and need but are restricted by many, if not most, of the cheap unlimited everything companies that load their servers with between 500 and 1500 shared hosting accounts, which most do.
RWH, on the other hand, has always held to an average of 100-125 accounts, per server with a maximum load of only 150! We have never deviated from these numbers and even if we would find ourselves needing to increase we still can offer so much lower thresholds than the competition. We have stayed small because we scrutinize all accounts that sign up. Most are by word-of-mouth as we have yet to do any commercial advertising in 7 years. Growth is nice and we gladly welcome it but not at the expense of quality and service. We have true 24x7x365 monitoring for which we pay extra.
The bottom line is that we want our clients to have the same quality of service and opportunity to develop various applications in the same environment that we do. All of our applications/sites share the same servers as our clients. Why should we short change you to make ourselves look good? In 7 years we have an uptime record 99.8%; seven years! I think you will find that is pretty impressive in the industry.
One last comment. Because of how we run our Web Hosting (trying to offer the most for less), we really need/depend on Donations. There is no hidden monetary agenda for the amount we try to generate monthly. If we were to reach $300/month, which hasn't happened but a few times over the years, we still fall 65% short every month from meeting our own server costs. We average more like $100/month which is only about 18% of what we need.
So if you're looking for better, but not necessarily bigger/cheaper, then please consider Raven Web Hosting - You will definitely not regret it 
In addition to customizing packages, click this link to see some pre-packaged plans ==> Only registered users can see links on this board! Get registered or login!
|
Last edited by Raven on Tue Jun 23, 2009 4:57 pm; edited 1 time in total |
|
|
|
|
duck
Involved
Joined: Jul 03, 2006
Posts: 273
|
| Posted:
Tue Jun 23, 2009 10:26 am |
|
@Raven well spoken Ad. But you should include some direct links for sign up too! I know you can find em on the front page but just a reminder the actual sales copy a person is reading at the time should come with a call to action and an easy method to do so right from that spot. |
| |
|
|
|
|
Raven
|
| Posted:
Tue Jun 23, 2009 4:58 pm |
|
|
|
|
|
ToolBox
|
| Posted:
Wed Jun 24, 2009 2:14 pm |
|
From the funny idea to Web Hosting? Not Bad.
|
| |
|
|
|
|
eldorado
|
| Posted:
Wed Jun 24, 2009 3:19 pm |
|
| ToolBox wrote: | From the funny idea to Web Hosting? Not Bad.
|
yeah , but no one answered my interrogations 
can you tell me how you literally upload a file to a database? |
| |
|
|
|
|
Raven
|
| Posted:
Wed Jun 24, 2009 6:27 pm |
|
|
|
|
|
ToolBox
|
| Posted:
Wed Jun 24, 2009 9:59 pm |
|
Raven has the correct answer.
There is another way to upload in a binary mode from temporary files which is not recommendable. |
| |
|
|
|
|
eldorado
|
| Posted:
Thu Jun 25, 2009 2:05 am |
|
o_O , thx raven , but even if the file is stored in a Long BLOB Field , you still use the temporary memory to store it.
I've seen code snippet on how to achieve these :
Code: $fileName = $_FILES[imgfile][name]; // image file name
$tmpName = $_FILES[imgfile][tmp_name]; // name of the temporary stored file name
$fileSize = $_FILES[imgfile][size]; // size of the uploaded file
$fileType = $_FILES[imgfile][type]; // file type
$fp = fopen($tmpName, ‘r’); // open a file handle of the temporary file
$imgContent = fread($fp, filesize($tmpName)); // read the temp file
fclose($fp); // close the file handle
$query = “INSERT INTO img_tbl (`img_name`, `img_type`, `img_size`, `img_data` )
VALUES (’$fileName’, ‘$fileType’, ‘$fileSize’, ‘$imgContent’)”;
|
it's not converted for nuke , however i'm quite sure it pre-store it in a temporary folder before sending it to the field..
Speaking of speed , it's useless because , you are storing the file twice , deleting from the temp. And reading it.Which takes 2x more time than storing it in ftp.
The worst thing is backup. How do you expect to backup such database? |
| |
|
|
|
|
Guardian2003
Site Admin
Joined: Aug 28, 2003
Posts: 6799
Location: Ha Noi, Viet Nam
|
| Posted:
Thu Jun 25, 2009 2:39 am |
|
It's do-able but some hosts do not allow fopen() or read_file(), also you are still restricted (I believe) to the PHP filesize limitation imposed by the server configuration.
You would also need to make sure you don't do anything silly like
SELECT * from img_table
as that would put severe load on the mySQL server - you would have to select each image seperately (if they were large images/files) as and when needed.
I think it's possible to mitigate that slightly by using a DB TYPE RAW (if your host allows it). |
| |
|
|
|
ToolBox
|
| Posted:
Thu Jun 25, 2009 10:44 am |
|
You're right too.
there is a classical word in computer science: "Divide and Conquer."
Well, even if this sayings is not for reading and writing files, you many "divide and conquer." |
| |
|
|
|
|
|
|
![[Valid RSS]](https://www.ravenphpscripts.com/images/valid-rss.png "Validate my RSS feed"){kind=small}
