-
PHP 5.0.1 Released!
(News)
-
Version 5.0.1
12-Aug-2004
* Changed destructor mechanism so that destructors are called prior to request shutdown. (Marcus)
* Rewritten UNIX and Windows install help files. (Documentation Team)
* Updated several libraries bundled with the windows release which now includes libxml2-2.6.11, libxslt-1.1.7 and iconv-1.9.1. (Rob, Edin)
* Improved and moved ActiveScript SAPI to PECL. (Wez)
* Fixed unloading of dynamically loaded extensions. (Marcus, kameshj at fastmail dot fm)
* Fixed ReflectionClass::getMethod() and ReflectionClass::getProperty() to raise an ReflectionException instead of returning NULL on failure. (Sebastian)
* Fixed convert.* filters to consume remaining buckets_in on flush. (Sara)
* Fixed bug in mysqli->client_version. (Georg)
* Fixed bug #29606 (php_strip_whitespace() prints to stdout rather then returning the value). (Ilia)
* Fixed bug #29577 (MYSQLI_CLIENT_FOUND_ROWS undefined) (Georg)
* Fixed bug #29573 (Segmentation fault, when exception thrown within PHP function called from XSLT). (Christian)
* Fixed bug #29522 (accessing properties without connection) (Georg)
* Fixed bug #29505 (get_class_vars() severely broken when used with arrays). (Marcus)
* Fixed bug #29490 (.Net object instantiation failed). (Michael Sisolak).
* Fixed bug #29474 (win32: usleep() doesn't work). (Wez)
* Fixed bug #29449 (win32: feof() hangs on empty tcp stream). (Wez)
* Fixed bug #29437 (Possible crash inside array_walk_recursive()). (Ilia)
* Fixed bug #29431 (crash when parsing invalid address; invalid address returned by stream_socket_recvfrom(), stream_socket_getname()). (Wez)
* Fixed bug #29409 (Segfault in PHP functions called from XSLT). (Rob)
* Fixed bug #29395 (sqlite_escape_string() returns bogus data on empty strings). (Ilia, Tony)
* Fixed bug #29392 (com_dotnet crashes when echo'ing an object). (Wez)
* Fixed bug #29368 (The destructor is called when an exception is thrown from the constructor). (Marcus)
* Fixed bug #29354 (Exception constructor marked as both public and protected). (Marcus)
* Fixed bug #29342 (strtotime() does not handle empty date string properly). (Ilia)
* Fixed bug #29340 (win32 build produces invalid php_ifx.dll). (Edin)
* Fixed bug #29335 (fetch functions now use MYSQLI_BOTH as default) (Georg)
* Fixed bug #29291 (get_class_vars() return names with NULLs). (Marcus)
* Fixed bug #29264 (gettext extension not working). (Edin)
* Fixed bug #29258 (variant_date_from_timestamp() does not honour timezone). (Wez)
* Fixed bug #29256 (error when sending large packets on a socket). (Dmitry)
* Fixed bug #29236 (memory error when wsdl-cache is enabled). (Dmitry)
* Fixed bug #29147 (Compile Error in mnoGoSearch functions). (Sergey, Antony)
* Fixed bug #29132 ($_SERVER["PHP_AUTH_USER"] isn't defined). (Stefan)
* Fixed bug #29119 (html_entity_decode() misbehaves with UTF-8). (Moriyoshi)
* Fixed bug #29109 (SoapFault exception: [WSDL] Out of memory). (Dmitry)
* Fixed bug #29061 (soap extension segfaults). (Dmitry)
* Fixed bug #28985 (__getTypes() returning nothing on complex WSDL). (Dmitry)
* Fixed bug #28969 (Wrong data encoding of special characters). (Dmitry)
* Fixed bug #28895 (ReflectionClass::isAbstract always returns false). (Marcus)
* Fixed bug #28829 (Thread-unsafety in bcmath elementary values). (Sara)
* Fixed bug #28464 (catch() does not catch exceptions by interfaces). (Marcus)
Generated on August 13, 2004.
-
Hardening The Security of Your Website
(News)
-
the webserver itself. There it analyses all requests coming to the webserver and checks them against a set of definable rules.
If the request passes all these checks then the page is served to the end user. If there is a match then ModSecurity can take a number of actions, including doing nothing, logging the request, or simply denying the request with an error message.
I highly recommended ModSecurity as a tool against hackers, it says it has a slight performance hit but in my testing it wasn't noticable at all. Obviously ModSecurity is only for those people who have root access to the server where their site is hosted, as it's a plugin module for Apache.
It's really a layer 7 firewall for your webserver and it does an excellent job. I've had a number of people try to exploit a website I run with a PostNuke hack (now fixed by the recent patch), it was stopped by ModSecurity though because the exploit when it connects to your site doesn't send a browser version and I had ModSecurity configured to deny all attempts to connect if no browser version was present.
Setting it up is quite easy, there's a few basic filters that come with it out of the box but you'll want to modify those and add new ones as you see fit.
I won't go into anymore detail here, if you're interested then please take a look at the ModSecurity website, it has everything you need to get ModSecurity setup and working to your needs.
Finally, another tool for those of us using Linux to serve up their PostNuke sites is a kernel patch called grsecurity. I won't go into all of it's features but it really is a brilliant piece of code. Should your webserver get hacked, grsecurity properly configured would make it very hard for the hacker to get themselves a rootshell or install any backdoors. If you understand how to compile your own Linux kernel you should really look at this patch, I use it on all my production servers.
I hope this short article will help some of you with the security of your PostNuke sites.
Regards,
Ti
Generated on April 28, 2004.
-
Phoenix Template Rendering Engine Overview
(News)
-
What is a template
rendering engine?
A template rendering engine is the total separation (abstraction) of an
application business logic and rules from the content layer (output HTML, XHTML,
XML, PDF, etc.).
It includes dynamic variable substitutions
(replaces keywords or place holders with content), dynamic block substitutions
(for example the result of a record set from a query, for instance the number
of available news topics on the news index), amazing capabilities to process
unlimited nested loops among many others.
Conditional statements ( [if/elsif/else]
which allow you to make decisions based on user interaction in a easy to understand
way - optional).
The problem here is many template
solutions for PHP are based on regular expressions replacements, which highly
complicated the code and added an immense overhead into the application, this
regular expressions metaphor where hard to extend (and to adjust to taste),
and did not quite provided the complete separation of presentation and logic
(for example, to make rows of a table alternate colors, PHP code had to be adjusted).
Instead of following this route and
live with this and many other drawbacks, Phoenix takes advantage of a revolutionary
concept in template rendering engines, provided by the underlying architecture
of Smarty. The compilation of templates, which combines the speed of execution
of pure PHP code with the ease and simplicity of template syntax.
By using this approach template files
are first converted into PHP scripts before they are executed. This may sound
costly in terms of performance until you consider that this need only be done
when the template file is changed! Once a template file is compiled, they are
stored for later use (and re-use) using a caching mechanism, the end result
being a reduced overall server load. Which can be greatly enhanced (up to 500%)
by the use of PHP optimizing technologies like php-accelerator or the zend optimizer.
The second biggest advantage is extensibility,
this is what really makes it invaluable for programmers and designers a like.
How
does it work?
Basically templates work quite similar to
any ordinary HTML page, it uses template "tags" to distinguish dynamic content
(data provided from the DB for example), from the rest of the template which
is pure HTML. This tags are then automatically replaced with the result of the
requested data set. All template functions are loaded on demand this means that
even though the rendering engine is extensive in its core it will only load
the required code to perform each task.
While working with templates you have
access to a wealth of resources, among them are:
Variable modifiers (allows you to
transform on the fly the properties of your content, i.e. Caps, indentation,
upper, lower, etc)
Configurations files, this allow you
to define settings for colors, width and practically every aspect of the HTML
properties.
A wealth of Built-in functions which
you can extend, like free block/module positioning, forms, automatic clocking
and encoding of email addresses, and many more.
You can easily add and extend with
your own functions the engine by taking advantage of the plugin architecture.
Many new possibilities arise with
the capability of automatic inclusion of static content either local or remote
on the fly.
Caching Mechanisms designed with great
granularity allows you to specify how, when and how often cached content is
to be updated (turning your site as fast as static HTML) and under which conditions.
Advanced
Features:
Prefilters
Are
a set of functions that are run on the templates prior to them being compiled
with the engine. (i.e. removing unwanted comments form them)
PostFilters
This are functions that are executed after the templates have been compiled.
And
could help add valuable data to the whole of your templates if needed on the
fly.
Output Filters
This
feature allows you to apply settings to content while being executed as opposed
to the postfilters which are applied just before saving the compiled template.
Multiple Template sources
Templates
may come from a variety of sources, like file system or the database.
Debugging Tools
Intelligent
debugging console which allows one to trace all items related to any and all
templates used diring the course of a page rendering.
The pnTemplate API
This
(Template Application Programming Interface) provides a set of tools that allow
programmers to harness the full set of combined resources that PostNuke and
Smarty provide.
It follows the pnAPI naming conventions
and style and will become easy to understand and apply for module/block programming,
taking current modules and block to the next level of usability, flexibility
and power.
The Phoenix Administration (system)
Module
It’s the front end for all
this power and flexibility, it manages Themes, which are composed of templates,
that in turn have interesting properties like content type (html, xhtml, csv,
rss, pdf), they also belong to a layout, each template in a theme can belong
to a different layout, lets say you create a "dual column" layout and an "art
deco", layout for theme "Postnuke", then you can switch among this with the
click of a mouse, and then apply this system wide, templates also belonge to
specific zones (header, footer, module content, block etc.)
Templates install them self’s
similar to how modules do now, you just drop in the theme, initialize and activate
it and you are done. Same goes for upgrades or removal.
In the Phoenix administration module
you can manage all aspects of the rendering engine, including but not limiting
to all properties that control the behavior of smarty, as well as create, edit,
delete templates and its related itmes online, since you can choose to use file
system templates or db templates or a combination of both, you can directly
upload new sets of templates from your computer.
You have access to CSS and many more
properties and features, the best part of it all is, that you can have the old
themes right along with the next generation and also switch back and forth among
them with ease.
Templates Programming Language
and Active Zones
While working with templates
as mentioned before you can either use the basic template "tags" and normal
HTML or go beyond the choice is yours, the rendering engine provides enough
resources to make your templates intuitive and intelligent accomplishing quite
complex task with great ease, this is done by the use of what we call the "active
zones". Active zones are special place holder areas in your templates that allow
execution of commands from the template rendering language or invocation of
plugins, filters, variable substitution, etc.
This, active zones, are easy to use
and apply and will make your life very simple and productive while customizing
and designing the site of your dreams.
In conclusion the Phoenix Template
Rendering Engine can answer the needs and requirements of both novices and
seasoned developers or graphics designer. And it supports popular HTML editors
like DreamWeaver among others allowing you to use visual tools to enhance your
experience and over-all productivity harnessing all this power in one simple
place.
For reference if you happen to read this before the principal article of this series please read the first part which you will find here:
http://news.postnuke.com/modules.php?op=modload&name=News&file=article&sid=2357
Note: [ For clarification 1st quarter refers to the 1st four (4) months [Jan-Apr] of 2003, thus the goal is to have the 0.8
Generated on February 11, 2003.
-
Postnuke caching idea
(News)
-
9/11 where among others cnn.dk (which is one of the sites for which the caching was designed) went down due to insane load spikes.
As Karateka correctly states, outputting pure html can increase the performance up to 3000%. especially because you can then use i.e. a kernel web server to speed up things even more (zero-copying etc.).
Shortly put, the method worked like this:
The webserver served all pages (except pages that had to be dynamic (like welcome ) as a static page (ie. rewrite url -> static url). Then a backend system watched the Database for changes, and updated the relevant static pages, whenever a change occured that infected a given page.
This removed the normal "caching-delay" of caching systems, as every page was updated immediately, once the database change had occured (we used triggers, as it was Oracle).
This also meant that we had to find a way to allow for blocks, like "latest news" to function, without having to change every page on the system, because that block had to be updated (this was found to be best done (by the html-designers), by using Iframes - and putting that blocks in a seperate static file and letting the browser "compile" the page).
This approach, meant that the system could easily disable all none-static requests (or just give them low priority) if the load was high - keeping the rest of the site online.
A system like that, would be very cool for Postnuke, and the cool thing was that we didn't have to optimize our site-generating code - as we just inserted this caching system in front.
What do you think? would this be a good idea for Postnuke? if(!) it could be made to work with postnuke, it could be very cool.
--
Regards,
Klavs Klavsen - kl at vsen.dk - http://www.vsen.dk
Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child who is carrying a .38.
Generated on January 27, 2003.
-
Comprehensive List of Recent Language Packs
(News)
-
Why compile such a list?
Currently, some language files may be found via
a) notices on postnuke.com's language area, b) the results
of a "language" search on that site c) the PN site on
sourceforge 3) searching the PN download page and 4) searches on the Internet.
I think there should be one comprehensive collection,
so that people don't have to go through the searching
above (unless they really, really want to).
* As there are quite a few packages out there
please send the following information so that
we may properly make them available centrally.
I'd like to make this list as COMPREHENSIVE,
PRECISE, and USEFUL as possible. I appreciate your cooperation and input, in advance.
* I also know that some of the packages that have been released have ...issues. This is an excellent opportunity
to re-release a package that you have already released, perhaps based on your post-release fixes? My humble suggestion.
1) URL(s) where the package may be downloaded.
2) precise name of package file(s) - please note
all file names such as .zip and tgz versions, etc.
3) pn version for which the packs are intended
(please use precise version numbers such as 714,
etc., and avoid pn71x, etc. When the package can
be used by more than one pn version, please indicate
precisely which versions they would be, e.g., "both 713
and 714," etc.
4) Date of release.
5) Person(s) making the release.
6) Contact info.
7) Any special characteristics (additional translation of some add-on modules are included, some portion of pn
is not translated, etc.)
* If the case where some of the above information is
noted at the download site or within the package, etc., please copy/paste that information and include in your
response to this call for contributions. This will help to
make the compilation trouble-free and precise.
* Please send your contributions for the list to:
*** laszlo@issho.org ***
The deadline for contributions is September 1.
Please DO NOT send questions asking about the
language packages' availability. When it is ready,
the data will be provided in the appropriate location.
Thank you.
Tony Laszlo, Tokyo
http://www.issho.org/laszlo.html
Generated on August 24, 2002.
-
PETS issues warning to PostNuke Dev Team
(News)
-
'There is no need for software to be mistreated in this way so that companies
like these can market new products.' said Sascha Endlicher, spokesperson for
PETS. 'Alternative methods of testing these products are available'
According to PETS, these companies force software to undergo lengthy and
arduous tests, often without rest, for hours or days at a time. Employees are
assigned to 'break' the software by any means necessary, and inside sources
report that they often joke about 'torturing' the software.
'It's no joke,' Sascha said . 'Innocent programs, from the day the are
compiled, are cooped up in tiny rooms and 'crashed' for hours on end. They spend
the whole lives on dirty, ill-maintained computers, and are unceremoniously
deleted when they're not needed anymore'.
Sascha said the software is kept in unsanitary conditions and is
infested with bugs.
'We know that alternatives to this horror exist.' he said, citing industry
giant Microsoft Corporation as a company that has become successful without
resorting to software testing.
Generated on August 4, 2002.
-
Template engines living together happily ever after .8 ?
(News)
-
1. there are (at least) 2 distinct parts to templating :
a. producing the individual block or module function output ("block" template)
b. fitting the pieces together into a page layout ("page" template)
2. with block layout and smarty (used by Encompass) and many other templating systems out there, a template is "filled in" simply by passing variables to the template engine. The engine will do the actual work of producing the output for that template (and how it does that is its business).
3. the template engine will generally start with the "page" template to figure out which pieces it needs, then call some function to fill in each individual "block" template, and then put it all together.
4. many template engines for PHP (including block layout and smarty) "compile" their templates (both "block" and "page") into PHP code
5. there is no (technical) reason why you couldn't have different template engines for "pages" and "blocks". In fact, a 'switch function' at the right place could even decide to let one particular "block" be processed by block layout, the other by Encompass, the third by ModeliXe etc. - remember, processing in this case is generally nothing else than executing some plain PHP code (or compiling the template into PHP first).
6. Block layout has been chosen as the default template engine+language for "block" templates in PostNuke. Good - that means that I, as a module developer, know that if I write my code & templates for that, at least I know my module/block will show some output on all PostNuke installations by default.
The block layout tags aren't much different (conceptually) from other template engines, and for "block" templates, I know I'll only need a small subset of all available tags most of the time anyway, so it's not a big problem.
[perhaps we could even imagine having some automatic translator from Encompass/ModeliXe/... to block layout syntax for simple "block" templates at some point in the future, so that people can develop in one, and release it in the default BL format + their own format (see below)]
7. Block layout has also been chosen for "page" templates in PostNuke. It's basically invoked by calling a single function in index.php to process the "page" template, which then calls other functions to fill in the different "block" templates.
And here is where things get "interesting" :-)
Suppose I have a standard site, with "pages" defined with block layout, and I want to switch to -say- Encompass as "page" template engine, e.g. because I'm using it now and I'm happy with it, or because it offers better/easier control of what goes where on different pages, or whatever.
So here's the situation so far :
a. I don't want to translate all individual "block" templates (from all modules & blocks) into Encompass syntax, but I may want to re-create *some* of them with Encompass anyway (perhaps because I'll be able to make use of feature XYZ better then)
b. I want to be able to define my "page" templates with Encompass
With all the observations above, and with the right 'switch functions' in place, do you see any *major* obstacles in using Encompass as "page" template engine, and a mix of standard block layout + a few customized Encompass templates for "block" templates ?
I don't... Of course, there's the fact that you're "running" 2 template engines now (although most of the processing is done only once, when the templates are "compiled" into PHP code), and there are some issue with how variables from blocks/modules should be passed to the different template engines, etc., but this certainly classifies as "feasible".
How would this compare with the current situation ?
1. blocks and modules are templated in a standard (default) way with block layout - no more digging into code to change "block" output
2. you can override the 'default' templates for each "block" with your own (for different themes), not only in block layout format but also in other template engine languages
3. you can use the template engine of your choice for defining different "page" templates (which is where the major pain of customisation is)
How's that for choice ? I'll leave the detailed analysis & implementation as an exercise for the reader :-)
Mike.
Generated on August 3, 2002.
-
Multisites...
(News)
-
Can you please compile a seperate release of the latest postnuke version set up with the directory structure and sql in place for people that want to take advantage of this feature.
This way we can use it as an example to go by.
I as well as many others that have left posts in the forums and in the irc chat room can not completely figure out what we are to do to make this happen.
I think since the developer of this feature knows what he/she is doing that them creating a distribution that is specific to multisites functionality is the best and easiest solution.
I don't think I am alone in this and hope you will seriously consider this as a viable solution.
I think this will also cut down on the support time that it takes to field and answer all the questions concerning multisites. So in the long run the developers can continue working on their present projects rather than having to take time away from them to answer all our questions.
It seems that the only person that really knows what is going on with the multisite feature is the developer/creator of this feature.
The multisite feature is a really great idea I only wish I fully understood what to do to get it working.
Thanks for any assistance and I really appreciate all the great work that the developers are doing.
Richard Wing
Generated on February 15, 2002.