Symphony.

I can confirm the bug and the fix, and I did not notice any side effects.

However, I think there might be a more elegant solution to build the $where string in the patch. If the code is considered fine, it should be pulled (and trailing whitespace might be removed).

[EDIT]: Maybe @brendo can take a look?

Probably there would be something more elegant but did first thing that came to mind - as the view was required on a project I am working on; better have it working then not.

Hopefully I can start contributing to the community slowly :)

I really appreciate your fix, and actually I had no idea how to make it "more elegant". :-)

I just thought that @brendo might take a look because I know that he is around 328 times better than me when it comes to PHP coding! :-))

I'll hold off,but hat off to @gunglien for spotting it. (It could also fix a bug in one of my extensions)

I found the same bug when selecting multiple pages, and @gunglien's fix worked.
But the extension has not been updated yet...

Is this logged on github? I plan to go through the issue trackers for Symphonists and Symphony extensions at some point soon.

yep issue is logged into github and there is a pull request. I've fixed some small things for 2.3 compatibility on a local copy at home if you want I can possibly issue pull requests as well once 2.3 is out so I don't mess it all up yet :)

I'm also pretty sure that klaftertief was updating this field heavily to use the new PageManager class. I made a start but held back when I found he was doing this. Not sure if he's send pull requests yet or not though.

ahh if its already being done best not to touch then :)

I updated most page related SQL queries to use the new PageManager, but haven't send any pull requests because I didb't touch the getToggleStates() method. The reason was that the PageManager (PM) doesn't support to query by multiple page types. Also I wanted to add a negation filter, which the PM doesn't have. Didn't find the time to implement it properly, only did some SQL research. This linked issue is about the Navigation DS though, but both areas would benefit.

I could prepare a pull request for the normal queries later today, but maybe we should discuss and wait for the more complex stuff at first.

What's the current situation with using this in Symphony 2.3? The experimental branch looks like it would be the one to try?

is that not possible to mix the page select field with the standard select field an put it in the symphony core system ?

I think page select is a important feature !

David, the experimental branch works just fine; used it in a personal site (live) recently and had no problems with it.

@quma, the Symphony core has the most important extensions included, its meant to be flexible if people don't use it they don't need to install it. Its an easy step to install it.

@gunglien: thanks - good to know. Installed. :)

@gunglien

the Symphony core has the most important extensions included

No this is not the case ! the coresystem can't show images on the index and edit pages, there is no a filesystem and multiupload function and much much more important functions are missing.

The problem with the 3th-party extensions is:

1. after a major core-update the most of the extensions not work

2. many extensions are not compatible with each other

3. You cant change a field in your sections without loss all your data

@quma it depends what is Essential to you.

First of all when I install I do not use the 'default' workspace so I get to re-create all the sections just how I want them.

In my environment having a filesystem/multiupload is completely useless. As I have a multi-server setup in some cases and the above step wouldn't cater for now my servers work.

1. Yes but this would even count for WordPress or any other system - you wait or help them being supported.

2. Many devs are super supportive and would help if you point out

3. That's to be expected you just have to design properly the first time round.

Anyway This is not the right place for any discussion :) so we shall keep the discussion on topic from now on :)

A small question / query. Lately I've been working on something which has two separate search pages. One main search page (taking care of normal text-based search) and a sub-page searching events.

so the urls are as follows search events/search

now both these pages have the current page as search... is there a way to be able to distinguish when using the page select field. When selecting I can see the parent so Event:search however when filtering / in the output neither of these is made available. so when I try to match 'search' both of them come up, and I cannot select the correct item.

Filtering in a DS by the Pages Field, right? Try $current-page-id.

Ah yeah you're right that works... didn't cross my mind to use the id... saw the list using the handles and thought it required a handle.