Skip to:
Content
Pages
Categories
Search
Top
Bottom

mo file uploading broke my 1.2

  • @chouf1

    Participant

    i actually testing a wp single 3.0 beta + bp 1.2 trunk “out of the box” install

    All went fine during install, except a minor fatal error in the different incoming links widgets in WP:

    Fatal error: Allowed memory size of 20971520 bytes exhausted (tried to allocate 1245184 bytes) in /xxx/xxx/xxx/wp-includes/class-simplepie.php on line 5410.

    When i add the mo file, in WP or BP, the whole site shows a blank error page with:

    Fatal error: Allowed memory size of 20971520 bytes exhausted (tried to allocate 77824 bytes) in /xxx/xxx/xxx//wp-admin/includes/template.php on line 153

    I can use a mo file in WP or BP, but not the both. And if i want to use one, i have to erase the other file.

    I expected the same problem with a standard version of wp and bp. And i tried with a different mo in another language. Same errors.

    20 mo php memory limit is common on a shared host, and many wp user are on shared host. Does this usual capacity compromise these user in the future, after the merge ? Do they all have to went on a dedicated 5 tera host ?

    I put a ticket on wp, bp and wpmu trac… without reaction at this time.

    But for now, i’m wondering if somebody using translation on his site experience the same issue ?

Viewing 8 replies - 1 through 8 (of 8 total)
  • @djpaul

    Keymaster

    You need to increase the amount of memory your PHP can use – if you can’t increase it, find a better host.

    This exact issue is why the ‘BP Backwards Compatbility’ Plugin was created. It saves loading all the code that is out-of-date and not current. But ultimately, if you’re out of memory, you’re out of memory.

    @chouf1

    Participant

    Ooooh DJPaul, i didn’t expect such an answer :-) !

    I had many out of memory issues in my weblife… it is not a fatality. Some where due to whitespace, i remember. So what here ?

    The problem is i don’t use old stuff, or outdated scripts, this is a pure out of the box experience.

    i can’t acces to php.ini directly or via htaccess instructions.

    My host is ready to sell me a different offer, of course, but i’m not ok.

    Is it normal that a translation, who works well elsewhere, takes so much memory ?

    And i’m not sure my problem is so simple as “if you’re out of memory, you’re out of memory”

    We had an analog problem in the past on WPMU/BP, with 64 bits servers i you remember ?

    subsidiary question:

    Do you know a shared hoster who gives unlimited php memory amount or more than 16 or 20 mo for php scripts ?

    @erich73

    Participant

    Chouf1,

    everyone who is following this forum for a certain time (like myself), recognized that you are an expert and you definitely know what you are talking about.

    Many thanks for discovering this issue and posting it into several tickets in order to highlight getting it fixed.

    Appreciate your help.

    @djpaul

    Keymaster

    Well, it might. All those strings you translate get put into memory at run-time. 20Mb is extremely small for a WordPress/BuddyPress site especially if on a shared server.

    Plus, BuddyPress isn’t supported on WordPress 3.0-alpha because, obviously, it’s in alpha. WordPress 3.0-alpha might have huge memory leaks which could be giving you this problem. I would urge you to stick to WP or WPMU 2.9.* for now

    @chouf1

    Participant

    @erich73, na Bueb, das’is n’Gstanzel ! Net von Dir !

    @DJ, did you read my post ? I expected the same problem with a standard install…

    So it remains the problem of memory.

    My host give the possibility to install automatically CMS’s like joomla, wordpress or wpmu, drupal etc to his customers on any of his shared offers. From the cheapest to the most expensive !

    Do you really think he would do that if these tools can’t work because of an unapropriate memory appetite ?

    So what is the minimal size to rent on a shared host to have an operating install with the actual and next coming version ?

    And please, don’t tell me i have to go to wordpress.com :-)

    @boonebgorges

    Keymaster

    Chouf1 – In my (admittedly limited) sysadmin experience, I agree with DJPaul that 20mb is probably just too small to do what you want to do. (One of the first things I had to do when setting up a server recently was to increase the limit in php.ini) I don’t have exact numbers on WP memory usage (it’s so dependent on which page of WP you’re viewing, of course) but with every plugin or addon that is added, each request to the server gets heavier and heavier.

    My guess is that l18n isn’t really the problem here – I don’t think that gettext has that much overhead. I think the problem is that WP + BP is bringing you so close to the PHP per-request memory limit that flipping on the MOs is the straw that breaks the camel’s back. The same thing would probably happen if you turned off l18n and started adding BP plugins, especially relatively hefty ones that add new components.

    As for your host and Fantastico or whatever he provides for automatic installation: I’d wager that he provides it because it’s what the customer wants. Just because he gives you a way to install WP automatically doesn’t necessarily mean that the system is optimized for WP, and especially for WP + BP, which is a pretty resource intensive add-on.

    No one knows yet what the minimum requirements for WP 3.0 will be, as the code is far from being finalized. But I can almost guarantee that you will need *at least* 32MB for PHP requests.

    @chouf1

    Participant

    @Boone, yep, thx !

    So i progressed on my site. I downgraded to wp 2.9 and asked (gently) my host to give me more memory.

    I have now 25 mb for php and the install is working. But i haven’t installed plugins other than BP for the moment….

    If this memory lack is “normal” or “expected”, i would preddict that as soon as WP 3.0 is avaible, 90% of all WP user actually on a shared host, and who udate, will go down. As actually no shared host offers at least 32 mb for php…

    The cgi php solution with 64 mo, the new host trend apparently, is more powerfull but is always shared too, which means that i could write at my site entry: open between 3 and 4 am. The rest of the day, maybe my neighbour is trolling on emule and consume the server memory with * db queries on his overspammed fischerman forum… Wouaaaaaaaa ! Nice future…

    This means also that from now on, a WP usage with BP is only intended to be on dedicated server.

    If this hypotesis is right, this must be annouced to the world and should be mentionned, at least, in the readme file and on the download page.

    So i discover that WP, who once was one of the fastest and litest CMS, is now entering in the heavy weight super-pro area, with ultra wide storage capacities, intense RAM consumption and specialized hi-band connection… Whouaaaaaa !

    Twenty Ten, a new template but also a very surprisingly year ! ;-)

    @chouf1

    Participant

    I continued my investigation and find some interresting things on the german WP forum

    about the 2.8 version and 64bit server php bug due to gettext.

    http://forum.wordpress-deutschland.org/installation/55589-und-noch-einmal-out-memory-4.html

    Also from germany this post in english:

    http://alexrabe.de/2009/06/14/dear-hoster-we-need-more-memory/

    from the author of memory_overview plugin

    And a begin of solution, a modified mo.php file, from here:

    http://www.code-styling.de/deutsch/wordpress-28-sprachdatei-speicherverbrauch-minimieren (the link to the mo file is in yellow under the title “Historie des Downloads” )

    This file goes into wp_includes/pomo

    Use memory_overview plugin, go to the dashboard to view the difference.

    Since 2.5, WP give the possibility to increase php memory in wp-config, but this didn’t work for me.

    https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘mo file uploading broke my 1.2’ is closed to new replies.
Skip to toolbar