• Search:



Planet eZ publish




ez publish community gateway

› Joining eZ Systems as Online Community Manager

I want to share some exciting news with our community. I will be joining eZ Systems as Online Community Manager and I hope to pick up where Nicolas Pastorino left off, as he parted eZ Systems back in August, 2014. This will be a part time position, I will continue as a member of the Community Board, and keep any other activities.

27/03/2015 7:04 pm (UTC)   http://share.ez.no   View entry   Digg!  digg it!   del.icio.us  del.icio.us

mugo web

› Custom fatal error message for eZ Publish (legacy)

Until some time ago, it was necessary to hack the eZ Publish legacy kernel in order to customize its generic error message, "Fatal error: The web server did not finish its request". This error occurs on all eZ Publish installations whenever there is an HTTP 500 status server error. It is a very common error; some examples of how it's triggered include: trying to access the value of a non-existent object attribute; the use of a non-existent PHP class or function; and too much memory usage.

Now, since this pull request from Mugo has been merged to the eZ Publish kernel, we have made it possible to customize the error page without hacking the kernel. In this post I will show you the new standard way to do this with a simple INI setting and your own PHP function.

26/03/2015 5:52 pm (UTC)   Mugo Web   View entry   Digg!  digg it!   del.icio.us  del.icio.us

ez publish community gateway

› Custom fatal error message for eZ Publish (legacy)

Until some time ago, it was necessary to hack the eZ Publish legacy kernel in order to customize its generic error message, "Fatal error: The web server did not finish its request". This error occurs on all eZ Publish installations whenever there is an HTTP 500 status server error. It is a very common error; some examples of how it's triggered include: trying to access the value of a non-existent object attribute; the use of a non-existent PHP class or function; and too much memory usage.

Now, since this pull request from Mugo has been merged to the eZ Publish kernel, we have made it possible to customize the error page without hacking the kernel. In this post I will show you the new standard way to do this with a simple INI setting and your own PHP function.

26/03/2015 4:22 pm (UTC)   http://share.ez.no   View entry   Digg!  digg it!   del.icio.us  del.icio.us

mugo web

› Mugo Web and Royal Columbian Hospital modernize emergency department shift evaluations

Mugo Web and the Royal Columbian Hospital / Eagle Ridge Hospital emergency departments have created an online shift evaluation system now in use in 5 emergency departments across the region. The system is called Online Daily Evaluations and is being used at Royal Columbian Hospital, Eagle Ridge Hospital, Vancouver General Hospital, Victoria General Hospital, and Kelowna General Hospital.

24/03/2015 2:48 pm (UTC)   Mugo Web   View entry   Digg!  digg it!   del.icio.us  del.icio.us

derick rethans

› Xdebug 2.3: Improvements to Debugging

Xdebug 2.3: Improvements to Debugging

This is the fourth article in a series about new features in Xdebug 2.3, which was first released on February 22nd.

In this article we are looking at the improvements towards "remote" debugging. The first improvement is the addition to view the values of user defined constants.

  • issue 406, 495, 1066, 1084 (debugging section)


Other parts in this series:

24/03/2015 10:12 am (UTC)   Derick Rethans   View entry   Digg!  digg it!   del.icio.us  del.icio.us

netgen

› What do eZ Publish CMS, Symfony PHP framework, and Sylius e-commerce have in common? Find out on 25 March at the workshop in Osijek!

Recently we became a proud member of the Osijek Software City project, whose members started organizing CodeCAMP training program in January. At the CodeCAMP on Wednesday, 25 March at 16:30 CET, our Ivo will hold a workshop named “What do eZ Publish CMS, Symfony PHP framework, and Sylius e-commerce have in common?in BIOS, Osijek.

18/03/2015 4:39 pm (UTC)   http://www.netgenlabs.com/Blog   View entry   Digg!  digg it!   del.icio.us  del.icio.us

netgen

› The eZ Publish Show #24: Externalising legacy code

Following the post on share.ez.no I invited eZ Engineering team to The eZ Publish Show to give some more details on the last developments with eZ Platform. So Bertrand Dunogier, one from the team, joined the hangout and talked about how they achieved legacy code externalisation and gave some more info about the new installer. 

18/03/2015 2:26 pm (UTC)   http://www.netgenlabs.com/Blog   View entry   Digg!  digg it!   del.icio.us  del.icio.us

netgen

› The eZ Publish Show #24: Externalising the legacy code

As mentioned in the post on share.ez.no, I invited eZ Engineering team to The eZ Publish Show so they can give some more details on the last developments with the eZ Platform. Bertrand Dunogier, one of the team members, joined the Hangout. He talked about how they achieved legacy code externalization, and he also gave some more info about the new installer. 

18/03/2015 2:26 pm (UTC)   http://www.netgenlabs.com/Blog   View entry   Digg!  digg it!   del.icio.us  del.icio.us

ez publish community gateway

› eZ Community Board meeting minutes - March 2015

Here are the minutes of the latest Community Project Board meeting, March 11 2015. Our previous minutes can be found here

17/03/2015 6:10 pm (UTC)   http://share.ez.no   View entry   Digg!  digg it!   del.icio.us  del.icio.us

derick rethans

› MongoDB 3.0 features: Big Polygon

MongoDB 3.0 features: Big Polygon

MongoDB has had geospatial query support since MongoDB 1.4. In subsequent versions we have added a range of new features, such as GeoJSON in MongoDB 2.4. In this post I will cover a new feature in MongoDB 3.0 for searching polygons that are larger than a hemisphere.

Finding objects in a specific area (polygon) can be done with the $geoWithin operator as illustrated below:

demo->points;

$c->find( [
    'loc' => [
        '$geoWithin' => [
            'type' => 'Polygon',
            'coordinates' => [ [
                [ -0.91, 51.74 ],
                [ -0.91, 51.27 ],
                [  0.67, 51.27 ],
                [  0.67, 51.74 ],
                [ -0.91, 51.74 ]
            ] ]
        ]
    ]
] );
?>

The GeoJSON format, which we use in this query as argument to the $geoWithin operator, defines a polygon as an array of linear rings, which themselves are a list of coordinate pairs beginning and ending with the same point to form a closed ring. The first linear ring is required and defines the exterior boundary of the polygon. Subsequent rings, if specified, would define interior boundaries (i.e. holes) within the polygon.

As an image, the geometry in this query looks like:

The GeoJSON format specification does not give any meaning about the direction or winding of points. The application is left to determine which side of the geometry is the search area. Both of the following images are possible interpretations when just taking the GeoJSON specification into account:

The interpretation of which part forms the search area would of course provide very different results! Because GeoJSON does not address winding, sometimes applications make wrong decisions.

MongoDB deterministically chooses the area that is the "smallest of the two". For our query, it would consider the polygon that is shown first of the two interpretations shown above.

This logic works for most applications, but it falls apart when you want to find objects within a polygon that spans more than a hemisphere.

In the small example of London, you would certainly expect the smallest area, the one that covers London to be the search area. But when we consider this much larger polygon (a circle centred around 25°N, 90°E with a diameter of 115°), then it is not so obvious:

When the polygon is larger than a hemisphere, i.e. larger than half of the Earth's surface, the "smallest of the two" is actually the area we intended to exclude. From MongoDB 3.0 a custom coordinate reference system (CRS) is supported, which forces geospatial queries with a polygon search area to consider the direction of coordinates in deciding which side is the search area. Consistent with KML, and WKT/WKB, the search area is determined to be the area that is on the left hand side of the direction of points. MongoDB calls this "strict winding". With strict winding enabled through our custom CRS, the following two possibilities can be considered:

MongoDB's implementation of GeoJSON allows us to specify a custom coordinate reference system on any geometry object via a crs property. Currently MongoDB only supports our custom CRS, urn:x-mongodb:crs:strictwinding:EPSG:4326, to specify strict winding. In the future, MongoDB could also support others, such as UTM, the US National Grid, or the UK's Ordnance Survey National Grid. The addition of support for this crs property is called "Big Polygon support" in MongoDB.

In a query, our custom CRS would appear as an extra argument within the $geoWithin or $geoIntersects criteria, on the same level as type and coordinates:

demo->points;

$c->find( [
    'loc' => [
        '$geoWithin' => [
            'type' => 'Polygon',
            'coordinates' => [ [
                [ -0.91, 51.74 ],
                [ -0.91, 51.27 ],
                [  0.67, 51.27 ],
                [  0.67, 51.74 ],
                [ -0.91, 51.74 ]
            ] ],
            'crs' => [
                'type' => 'name',
                'properties' => [
                    'name' => 'urn:x-mongodb:crs:strictwinding:EPSG:4326'
                ]
            ]
        ]
    ]
] );
?>

The use of the custom CRS is only relevant when searching an area that is larger than a hemisphere. In most cases, the default "smallest of the two" behaviour will be sufficient and you will not need to specify a custom CRS.

17/03/2015 10:07 am (UTC)   Derick Rethans   View entry   Digg!  digg it!   del.icio.us  del.icio.us