Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #15925 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2015-12-19 10:03 +0000 |
| Last post | 2016-01-12 05:34 +0100 |
| Articles | 20 on this page of 159 — 11 participants |
Back to article view | Back to comp.lang.php
PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-19 10:03 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-19 08:20 -0500
Re: PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-20 10:16 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-20 09:31 -0500
Re: PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-20 17:11 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-20 16:42 -0500
Re: PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-25 15:56 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-25 11:23 -0500
Re: PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-26 10:09 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-26 09:33 -0500
Re: PHP boilerplate to appear at the top of any program Denis McMahon <denismfmcmahon@gmail.com> - 2015-12-20 22:54 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-20 18:40 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-21 10:38 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 08:41 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-21 15:30 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 11:04 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-21 23:24 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:16 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 00:33 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:19 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 10:27 +0100
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-22 11:18 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 06:34 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-22 16:00 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 10:56 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 15:56 +0100
OT: pre-PHP day (was: PHP boilerplate to appear at the top of any program) Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 16:57 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 11:03 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-22 18:02 +0100
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 14:47 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 11:04 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 18:22 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 12:33 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 18:46 +0100
Re: PHP boilerplate to appear at the top of any program "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-12-21 17:25 +0100
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-21 23:17 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:23 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-28 15:26 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 10:02 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-28 18:14 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 12:29 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-28 18:54 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 14:15 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-28 21:18 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 15:49 -0500
Re: PHP boilerplate to appear at the top of any program Richard Damon <Richard@Damon-Family.org> - 2015-12-28 20:31 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 20:48 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-30 11:26 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 12:33 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-30 18:57 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 15:14 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-30 19:05 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 15:18 -0500
Re: PHP boilerplate to appear at the top of any program Richard Damon <Richard@Damon-Family.org> - 2015-12-30 21:55 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2015-12-30 22:14 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 22:43 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 22:46 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 22:42 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 09:07 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 07:47 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 16:11 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 10:47 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 17:43 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 13:49 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 20:35 +0100
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-30 11:18 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 12:36 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-30 19:09 +0100
Re: PHP boilerplate to appear at the top of any program Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2015-12-30 20:28 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 15:21 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 09:09 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 15:21 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 09:16 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 07:53 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 16:03 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 10:49 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-31 17:16 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 13:54 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-31 20:41 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 14:47 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 20:56 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 15:21 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 17:52 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 13:51 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-28 19:35 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 14:17 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 00:20 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:27 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 10:12 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 06:36 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 13:57 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 11:05 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 17:22 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 12:01 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 18:25 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 12:34 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-12-21 14:53 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:30 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2015-12-21 21:40 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2015-12-21 21:47 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 21:55 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2015-12-21 21:57 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 22:01 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 21:54 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-12-22 11:54 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 15:42 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-02 11:08 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-02 15:12 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-04 10:41 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 14:39 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-12-22 11:49 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 15:44 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-02 11:09 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-02 15:14 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-04 10:42 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 14:41 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-04 22:54 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 19:40 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 04:19 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 22:29 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2016-01-05 02:02 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 09:08 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 18:55 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 14:06 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-04 15:51 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 19:41 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 04:27 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 22:31 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 04:48 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 22:52 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 09:16 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 09:08 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 18:59 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 14:07 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-06 01:13 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 20:52 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-06 08:53 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 09:15 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-05 09:00 -0800
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 19:01 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 14:09 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-06 01:15 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 20:51 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-06 08:54 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 09:16 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 09:02 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 08:02 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 23:42 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:44 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 14:09 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-06 09:27 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 15:25 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-06 13:27 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 16:32 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 09:03 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 08:03 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 23:45 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:48 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 05:34 +0100
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-28 12:29 -0500 |
| Message-ID | <n5rrd9$lhv$1@jstuckle.eternal-september.org> |
| In reply to | #15998 |
On 12/28/2015 12:14 PM, Gregor Kofler wrote: > Am 2015-12-28 um 16:02 schrieb Jerry Stuckle: >> On 12/28/2015 9:26 AM, Thomas 'PointedEars' Lahn wrote: >>> Jerry Stuckle wrote: >>> >>>> On 12/21/2015 5:17 PM, Thomas 'Pointed Head' Lahn wrote: >>>>> Christoph M. Becker wrote: >>>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>> Jerry Stuckle wrote: >>>>>>>> Only someone who uses a CMS triggers everything from index.php. >>>>> JFTR: Strawman. I had _not_ said that *everything* should be triggered >>>>> from index.php. >>>> >>>> ROFLMAO! You said *exactly* that! And now you try to deny it. >>> >>> ,-<news:2838299.zdqeYZrqYU@PointedEars.de> >>> | > Use of ob_start before the code generates 'normal' output so that the >>> | > program can present custom error information if something goes wrong. >>> | >>> | Again, that is something better enabled for the whole site (in index.php, >>> | which should trigger almost everything else) >>> ^^^^^^ >>> >> >> Which is only a minor difference. You run virtually everything through >> index.php - something that's crappy programming except when most of your >> code is stored in a database as in a CMS. > > I have whole web applications without database backend running "through > index.php". And my code is primarily stored in so-called controllers or > so-called services. (What's "code stored in a database" supposed to be, > anyway?) > Sounds like a pretty poor way of doing things. And "code stored in a database" is exactly that. The code is stored in a database (typically MySQL or PostGreSQL) and exec'd. > Since this is the approach of quite a few (if not most) major web > application frameworks out there - everyone using such one relies on > "crappy programming"? > Yes, and most of those frameworks store code in a database - ones such as Joomla, WordPress, Drupal... But if you're so knowledgeable about those frameworks, you should understand it. > Since you consider it "crappy programming" - can you explain *why*? > > Gregor > First of all, it's additional overhead on the server. It has to retrieve the index.php, do some processing, then include the appropriate scripts to perform the work. As opposed to individual scripts, which can be retrieved directly via their uri. Additionally, the index.php file often includes virtually any class files or other includes other scripts may require. The result is higher resource requirements on the server, resulting in higher workload for the server and slower response time to the client. Of course, this might not be important to you if you're only serving 10 pages per hour. But if you're trying to serve hundreds of pages per second, it's a huge difference. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2015-12-28 18:54 +0100 |
| Message-ID | <n5rssi$rl4$1@dont-email.me> |
| In reply to | #15999 |
Am 2015-12-28 um 18:29 schrieb Jerry Stuckle: > On 12/28/2015 12:14 PM, Gregor Kofler wrote: >> Am 2015-12-28 um 16:02 schrieb Jerry Stuckle: >>> On 12/28/2015 9:26 AM, Thomas 'PointedEars' Lahn wrote: >>>> Jerry Stuckle wrote: >>>> >>>>> On 12/21/2015 5:17 PM, Thomas 'Pointed Head' Lahn wrote: >>>>>> Christoph M. Becker wrote: >>>>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>>> Jerry Stuckle wrote: >>>>>>>>> Only someone who uses a CMS triggers everything from index.php. >>>>>> JFTR: Strawman. I had _not_ said that *everything* should be triggered >>>>>> from index.php. >>>>> >>>>> ROFLMAO! You said *exactly* that! And now you try to deny it. >>>> >>>> ,-<news:2838299.zdqeYZrqYU@PointedEars.de> >>>> | > Use of ob_start before the code generates 'normal' output so that the >>>> | > program can present custom error information if something goes wrong. >>>> | >>>> | Again, that is something better enabled for the whole site (in index.php, >>>> | which should trigger almost everything else) >>>> ^^^^^^ >>>> >>> >>> Which is only a minor difference. You run virtually everything through >>> index.php - something that's crappy programming except when most of your >>> code is stored in a database as in a CMS. >> >> I have whole web applications without database backend running "through >> index.php". And my code is primarily stored in so-called controllers or >> so-called services. (What's "code stored in a database" supposed to be, >> anyway?) >> > > Sounds like a pretty poor way of doing things. And "code stored in a > database" is exactly that. The code is stored in a database (typically > MySQL or PostGreSQL) and exec'd. So? Does this happen a lot? I doubt that. >> Since this is the approach of quite a few (if not most) major web >> application frameworks out there - everyone using such one relies on >> "crappy programming"? >> > > Yes, and most of those frameworks store code in a database - ones such > as Joomla, WordPress, Drupal... But if you're so knowledgeable about > those frameworks, you should understand it. Joomla stores code in the database? Can you back that up? It might store parameters but no PHP code. I suppose other CMSs behave the same. And I can back it up - I just looked into a Joomla database. Besides: When talking about web application frameworks I meant something like Symfony or ZF, not some ready-made CMS. >> Since you consider it "crappy programming" - can you explain *why*? > First of all, it's additional overhead on the server. It has to > retrieve the index.php, do some processing, then include the appropriate > scripts to perform the work. As opposed to individual scripts, which > can be retrieved directly via their uri. Additionally, the index.php > file often includes virtually any class files or other includes other > scripts may require. And your umpteenth directly addressed scripts don't include library files? > The result is higher resource requirements on the server, resulting in > higher workload for the server and slower response time to the client. > Of course, this might not be important to you if you're only serving 10 > pages per hour. But if you're trying to serve hundreds of pages per > second, it's a huge difference. Efficient caching mechanism exist. You rated the front controller approach generally as "crappy programming". Now we are already talking about particular application requirements (hundreds of request per second) ignoring any benefit stemming from a front controller. Gregor
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-28 14:15 -0500 |
| Message-ID | <n5s1jo$fj9$1@jstuckle.eternal-september.org> |
| In reply to | #16000 |
On 12/28/2015 12:54 PM, Gregor Kofler wrote: > Am 2015-12-28 um 18:29 schrieb Jerry Stuckle: >> On 12/28/2015 12:14 PM, Gregor Kofler wrote: >>> Am 2015-12-28 um 16:02 schrieb Jerry Stuckle: >>>> On 12/28/2015 9:26 AM, Thomas 'PointedEars' Lahn wrote: >>>>> Jerry Stuckle wrote: >>>>> >>>>>> On 12/21/2015 5:17 PM, Thomas 'Pointed Head' Lahn wrote: >>>>>>> Christoph M. Becker wrote: >>>>>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>>>> Jerry Stuckle wrote: >>>>>>>>>> Only someone who uses a CMS triggers everything from index.php. >>>>>>> JFTR: Strawman. I had _not_ said that *everything* should be triggered >>>>>>> from index.php. >>>>>> >>>>>> ROFLMAO! You said *exactly* that! And now you try to deny it. >>>>> >>>>> ,-<news:2838299.zdqeYZrqYU@PointedEars.de> >>>>> | > Use of ob_start before the code generates 'normal' output so that the >>>>> | > program can present custom error information if something goes wrong. >>>>> | >>>>> | Again, that is something better enabled for the whole site (in index.php, >>>>> | which should trigger almost everything else) >>>>> ^^^^^^ >>>>> >>>> >>>> Which is only a minor difference. You run virtually everything through >>>> index.php - something that's crappy programming except when most of your >>>> code is stored in a database as in a CMS. >>> >>> I have whole web applications without database backend running "through >>> index.php". And my code is primarily stored in so-called controllers or >>> so-called services. (What's "code stored in a database" supposed to be, >>> anyway?) >>> >> >> Sounds like a pretty poor way of doing things. And "code stored in a >> database" is exactly that. The code is stored in a database (typically >> MySQL or PostGreSQL) and exec'd. > > So? Does this happen a lot? I doubt that. > Then you don't understand how CMS's work. It's how WordPress, Joomla and Drupal do, for instance. >>> Since this is the approach of quite a few (if not most) major web >>> application frameworks out there - everyone using such one relies on >>> "crappy programming"? >>> >> >> Yes, and most of those frameworks store code in a database - ones such >> as Joomla, WordPress, Drupal... But if you're so knowledgeable about >> those frameworks, you should understand it. > > Joomla stores code in the database? Can you back that up? It might store > parameters but no PHP code. I suppose other CMSs behave the same. And I > can back it up - I just looked into a Joomla database. > Look at Joomla and the other databases. When you enter custom PHP code into a page, the code is stored in the database and exec'd from there. > Besides: When talking about web application frameworks I meant something > like Symfony or ZF, not some ready-made CMS. > Which are not a whole lot different than CMS's. But I have yet to find an application frameworks which is worth a damn for web pages. Every one of them adds extra unnecessary overhead, restricts what you can do and generally makes things more difficult. I've found I can code web pages from scratch much faster. >>> Since you consider it "crappy programming" - can you explain *why*? > >> First of all, it's additional overhead on the server. It has to >> retrieve the index.php, do some processing, then include the appropriate >> scripts to perform the work. As opposed to individual scripts, which >> can be retrieved directly via their uri. Additionally, the index.php >> file often includes virtually any class files or other includes other >> scripts may require. > > And your umpteenth directly addressed scripts don't include library files? > Sure. But they are first order includes - the called script includes them, not some script which was called from another script which was called from another script... And the scripts only include what they need - not superfluous files. >> The result is higher resource requirements on the server, resulting in >> higher workload for the server and slower response time to the client. >> Of course, this might not be important to you if you're only serving 10 >> pages per hour. But if you're trying to serve hundreds of pages per >> second, it's a huge difference. > > Efficient caching mechanism exist. > Which requires even more system resources. But all the caching does is limit disk accesses. It doesn't do a thing for the rest of the problems. > You rated the front controller approach generally as "crappy > programming". Now we are already talking about particular application > requirements (hundreds of request per second) ignoring any benefit > stemming from a front controller. > > Gregor > No, I'm talking about good programming practices which work with any load. But when all you code are sites which get 10 page hits per day, performance isn't a problem. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2015-12-28 21:18 +0100 |
| Message-ID | <n5s5ad$ttt$1@dont-email.me> |
| In reply to | #16002 |
Am 2015-12-28 um 20:15 schrieb Jerry Stuckle: > On 12/28/2015 12:54 PM, Gregor Kofler wrote: >> Am 2015-12-28 um 18:29 schrieb Jerry Stuckle: >>> Yes, and most of those frameworks store code in a database - ones such >>> as Joomla, WordPress, Drupal... But if you're so knowledgeable about >>> those frameworks, you should understand it. >> >> Joomla stores code in the database? Can you back that up? It might store >> parameters but no PHP code. I suppose other CMSs behave the same. And I >> can back it up - I just looked into a Joomla database. >> > > Look at Joomla and the other databases. When you enter custom PHP code > into a page, the code is stored in the database and exec'd from there. At least Joomla filters PHP when entered as content of a page. I suppose other CMSs behave the same. Besides, even if this is accepted, it is hardly a necessity to do that. >>>> Since you consider it "crappy programming" - can you explain *why*? >> >>> First of all, it's additional overhead on the server. It has to >>> retrieve the index.php, do some processing, then include the appropriate >>> scripts to perform the work. As opposed to individual scripts, which >>> can be retrieved directly via their uri. Additionally, the index.php >>> file often includes virtually any class files or other includes other >>> scripts may require. >> >> And your umpteenth directly addressed scripts don't include library files? > > Sure. But they are first order includes - the called script includes > them, not some script which was called from another script which was > called from another script... And the scripts only include what they > need - not superfluous files. What's the nesting got to do with server load? Agreed, it will make difference whether you include 100 or 1000 files, but whether they are nested will make no difference. So it boils down to how many files are included/parsed. Then take a lean framework. >>> The result is higher resource requirements on the server, resulting in >>> higher workload for the server and slower response time to the client. >>> Of course, this might not be important to you if you're only serving 10 >>> pages per hour. But if you're trying to serve hundreds of pages per >>> second, it's a huge difference. >> >> Efficient caching mechanism exist. >> > Which requires even more system resources. But all the caching does is > limit disk accesses. It doesn't do a thing for the rest of the problems. System resources in this case primarily mean "disk space" - which you are also "squandering" by having seperate files for every page. Anyway, in both cases the additional disk space is hardly more than the un-cached application. What are "the rest of the problems"? >> You rated the front controller approach generally as "crappy >> programming". Now we are already talking about particular application >> requirements (hundreds of request per second) ignoring any benefit >> stemming from a front controller. > > No, I'm talking about good programming practices which work with any > load. But when all you code are sites which get 10 page hits per day, > performance isn't a problem. No. We are talking about an approach which might show some benefits with high loads. Might. We are leaving out all other aspects of "good programming practices". I assume you are not a big fan of OOP either.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-28 15:49 -0500 |
| Message-ID | <n5s746$510$1@jstuckle.eternal-september.org> |
| In reply to | #16004 |
On 12/28/2015 3:18 PM, Gregor Kofler wrote: > Am 2015-12-28 um 20:15 schrieb Jerry Stuckle: >> On 12/28/2015 12:54 PM, Gregor Kofler wrote: >>> Am 2015-12-28 um 18:29 schrieb Jerry Stuckle: > >>>> Yes, and most of those frameworks store code in a database - ones such >>>> as Joomla, WordPress, Drupal... But if you're so knowledgeable about >>>> those frameworks, you should understand it. >>> >>> Joomla stores code in the database? Can you back that up? It might store >>> parameters but no PHP code. I suppose other CMSs behave the same. And I >>> can back it up - I just looked into a Joomla database. >>> >> >> Look at Joomla and the other databases. When you enter custom PHP code >> into a page, the code is stored in the database and exec'd from there. > > At least Joomla filters PHP when entered as content of a page. I suppose > other CMSs behave the same. Besides, even if this is accepted, it is > hardly a necessity to do that. > It *can* filter PHP. But that filtering means just disallowing certain keywords/functions. It's not very secure. >>>>> Since you consider it "crappy programming" - can you explain *why*? >>> >>>> First of all, it's additional overhead on the server. It has to >>>> retrieve the index.php, do some processing, then include the appropriate >>>> scripts to perform the work. As opposed to individual scripts, which >>>> can be retrieved directly via their uri. Additionally, the index.php >>>> file often includes virtually any class files or other includes other >>>> scripts may require. >>> >>> And your umpteenth directly addressed scripts don't include library files? >> >> Sure. But they are first order includes - the called script includes >> them, not some script which was called from another script which was >> called from another script... And the scripts only include what they >> need - not superfluous files. > > What's the nesting got to do with server load? Agreed, it will make > difference whether you include 100 or 1000 files, but whether they are > nested will make no difference. > So it boils down to how many files are included/parsed. Then take a lean > framework. > Glad you think so. But not true. There is a limit to how much can be cached, and the deeper you go, the more cache that's required. The result is less is cached when you include from several layers deep. >>>> The result is higher resource requirements on the server, resulting in >>>> higher workload for the server and slower response time to the client. >>>> Of course, this might not be important to you if you're only serving 10 >>>> pages per hour. But if you're trying to serve hundreds of pages per >>>> second, it's a huge difference. >>> >>> Efficient caching mechanism exist. >>> >> Which requires even more system resources. But all the caching does is >> limit disk accesses. It doesn't do a thing for the rest of the problems. > > System resources in this case primarily mean "disk space" - which you > are also "squandering" by having seperate files for every page. Anyway, > in both cases the additional disk space is hardly more than the > un-cached application. > > What are "the rest of the problems"? > Disk space is NOT the problem. Disk space is cheap. System resources include memory and processor time - both which are limited in a busy system. Also, to a certain extent, disk access time - multiple files are not necessarily in adjacent blocks on the disk, while a single file may fit into one block. For instance, if the disk block size is 4096 bytes, it takes one seek/read to get a 3K file - but three seeks/reads to get the same code in three files. And BTW - the 3 files will take up 12K, while the single file will take up 1K. But as I said, disk space nowadays is not a problem. >>> You rated the front controller approach generally as "crappy >>> programming". Now we are already talking about particular application >>> requirements (hundreds of request per second) ignoring any benefit >>> stemming from a front controller. >> >> No, I'm talking about good programming practices which work with any >> load. But when all you code are sites which get 10 page hits per day, >> performance isn't a problem. > > No. We are talking about an approach which might show some benefits with > high loads. Might. We are leaving out all other aspects of "good > programming practices". I assume you are not a big fan of OOP either. > No, we are talking about an approach which is scalable and used good programming practices. And it DOES show benefits with high loads. But then you've never programmed for a site which can hit > 1K page views per second. That is obvious. But even with low load sites, it is much more manageable. And yes, I am a huge fan of OOP. If you read my updates (even in this thread), you would understand that. But even trying to change the subject like that is typical of a troll who can't respond in an intelligent manner. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-12-28 20:31 -0500 |
| Message-ID | <6olgy.31399$b8.17906@fx29.iad> |
| In reply to | #16002 |
On 12/28/15 2:15 PM, Jerry Stuckle wrote: > On 12/28/2015 12:54 PM, Gregor Kofler wrote: >> Am 2015-12-28 um 18:29 schrieb Jerry Stuckle: >>> On 12/28/2015 12:14 PM, Gregor Kofler wrote: >>>> Am 2015-12-28 um 16:02 schrieb Jerry Stuckle: >>>>> On 12/28/2015 9:26 AM, Thomas 'PointedEars' Lahn wrote: >>>>>> Jerry Stuckle wrote: >>>>>> >>>>>>> On 12/21/2015 5:17 PM, Thomas 'Pointed Head' Lahn wrote: >>>>>>>> Christoph M. Becker wrote: >>>>>>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>>>>> Jerry Stuckle wrote: >>>>>>>>>>> Only someone who uses a CMS triggers everything from index.php. >>>>>>>> JFTR: Strawman. I had _not_ said that *everything* should be triggered >>>>>>>> from index.php. >>>>>>> >>>>>>> ROFLMAO! You said *exactly* that! And now you try to deny it. >>>>>> >>>>>> ,-<news:2838299.zdqeYZrqYU@PointedEars.de> >>>>>> | > Use of ob_start before the code generates 'normal' output so that the >>>>>> | > program can present custom error information if something goes wrong. >>>>>> | >>>>>> | Again, that is something better enabled for the whole site (in index.php, >>>>>> | which should trigger almost everything else) >>>>>> ^^^^^^ >>>>>> >>>>> >>>>> Which is only a minor difference. You run virtually everything through >>>>> index.php - something that's crappy programming except when most of your >>>>> code is stored in a database as in a CMS. >>>> >>>> I have whole web applications without database backend running "through >>>> index.php". And my code is primarily stored in so-called controllers or >>>> so-called services. (What's "code stored in a database" supposed to be, >>>> anyway?) >>>> >>> >>> Sounds like a pretty poor way of doing things. And "code stored in a >>> database" is exactly that. The code is stored in a database (typically >>> MySQL or PostGreSQL) and exec'd. >> >> So? Does this happen a lot? I doubt that. >> > > Then you don't understand how CMS's work. It's how WordPress, Joomla > and Drupal do, for instance. > >>>> Since this is the approach of quite a few (if not most) major web >>>> application frameworks out there - everyone using such one relies on >>>> "crappy programming"? >>>> >>> >>> Yes, and most of those frameworks store code in a database - ones such >>> as Joomla, WordPress, Drupal... But if you're so knowledgeable about >>> those frameworks, you should understand it. >> >> Joomla stores code in the database? Can you back that up? It might store >> parameters but no PHP code. I suppose other CMSs behave the same. And I >> can back it up - I just looked into a Joomla database. >> > > Look at Joomla and the other databases. When you enter custom PHP code > into a page, the code is stored in the database and exec'd from there. > Have made extensive use of Joomla and Drupal, I can say that having code IN the database is the exception, not the rule. 99% of your code is in normal php files in the modules used to build the site. They allow, but discourage the ability to place snippets in the database to allow building more complicated conditions/'rules' for behavior, but this comes with major warnings that if you allow this to be done, you have opened a major security hole in your site.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-28 20:48 -0500 |
| Message-ID | <n5sole$3jd$1@jstuckle.eternal-september.org> |
| In reply to | #16006 |
On 12/28/2015 8:31 PM, Richard Damon wrote: > On 12/28/15 2:15 PM, Jerry Stuckle wrote: >> On 12/28/2015 12:54 PM, Gregor Kofler wrote: >>> Am 2015-12-28 um 18:29 schrieb Jerry Stuckle: >>>> On 12/28/2015 12:14 PM, Gregor Kofler wrote: >>>>> Am 2015-12-28 um 16:02 schrieb Jerry Stuckle: >>>>>> On 12/28/2015 9:26 AM, Thomas 'PointedEars' Lahn wrote: >>>>>>> Jerry Stuckle wrote: >>>>>>> >>>>>>>> On 12/21/2015 5:17 PM, Thomas 'Pointed Head' Lahn wrote: >>>>>>>>> Christoph M. Becker wrote: >>>>>>>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>>>>>> Jerry Stuckle wrote: >>>>>>>>>>>> Only someone who uses a CMS triggers everything from index.php. >>>>>>>>> JFTR: Strawman. I had _not_ said that *everything* should be >>>>>>>>> triggered >>>>>>>>> from index.php. >>>>>>>> >>>>>>>> ROFLMAO! You said *exactly* that! And now you try to deny it. >>>>>>> >>>>>>> ,-<news:2838299.zdqeYZrqYU@PointedEars.de> >>>>>>> | > Use of ob_start before the code generates 'normal' output so >>>>>>> that the >>>>>>> | > program can present custom error information if something >>>>>>> goes wrong. >>>>>>> | >>>>>>> | Again, that is something better enabled for the whole site (in >>>>>>> index.php, >>>>>>> | which should trigger almost everything else) >>>>>>> ^^^^^^ >>>>>>> >>>>>> >>>>>> Which is only a minor difference. You run virtually everything >>>>>> through >>>>>> index.php - something that's crappy programming except when most >>>>>> of your >>>>>> code is stored in a database as in a CMS. >>>>> >>>>> I have whole web applications without database backend running >>>>> "through >>>>> index.php". And my code is primarily stored in so-called >>>>> controllers or >>>>> so-called services. (What's "code stored in a database" supposed to >>>>> be, >>>>> anyway?) >>>>> >>>> >>>> Sounds like a pretty poor way of doing things. And "code stored in a >>>> database" is exactly that. The code is stored in a database (typically >>>> MySQL or PostGreSQL) and exec'd. >>> >>> So? Does this happen a lot? I doubt that. >>> >> >> Then you don't understand how CMS's work. It's how WordPress, Joomla >> and Drupal do, for instance. >> >>>>> Since this is the approach of quite a few (if not most) major web >>>>> application frameworks out there - everyone using such one relies on >>>>> "crappy programming"? >>>>> >>>> >>>> Yes, and most of those frameworks store code in a database - ones such >>>> as Joomla, WordPress, Drupal... But if you're so knowledgeable about >>>> those frameworks, you should understand it. >>> >>> Joomla stores code in the database? Can you back that up? It might store >>> parameters but no PHP code. I suppose other CMSs behave the same. And I >>> can back it up - I just looked into a Joomla database. >>> >> >> Look at Joomla and the other databases. When you enter custom PHP code >> into a page, the code is stored in the database and exec'd from there. >> > > Have made extensive use of Joomla and Drupal, I can say that having code > IN the database is the exception, not the rule. 99% of your code is in > normal php files in the modules used to build the site. They allow, but > discourage the ability to place snippets in the database to allow > building more complicated conditions/'rules' for behavior, but this > comes with major warnings that if you allow this to be done, you have > opened a major security hole in your site. > I also have had to pick up maintenance of Drupal, Joomla and WordPress sites other programmers have screwed up. I am *quite* familiar with the structure. Yes, most of the code is in modules and other files WRITTEN BY OTHER PEOPLE. But the majority of code YOU WRITE goes in the database. Very few people are going to learn how to write a module just to put in a few filters or display something from another database. Rather, they'll put it right in the page - which places it in the database. Sure, it's a potential security hole. But only if you don't know what you're doing. Unfortunately, few programmers who use a CMS or frameworks know how to secure a website properly. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-12-30 11:26 +0100 |
| Message-ID | <5683B141.5080909@arnowelzel.de> |
| In reply to | #16007 |
Jerry Stuckle schrieb am 2015-12-29 um 02:48: > On 12/28/2015 8:31 PM, Richard Damon wrote: [...] >> Have made extensive use of Joomla and Drupal, I can say that having code >> IN the database is the exception, not the rule. 99% of your code is in >> normal php files in the modules used to build the site. They allow, but >> discourage the ability to place snippets in the database to allow >> building more complicated conditions/'rules' for behavior, but this >> comes with major warnings that if you allow this to be done, you have >> opened a major security hole in your site. >> > > I also have had to pick up maintenance of Drupal, Joomla and WordPress > sites other programmers have screwed up. I am *quite* familiar with the > structure. > > Yes, most of the code is in modules and other files WRITTEN BY OTHER > PEOPLE. But the majority of code YOU WRITE goes in the database. Very No - it doesn't. Don't mix up crap written by third parties with the core or Drupal, Joomla or WordPress. How many websites did you set up from scratch in Drupal, Joomla, WordPress? How many add-ons, themes, extensions, modules etc. did you develop for Drupal, Joomla and WordPress? > few people are going to learn how to write a module just to put in a few > filters or display something from another database. Rather, they'll put > it right in the page - which places it in the database. > > Sure, it's a potential security hole. But only if you don't know what > you're doing. Unfortunately, few programmers who use a CMS or > frameworks know how to secure a website properly. So what? This is not the problem of the CMS as it is not the problem of PHP itself that people without enough knowledge write bad code. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-30 12:33 -0500 |
| Message-ID | <n614bo$n85$1@jstuckle.eternal-september.org> |
| In reply to | #16009 |
On 12/30/2015 5:26 AM, the well known troll Arno Welzel wrote: > Jerry Stuckle schrieb am 2015-12-29 um 02:48: > >> On 12/28/2015 8:31 PM, Richard Damon wrote: > [...] >>> Have made extensive use of Joomla and Drupal, I can say that having code >>> IN the database is the exception, not the rule. 99% of your code is in >>> normal php files in the modules used to build the site. They allow, but >>> discourage the ability to place snippets in the database to allow >>> building more complicated conditions/'rules' for behavior, but this >>> comes with major warnings that if you allow this to be done, you have >>> opened a major security hole in your site. >>> >> >> I also have had to pick up maintenance of Drupal, Joomla and WordPress >> sites other programmers have screwed up. I am *quite* familiar with the >> structure. >> >> Yes, most of the code is in modules and other files WRITTEN BY OTHER >> PEOPLE. But the majority of code YOU WRITE goes in the database. Very > > No - it doesn't. Don't mix up crap written by third parties with the > core or Drupal, Joomla or WordPress. > The troll once again proves he knows nothing about which he speaks. > How many websites did you set up from scratch in Drupal, Joomla, > WordPress? How many add-ons, themes, extensions, modules etc. did you > develop for Drupal, Joomla and WordPress? > More than you ever have, troll. That's for sure. >> few people are going to learn how to write a module just to put in a few >> filters or display something from another database. Rather, they'll put >> it right in the page - which places it in the database. >> >> Sure, it's a potential security hole. But only if you don't know what >> you're doing. Unfortunately, few programmers who use a CMS or >> frameworks know how to secure a website properly. > > So what? This is not the problem of the CMS as it is not the problem of > PHP itself that people without enough knowledge write bad code. > > I never said it was a problem with the CMS, troll. But once again you can't read plain English. I suggest you go back to digging ditches with your fellow troll Pointed Head. If you can figure out which end of the shovel to use, that is. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-12-30 18:57 +0100 |
| Message-ID | <56841B1B.4080104@arnowelzel.de> |
| In reply to | #16010 |
Jerry Stuckle schrieb am 2015-12-30 um 18:33: > On 12/30/2015 5:26 AM, the well known troll Arno Welzel wrote: >> Jerry Stuckle schrieb am 2015-12-29 um 02:48: >> >>> On 12/28/2015 8:31 PM, Richard Damon wrote: >> [...] >>>> Have made extensive use of Joomla and Drupal, I can say that having code >>>> IN the database is the exception, not the rule. 99% of your code is in >>>> normal php files in the modules used to build the site. They allow, but >>>> discourage the ability to place snippets in the database to allow >>>> building more complicated conditions/'rules' for behavior, but this >>>> comes with major warnings that if you allow this to be done, you have >>>> opened a major security hole in your site. >>>> >>> >>> I also have had to pick up maintenance of Drupal, Joomla and WordPress >>> sites other programmers have screwed up. I am *quite* familiar with the >>> structure. >>> >>> Yes, most of the code is in modules and other files WRITTEN BY OTHER >>> PEOPLE. But the majority of code YOU WRITE goes in the database. Very >> >> No - it doesn't. Don't mix up crap written by third parties with the >> core or Drupal, Joomla or WordPress. >> > > The troll once again proves he knows nothing about which he speaks. Just to convince the readers here that *you* know what you talk about: show the code in WordPress where WordPress itself puts *code* into its database. And by "WordPress itself" I mean the core of WordPress: <https://core.svn.wordpress.org/trunk/> -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-30 15:14 -0500 |
| Message-ID | <n61dqm$rpv$1@jstuckle.eternal-september.org> |
| In reply to | #16012 |
On 12/30/2015 12:57 PM, Arno Welzel wrote: > Jerry Stuckle schrieb am 2015-12-30 um 18:33: > >> On 12/30/2015 5:26 AM, the well known troll Arno Welzel wrote: >>> Jerry Stuckle schrieb am 2015-12-29 um 02:48: >>> >>>> On 12/28/2015 8:31 PM, Richard Damon wrote: >>> [...] >>>>> Have made extensive use of Joomla and Drupal, I can say that having code >>>>> IN the database is the exception, not the rule. 99% of your code is in >>>>> normal php files in the modules used to build the site. They allow, but >>>>> discourage the ability to place snippets in the database to allow >>>>> building more complicated conditions/'rules' for behavior, but this >>>>> comes with major warnings that if you allow this to be done, you have >>>>> opened a major security hole in your site. >>>>> >>>> >>>> I also have had to pick up maintenance of Drupal, Joomla and WordPress >>>> sites other programmers have screwed up. I am *quite* familiar with the >>>> structure. >>>> >>>> Yes, most of the code is in modules and other files WRITTEN BY OTHER >>>> PEOPLE. But the majority of code YOU WRITE goes in the database. Very >>> >>> No - it doesn't. Don't mix up crap written by third parties with the >>> core or Drupal, Joomla or WordPress. >>> >> >> The troll once again proves he knows nothing about which he speaks. > > Just to convince the readers here that *you* know what you talk about: > show the code in WordPress where WordPress itself puts *code* into its > database. And by "WordPress itself" I mean the core of WordPress: > > <https://core.svn.wordpress.org/trunk/> > > ROFLMAO! I'm not going to fall for your trollish behavior. I don't need to prove to YOU, of all people, anything. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2015-12-30 19:05 +0100 |
| Message-ID | <n6168r$une$1@dont-email.me> |
| In reply to | #16010 |
Am 2015-12-30 um 18:33 schrieb Jerry Stuckle: > On 12/30/2015 5:26 AM, the well known troll Arno Welzel wrote: >> Jerry Stuckle schrieb am 2015-12-29 um 02:48: >> >>> On 12/28/2015 8:31 PM, Richard Damon wrote: >> [...] >>>> Have made extensive use of Joomla and Drupal, I can say that having code >>>> IN the database is the exception, not the rule. 99% of your code is in >>>> normal php files in the modules used to build the site. They allow, but >>>> discourage the ability to place snippets in the database to allow >>>> building more complicated conditions/'rules' for behavior, but this >>>> comes with major warnings that if you allow this to be done, you have >>>> opened a major security hole in your site. >>>> >>> >>> I also have had to pick up maintenance of Drupal, Joomla and WordPress >>> sites other programmers have screwed up. I am *quite* familiar with the >>> structure. >>> >>> Yes, most of the code is in modules and other files WRITTEN BY OTHER >>> PEOPLE. But the majority of code YOU WRITE goes in the database. Very >> >> No - it doesn't. Don't mix up crap written by third parties with the >> core or Drupal, Joomla or WordPress. >> > > The troll once again proves he knows nothing about which he speaks. Sheesh, Jerry! Can you add some substance to your insults? >> How many websites did you set up from scratch in Drupal, Joomla, >> WordPress? How many add-ons, themes, extensions, modules etc. did you >> develop for Drupal, Joomla and WordPress? >> > > More than you ever have, troll. That's for sure. Can you back that up? Your "extensive knowledge" of CM systems, that is. To put it bluntly: There is no PHP code in, say, a Joomla! database, unless you are really putting some effort into it placing it there. And even then - is ever parsed at all? Make me a believer: Show me some examples. You sound as if you have hundreds at hand (since according to you this "storing code in the database" seems a fairly common approach). >>> few people are going to learn how to write a module just to put in a few >>> filters or display something from another database. Rather, they'll put >>> it right in the page - which places it in the database. >>> >>> Sure, it's a potential security hole. But only if you don't know what >>> you're doing. Unfortunately, few programmers who use a CMS or >>> frameworks know how to secure a website properly. >> >> So what? This is not the problem of the CMS as it is not the problem of >> PHP itself that people without enough knowledge write bad code. >> >> > > I never said it was a problem with the CMS, troll. But...? > But once again you > can't read plain English. Seems as if I've the same problem. Can you point it out one more time? Taking a second look. You wrote: "You run virtually everything through index.php - something that's crappy programming except when most of your code is stored in a database as in a CMS." Here you state, that a CMS stores most (of the developers) code in the database. Which is of course utter nonsense. And: It's actually no longer "crappy programming", when you combine a front controller with all code stored in a database. Which just doesn't ring true. Or is there another interpretation at hand? Keep in mind that I'm a non-native speaker - is there some meta level I don't grasp? > I suggest you go back to digging ditches with your fellow troll Pointed > Head. If you can figure out which end of the shovel to use, that is. You forgot to mention me. I'm somewhat disappointed. Cheers, Gregor
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-30 15:18 -0500 |
| Message-ID | <n61e2f$tg6$1@jstuckle.eternal-september.org> |
| In reply to | #16013 |
On 12/30/2015 1:05 PM, Gregor Kofler wrote: > Am 2015-12-30 um 18:33 schrieb Jerry Stuckle: >> On 12/30/2015 5:26 AM, the well known troll Arno Welzel wrote: >>> Jerry Stuckle schrieb am 2015-12-29 um 02:48: >>> >>>> On 12/28/2015 8:31 PM, Richard Damon wrote: >>> [...] >>>>> Have made extensive use of Joomla and Drupal, I can say that having code >>>>> IN the database is the exception, not the rule. 99% of your code is in >>>>> normal php files in the modules used to build the site. They allow, but >>>>> discourage the ability to place snippets in the database to allow >>>>> building more complicated conditions/'rules' for behavior, but this >>>>> comes with major warnings that if you allow this to be done, you have >>>>> opened a major security hole in your site. >>>>> >>>> >>>> I also have had to pick up maintenance of Drupal, Joomla and WordPress >>>> sites other programmers have screwed up. I am *quite* familiar with the >>>> structure. >>>> >>>> Yes, most of the code is in modules and other files WRITTEN BY OTHER >>>> PEOPLE. But the majority of code YOU WRITE goes in the database. Very >>> >>> No - it doesn't. Don't mix up crap written by third parties with the >>> core or Drupal, Joomla or WordPress. >>> >> >> The troll once again proves he knows nothing about which he speaks. > > Sheesh, Jerry! Can you add some substance to your insults? > > >>> How many websites did you set up from scratch in Drupal, Joomla, >>> WordPress? How many add-ons, themes, extensions, modules etc. did you >>> develop for Drupal, Joomla and WordPress? >>> >> >> More than you ever have, troll. That's for sure. > > Can you back that up? Your "extensive knowledge" of CM systems, that is. > To put it bluntly: There is no PHP code in, say, a Joomla! database, > unless you are really putting some effort into it placing it there. And > even then - is ever parsed at all? Make me a believer: Show me some > examples. You sound as if you have hundreds at hand (since according to > you this "storing code in the database" seems a fairly common approach). > I don't need to. Look back through this newsgroup. The troll has never contributed anything worthwhile to this newsgroup; all he does is stalk other users. Yes, I can. The latest I have is in Drupal, where adding PHP code to a page places that code in the database. The code is then exec()'d when it comes out. I have made extensive use of it in a couple of sites where I need to access an external resource in a couple of pages, but not enough to require a module. The same is true in WordPress and Joomla. >>>> few people are going to learn how to write a module just to put in a few >>>> filters or display something from another database. Rather, they'll put >>>> it right in the page - which places it in the database. >>>> >>>> Sure, it's a potential security hole. But only if you don't know what >>>> you're doing. Unfortunately, few programmers who use a CMS or >>>> frameworks know how to secure a website properly. >>> >>> So what? This is not the problem of the CMS as it is not the problem of >>> PHP itself that people without enough knowledge write bad code. >>> >>> >> >> I never said it was a problem with the CMS, troll. > > But...? > Bo buts. >> But once again you >> can't read plain English. > > Seems as if I've the same problem. Can you point it out one more time? > > Taking a second look. You wrote: > > "You run virtually everything through > index.php - something that's crappy programming except when most of your > code is stored in a database as in a CMS." > > Here you state, that a CMS stores most (of the developers) code in the > database. Which is of course utter nonsense. > > And: It's actually no longer "crappy programming", when you combine a > front controller with all code stored in a database. Which just doesn't > ring true. > > Or is there another interpretation at hand? Keep in mind that I'm a > non-native speaker - is there some meta level I don't grasp? > >> I suggest you go back to digging ditches with your fellow troll Pointed >> Head. If you can figure out which end of the shovel to use, that is. > > You forgot to mention me. I'm somewhat disappointed. > > Cheers, Gregor > You don't read any better than Arno, do you? Typical. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-12-30 21:55 -0500 |
| Message-ID | <dO0hy.94816$tL.44836@fx34.iad> |
| In reply to | #16017 |
On 12/30/15 3:18 PM, Jerry Stuckle wrote: > > Yes, I can. The latest I have is in Drupal, where adding PHP code to a > page places that code in the database. The code is then exec()'d when > it comes out. I have made extensive use of it in a couple of sites > where I need to access an external resource in a couple of pages, but > not enough to require a module. The same is true in WordPress and Joomla. > > In Drupal, to add PHP code to a page via the database, you need to turn on the 'PHP' module. As described in the documentation https://www.drupal.org/documentation/modules/php there are major concerns about this, and would hardly be considered 'standard' procedure. Putting PHP code in the database is possible, but it not the 'standard' way to use the CMS. Developers will almost always create a custom module (or other points in the code of the site itself) to inject PHP code into a site (it really isn't hard), and the final users/maintainter tend to focus on 'content' (the C in CMS).
[toc] | [prev] | [next] | [standalone]
| From | Matthew Carter <m@ahungry.com> |
|---|---|
| Date | 2015-12-30 22:14 -0500 |
| Message-ID | <87wprvcnsq.fsf@ahungry.com> |
| In reply to | #16020 |
Richard Damon <Richard@Damon-Family.org> writes: > On 12/30/15 3:18 PM, Jerry Stuckle wrote: >> >> Yes, I can. The latest I have is in Drupal, where adding PHP code to a >> page places that code in the database. The code is then exec()'d when >> it comes out. I have made extensive use of it in a couple of sites >> where I need to access an external resource in a couple of pages, but >> not enough to require a module. The same is true in WordPress and Joomla. >> >> > > In Drupal, to add PHP code to a page via the database, you need to > turn on the 'PHP' module. > > As described in the documentation > https://www.drupal.org/documentation/modules/php > there are major concerns about this, and would hardly be considered > 'standard' procedure. > > Putting PHP code in the database is possible, but it not the > 'standard' way to use the CMS. Developers will almost always create a > custom module (or other points in the code of the site itself) to > inject PHP code into a site (it really isn't hard), and the final > users/maintainter tend to focus on 'content' (the C in CMS). Jerry is just a troll, whose main insult is calling other people trolls, I wouldn't even bother responding (I got caught up in a few in the past). If you see someone labelled as a troll by Jerry, chances are they are a pretty knowledgeable and useful contributor to the newsgroup (PointedEars, Arno, Gregor etc.). -- Matthew Carter (m@ahungry.com) http://ahungry.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-30 22:43 -0500 |
| Message-ID | <n62844$j60$2@jstuckle.eternal-september.org> |
| In reply to | #16021 |
On 12/30/2015 10:14 PM, Matthew Carter wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 12/30/15 3:18 PM, Jerry Stuckle wrote: >>> >>> Yes, I can. The latest I have is in Drupal, where adding PHP code to a >>> page places that code in the database. The code is then exec()'d when >>> it comes out. I have made extensive use of it in a couple of sites >>> where I need to access an external resource in a couple of pages, but >>> not enough to require a module. The same is true in WordPress and Joomla. >>> >>> >> >> In Drupal, to add PHP code to a page via the database, you need to >> turn on the 'PHP' module. >> >> As described in the documentation >> https://www.drupal.org/documentation/modules/php >> there are major concerns about this, and would hardly be considered >> 'standard' procedure. >> >> Putting PHP code in the database is possible, but it not the >> 'standard' way to use the CMS. Developers will almost always create a >> custom module (or other points in the code of the site itself) to >> inject PHP code into a site (it really isn't hard), and the final >> users/maintainter tend to focus on 'content' (the C in CMS). > > Jerry is just a troll, whose main insult is calling other people trolls, > I wouldn't even bother responding (I got caught up in a few in the > past). > > If you see someone labelled as a troll by Jerry, chances are they are a > pretty knowledgeable and useful contributor to the newsgroup > (PointedEars, Arno, Gregor etc.). > ROFLMAO! Spoken like a true numbnuts. One who has NEVER contributed ANYTHING positive to this newsgroup. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-30 22:46 -0500 |
| Message-ID | <n6288u$j60$3@jstuckle.eternal-september.org> |
| In reply to | #16021 |
On 12/30/2015 10:14 PM, Matthew Carter wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 12/30/15 3:18 PM, Jerry Stuckle wrote: >>> >>> Yes, I can. The latest I have is in Drupal, where adding PHP code to a >>> page places that code in the database. The code is then exec()'d when >>> it comes out. I have made extensive use of it in a couple of sites >>> where I need to access an external resource in a couple of pages, but >>> not enough to require a module. The same is true in WordPress and Joomla. >>> >>> >> >> In Drupal, to add PHP code to a page via the database, you need to >> turn on the 'PHP' module. >> >> As described in the documentation >> https://www.drupal.org/documentation/modules/php >> there are major concerns about this, and would hardly be considered >> 'standard' procedure. >> >> Putting PHP code in the database is possible, but it not the >> 'standard' way to use the CMS. Developers will almost always create a >> custom module (or other points in the code of the site itself) to >> inject PHP code into a site (it really isn't hard), and the final >> users/maintainter tend to focus on 'content' (the C in CMS). > > Jerry is just a troll, whose main insult is calling other people trolls, > I wouldn't even bother responding (I got caught up in a few in the > past). > > If you see someone labelled as a troll by Jerry, chances are they are a > pretty knowledgeable and useful contributor to the newsgroup > (PointedEars, Arno, Gregor etc.). > Oh, and I should add - Pointed Head, Arno and others are well-known trolls in multiple newsgroups by many people - not just by me in this newsgroup. For instance, ask about Pointed Head in comp.lang.javascript. You'll get an earful. And who besides a troll like Arno purposely unmunges other peoples' emails just so they will get spammed? Sorry - your lies are just too easy to disprove. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-30 22:42 -0500 |
| Message-ID | <n62828$j60$1@jstuckle.eternal-september.org> |
| In reply to | #16020 |
On 12/30/2015 9:55 PM, Richard Damon wrote: > On 12/30/15 3:18 PM, Jerry Stuckle wrote: >> >> Yes, I can. The latest I have is in Drupal, where adding PHP code to a >> page places that code in the database. The code is then exec()'d when >> it comes out. I have made extensive use of it in a couple of sites >> where I need to access an external resource in a couple of pages, but >> not enough to require a module. The same is true in WordPress and >> Joomla. >> >> > > In Drupal, to add PHP code to a page via the database, you need to turn > on the 'PHP' module. > > As described in the documentation > https://www.drupal.org/documentation/modules/php > there are major concerns about this, and would hardly be considered > 'standard' procedure. > I didn't say you don't have to enable a module. But that is the way many programmers put small amounts of code on a page. It's much easier and faster than creating a whole module when only a few lines of PHP are required. > Putting PHP code in the database is possible, but it not the 'standard' > way to use the CMS. Developers will almost always create a custom module > (or other points in the code of the site itself) to inject PHP code into > a site (it really isn't hard), and the final users/maintainter tend to > focus on 'content' (the C in CMS). Do they? I've seen a lot of code in Drupal pages, stored in the database. A module is NOT always the right way to do something. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-12-31 09:07 +0100 |
| Message-ID | <5684E23B.30100@arnowelzel.de> |
| In reply to | #16020 |
Richard Damon schrieb am 2015-12-31 um 03:55: > On 12/30/15 3:18 PM, Jerry Stuckle wrote: >> >> Yes, I can. The latest I have is in Drupal, where adding PHP code to a >> page places that code in the database. The code is then exec()'d when >> it comes out. I have made extensive use of it in a couple of sites >> where I need to access an external resource in a couple of pages, but >> not enough to require a module. The same is true in WordPress and Joomla. >> >> > > In Drupal, to add PHP code to a page via the database, you need to turn > on the 'PHP' module. > > As described in the documentation > https://www.drupal.org/documentation/modules/php > there are major concerns about this, and would hardly be considered > 'standard' procedure. > > Putting PHP code in the database is possible, but it not the 'standard' > way to use the CMS. Developers will almost always create a custom module > (or other points in the code of the site itself) to inject PHP code into > a site (it really isn't hard), and the final users/maintainter tend to > focus on 'content' (the C in CMS). The same is true for WordPress: There is no standard way to add PHP code to a page or post which would then be stored in the database. There are only some third party plugins who try emulating this using output filters (as <https://wordpress.org/plugins/allow-php-in-posts-and-pages/>) - but it is of course not recommended due to possible security problems and this is not part of the WordPress core framework. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-31 07:47 -0500 |
| Message-ID | <n637vr$j1v$1@jstuckle.eternal-september.org> |
| In reply to | #16025 |
On 12/31/2015 3:07 AM, Arno Welzel wrote: > Richard Damon schrieb am 2015-12-31 um 03:55: > >> On 12/30/15 3:18 PM, Jerry Stuckle wrote: >>> >>> Yes, I can. The latest I have is in Drupal, where adding PHP code to a >>> page places that code in the database. The code is then exec()'d when >>> it comes out. I have made extensive use of it in a couple of sites >>> where I need to access an external resource in a couple of pages, but >>> not enough to require a module. The same is true in WordPress and Joomla. >>> >>> >> >> In Drupal, to add PHP code to a page via the database, you need to turn >> on the 'PHP' module. >> >> As described in the documentation >> https://www.drupal.org/documentation/modules/php >> there are major concerns about this, and would hardly be considered >> 'standard' procedure. >> >> Putting PHP code in the database is possible, but it not the 'standard' >> way to use the CMS. Developers will almost always create a custom module >> (or other points in the code of the site itself) to inject PHP code into >> a site (it really isn't hard), and the final users/maintainter tend to >> focus on 'content' (the C in CMS). > > The same is true for WordPress: There is no standard way to add PHP code > to a page or post which would then be stored in the database. There are > only some third party plugins who try emulating this using output > filters (as > <https://wordpress.org/plugins/allow-php-in-posts-and-pages/>) - but it > is of course not recommended due to possible security problems and this > is not part of the WordPress core framework. > > > So it's not part of the core? There are a lot of things which aren't part of the core of WordPress in use every day. In fact, I would suspect most WordPress sites have additional modules - at least the sites I've seen generally do. And yes, it's not recommended for many CMS users they don't know how to handle security properly. It is perfectly possible to put secure code in the database. But you have to know what you're doing - which you have repeatedly proven you don't. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web