Hi Idan Thank you for jumping in, much appreciated. In answer to your query, I have a series of bulletins in both pdf and png named as 'Bulletin January 2010', 'Bulletin March 2010' through to Bulletin January 2014. 3 per year, maximum of 150kb each.
I need to display all of the bulletins including future versions as png images 350px x 500px approx., in chronological order on a bulletins page. It's a sort of historical record, accessed by member log-in. PDF display is not required.
I can create a view that displays all of the images in the /images folder, including the Bulletins if they are in the images folder, and not have memory issues but cannot get it to access or display images in folders within the /images folder or folders outside the /images folder.
Strange thing is that - If I could create a new content type, I could have a number of blocks on that content type page and display all the bulletin images within those, - easy as, no brainer. But it's not dynamic and has to be manually changed as new bulletins arrive.
The php Fatal memory issue is not related to the above. Instead it relates to Drupal displaying the [Create Content Type] Administration page and it is my feeling that Drupal devs could bite the bullet and build in counter measures for this recurrent php fault. Like reducing the memory requirement for Creating Content Types, which after all is just another creation page like creating new Taxonomy , Views, Rules, People, Workbench, Blocks, etc but for some reason Create New Content Type frightens php out of it's wits so it hides quivering under the Fatal: bed.
As was pointed out by John in reply #6 it's got to be a php problem due to upgrading and seems to have been through previous upgrades judging by the number of Google pages on the subject. I believe it has never been attended to. Yes I have set memory_limit in php.ini, and I have changed /settings.php in Drupal and these seemed to solve the problem until my Fedora 18 upgraded php from 5.3 to 5.4 a week or so ago. So in deference, it is not my machine or it's settings or the remote server but exclusively a php dev testing failure prior to release.
I am looking into Centos 6.4 as was recommended by John but that's not an immediate fix, 5-6 hours to download is beyond my internet capability.
Roger
just jumping in here....Can you explain what you're trying to achive, why are you trying to access the images directly? have you increase the memory limit in the php settings?
Idan
On Thu, Apr 4, 2013 at 10:08 AM, Rogerarelem@bigpond.com wrote:
<snip> My heart just sank into oblivion. I am sooooo sad and fed up with the latest and incessant: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 9331811 bytes) in ...... </snip>
Hi again. Ok so I can't create a content type due to Fatal error messages, but maybe I can make a view and display that in an existing page or block. Problem is I have png images in a number of directories in the /defaults/files/images/Seminar database. Images are png and jpg. I have no idea how to tell a view how to get images from certain directories. For some reason the view I create gets images only from the /images directory and no other. I could not even figure out how to filter on directory names. If it can be solved how to get only png images from different directories /images/Seminar/2011, /2012, /2013, /2014 file tree this would be of great assistance and maybe bail me out temporarily.
Thank you for any assistance, it will be greatly appreciated. Roger --
On 05/04/13 13:42, Roger wrote:
Yes I have set memory_limit in php.ini, and I have changed /settings.php in Drupal and these seemed to solve the problem until my Fedora 18 upgraded php from 5.3 to 5.4 a week or so ago. So in deference, it is not my machine or it's settings or the remote server but exclusively a php dev testing failure prior to release.
I don't expect drupal has had much testing with 5.4.
I am looking into Centos 6.4 as was recommended by John but that's not an immediate fix, 5-6 hours to download is beyond my internet capability.
You can do a network install, and that way you won't have to download all the contents DVD image. Careful configuration of Squid can help immensely too by saving you from downloading packages multiple times. I think one of the things you need to change (but it's years since I did it) is the maximum sized file it will cache.
Apache can cache and proxy too.
It might be a local computer shop will do it for a nominal charge too.
On 05/04/13 13:42, Roger wrote:
s was pointed out by John in reply #6 it's got to be a php problem due to upgrading and seems to have been through previous upgrades judging by the number of Google pages on the subject. I believe it has never been attended to. Yes I have set memory_limit in php.ini, and I have changed /settings.php in Drupal and these seemed to solve the problem until my Fedora 18 upgraded php from 5.3 to 5.4 a week or so ago. So in deference, it is not my machine or it's settings or the remote server but exclusively a php dev testing failure prior to release.
I am looking into Centos 6.4 as was recommended by John but that's not an immediate fix, 5-6 hours to download is beyond my internet capability.
Second option is pretty obvious: remove all your PHP5.4 packages and either get the latest src.rpm you can (earlier Fedora? RHEL6?) and build that, or get the latest 5.3 source from php - a quick look didn't show me anyone who builds 5.3 as rpms - and either use the ./configure && make && sudo make install procedure or roll your own rpms.
Note that D8 will not support RHEL6.
Note that D8 will not support RHEL6.
Care to elaborate? This is contrary to what I've read. My RHEL 6 boxes are running php 5.3.14 which is more than enough for D8. What's the hangup here?
default version for RHEL 6 version
On 05/04/13 23:18, Metzler, David wrote:
Note that D8 will not support RHEL6.
Care to elaborate? This is contrary to what I've read. My RHEL 6 boxes are running php 5.3.14 which is more than enough for D8. What's the hangup here?
Really?
default version for RHEL 6 version
I updated a few hours ago. [root@TestServer ~]# rpm -qf /etc/redhat-release /usr/bin/php centos-release-6-4.el6.centos.10.x86_64 php-cli-5.3.3-22.el6.x86_64 [root@TestServer ~]#
Here's the PHP source H has released: lftp ftp.redhat.com:/pub/redhat/linux/enterprise/6Server/en/os/SRPMS> dir php* -rw-r--r-- 4 ftp ftp 10533725 Aug 18 2010 php-5.3.2-6.el6.src.rpm -rw-r--r-- 5 ftp ftp 10537066 Jan 31 2011 php-5.3.2-6.el6_0.1.src.rpm -rw-r--r-- 4 ftp ftp 10740806 Jun 26 2012 php-5.3.3-14.el6_3.src.rpm -rw-r--r-- 4 ftp ftp 10841228 Jan 22 12:11 php-5.3.3-22.el6.src.rpm -rw-r--r-- 5 ftp ftp 10713798 Apr 21 2011 php-5.3.3-3.el6.src.rpm -rw-r--r-- 5 ftp ftp 10728151 Nov 02 2011 php-5.3.3-3.el6_1.3.src.rpm -rw-r--r-- 5 ftp ftp 10730266 Jan 09 2012 php-5.3.3-3.el6_2.5.src.rpm -rw-r--r-- 5 ftp ftp 10730562 Feb 02 2012 php-5.3.3-3.el6_2.6.src.rpm -rw-r--r-- 5 ftp ftp 10731398 May 04 2012 php-5.3.3-3.el6_2.8.src.rpm
Sorry about the line wraps.
I'm less concerned that I was a little while ago, RHEL7 is in testing, beta is due RSN and release later in the year. I found a bug report in RH's bugzilla. It's based on Fedora 18, so probably PHP 5.4.
I'm sure some will happily run non-standard PHP on their EL6 systems, but those who care about certifications will not, and those who have other PHP applications might not.
ps I have a F18 virtual system running on CentOS 6 + viert-manager. It's display is usably large, in comparison with earlier Linux desktops.
-
John Summerfield -
Metzler, David -
Roger