was a HTML-displaying-problem. & q u o t ; did it

I better stick to input type=submit...

...I don't want them to be in the XML, only idea of mine is another table (sigh)

17.12.2005
made it "in progress". Another table is the way to go. Every page gets an intro
in a special table. Make also the create-statement in the Admin Library!

27.12.2005
Todo:

• add the table (in admin index) - easy
  
• add code to edit (make it an option in edit.php somehow) - accesible from Admin Index and the intro itself
  
• add code to show - should be easy

29.12.2005
done (for multipages)

I mean the behavior of multipages. Are they really doing what the user expects? I think there needs to be at least a change so that calling the page with an ID shows only that entry, or not?

22.11.2005 - at the moment, not even showing brief entries works! Prio 1

07.12.2005 - brief entries work and showing entry with the id also I think. Needs some testing

19.12.2005 - seems to be fixed for now

(maybe we need a "single" mode for entites where there is only one entry intended and then grouping means "all fields")

 

17.10.2005

done with singlepages 

Here is a good explanation how to have a plugin for picture upload and stuff.

This is crucial for novice users.

Could be fun testing.

21.11.2005  done - some configuration might still be to be done. and it is (like tinymce) not automatically uploaded.

notice that I had to adjust the file upload field in ibrowser.php, because it was so wide you couldn't see the button to actually start the upload... 

• finding an entry of a specific kind to edit it
• making a new simple page
• maybe insert the section-table in the db initially
• ...
  

a little "#" at the bottom would be the link.

 

08.12.2005

see ideas at bug Nr 59: init chmods, change htaccess-pass

and fileupload (another bug)

22.12.2005

• chmod wasn't possible
• finding needs an adjustment of showEntry (shoer lists, also not published) and an extra page
• a new singlepage has to be recognized somehow permanently as such - has to wait till the metadata is on the server

there is now an admin index with what I could do ... I'll close this superbug and make some small new ones.

See bugs: When all bugs are shown, they are ordered after priority and then grouped by state, but should be first ordered by state, then by priority and then be grouped. Now I see several groups for fixed, several for new, and so on.

Take a look at the SQL Query.

03.12.2005  - fixed, I switched both around. If a grouping field is given, it is first order by - criteria

In IE, there are several issues to cope with:

• the panes on the right sides don't fit
• submenu entries appear too high
• hover-over effects in menu do not work
• when editing a new bug, tinymce won't work
• The seach options do work, but look shitty

Some of these issues might be due to the iefix.css not being loaded, others not.

01.12.2005 - noe iefix.css is loaded (it didn't due to some maintenance two weeks ago). The first 3 issues are now working, but the others still aren't. The tinymce thing is not understood by now - I tried 15 minutes to find out what's wrong. The only thing I saw was that tinymce in IE does not force br...

01.12.2005 - updated tinymce to version 2.04 (from 2.03) and now it works. Leaves me with the search form... change topic to "showing"

02.12.2005 - updated to tinymce because 2.01 was ready (sigh) and fixed the styling of the search form within iefix.css. bug is fixed

To be used in German, all generated text that is visible on the page should be available in german, too.

This means that all those texts (like link texts, tool tips,...) should be be collected in a language file. There should be one for German and one for English, then.

Every Statement gets a number and all the code does is call a function that gives as param the number and language, e.g.

getText(13,"en");

 

27.12.2005 - After seeing the GNU gettext project: Maybe we should just make a call like this: _("Click here to see the page.")

That way the code stays readable and can be altered quickly. The language function would transalte all those strings (and is pretty good readable, too)

 

29.12.2005 - It works now, though I haven't translated it all into German yet. The call to the function is now "__()", since gettext is enabled on my server, but I define my own...

 

30.12.2005 - translated all so far

The SQL string fails because there are no values for the checkbox fields. Mayber an error in getParameters().

Also the error message is not shown. Why?

07.12.2005 - code still used old variable names... fixed

 

Several points regarding first installation have to be clarified or implemented in the first place:

1. When and how does the upload of files take place that are not in the publish-cycle:
1. not-generated files (e.g. pics)
   
2. plugin-files (tinymce, ibrowser, gallery,...) Legally best when available as option, technically best when upload per button-click (don't know how)
2. the directory structure has to be created on the server
3. some chmods have to be done (for ibrowser), also .htaccess ?
4. how are standard dirs for pictures selected? Option or no option?
5. a possibility to create the section table. maybe first and only option in admin-index-page
6. should the bash-file check if there is JAVA_HOME on the computer in the first place? Well, that's not so relevant after all...#

All this should probably result in one install.bash (or .bat) so that in this stage everything is preparable.

 

08.12.2005 - Answers

1. and 2. and (3.) I'll make an install-skript that uploads everything. That's not the intended usage for this, but better than nothing. chmods may only be possible in lftp, not for windows?

3. I think this could all be done by PHP

-the chmod-function could be used by a link on the admin page

-for htaccess there is a PHP class on PHPFree that AdminIndex could include or we use this PHP password protection method ...

4. no option for the time being.

5. place it on the Admin Index - how to check if it already has been done: if exists... in MySQL?

6. nah not yet

 

13.12.2005

    to 6: checked. JAVA_HOME needs to be set.

 

14.12.2005

everything done, only chmoding still needs to be done, but in PHP.

ftp doesn't give it. I even had to use wput.exe to upload all files ...

 

22.12.2005

switched to FCKeditor and configured it. done

Admins need to have a quick glimpse over what they have.
In this view, there need to be also the not published entries. That means:

• this view has to be non-public
• published/not published needs to be visible

In principle, we need only a little altering of the showEntry - Code (this is also useful for the idea about showing an index of headings at the top) and a little extra page for admins that only uses stuff we already have...

Perhaps use wordwrap or chunksplit and then explode (use only the first part of the array then...)

31.12.2005
done - for now, I only show the title-field, that suffices for this stage. Implemented a "go to list"-link when the admin edited and wants to get back to the list.

just like with the intros, we can use the code that also handles the multipages. The SQL-Code, though, maybe maintained because the key is assembled from page and id (also the case with comments, so look for reusing that there).

04.01.2006 - almost done. little bugfixing still left...

15.01.2006 - I'll close it now.

some words are in separate rows...

19.01.2006 - in CSS one should be careful with the * - Operator...
lokks good now. fixed

• Searching for "Achim" is impossible -- "Achi" works, though
  • works on the PP site - and: Please try to find a less specific way to describe a problem. I can't imagine how to investigate this.
• When I offer "SML" as a click-n-search possibility, the result looks like this
  • this seems to work now. The rest of the problem is the keyword-in-HTML-Bug already described.
• Searching produces old database entries that should have been deleted long ago (this should probably be an own bug) -- I looked through my database, I can't find multiple versions of the same entry.
  
  • you are describing this one below, I think. And it's better described there.
• Search does not include gallery-captions
  • those are in text files, not in the database.
• Using the search box and typing "Söhlke" did not produce a result. i had to type "Söhlke" to find the about page. Same for 中国
  • Well, that's how we save things in the DB. We could make ö to ö when searched...? This is one of the great topics before 1.0.
• Searching for "Anke" finds Kr-anke-nkasse, d-anke, B-anke-n etc. but not "Anke"
  • works on PP. Maybe we'll observe a pattern someday...
    
    • Does it work for (Anke, too? -- yes, but not for (Anke. And still not on my site
      
•  Searching for "anke" on PP is quite funny, too, as you will get the same results over and over again -- plus the statement: "There is no entry in the database meeting the search criteria..."
  • now that is one of the two problems I can work on.

05.02.07
Some issues are now resolved:
The link of the result now actually links to the page it was found on, not to "_search".
And you don't get some results multiple times. PP returned results from singlepages as many times as there were singlepages (any) in the db. Oops.
And you don't get the message "There were no results..." for pages on which PP didn't find anything.

5.2.07
This is funny, too. Showing us the work still to come?
Searching for strings including spaces makes the thing go wild, too. The problems are:
1. search term begins with space: " TERM"
2. search term ends with space: "TERM "
3. search term is space: " "

6.2.07
I think, I found something on the search-issues: I have the impression that a capital letter can be a problem. Searching for "elekommunikationsunternehmen" produced two matches (so it can't be length). As soon as I include the T, it doesn't work any more. Not for the whole thing and not for "Telekom". "Tele" works again, though, but does not find the entry with "Telekommunikationsunternehmen" in the Title. Hm.
"Firefox" produces one result (in a link). "irefox" produces more results. They are after the one with the link.
Case in the searchterm does not matter (no difference in "Firefox" and "firefox")

07.02.07
Now it would be interesting if that only holds for capital letters at the beginning of a word.

8.2.07
"2.0" finds some (not all) 200 and 2:0 as well

24.03.2007
I did a lot of work on this one and I think it should all be gone now.
For instance, it turns out that for case insensitive search you should not use blob field types. The text field types are equally good and allow for case insensitive search (there is  sql code in the svn to update the _sys_tables).
 
If there is anything serious left about searching, let's open another bug.

did I make id the only primary key?

19.01.2006 - yep

there is no result when you do a search in the admin/content - area

27.04.2006 - fixed

Maybe SQL Code has to be able to do two things:
-normal tables
-one-to-many relations within one table (singlepages: page-to-sections, comments: entry-comments)

That could be reflected and reused (e.g. for tagging)

31.01.2006
Closed this issue. In general, it suffices to have tables that indeed carry a PK field. Relations to FK fields can be made by inducing this value by the system (via the $params - array, see writeCommentForm()).
The special SQL code for singlepages stays, because it runs well.

for delivering this to users, it should be possible to get rid of all this XSL stuff.
All the metadata must be represented in the database and read by the PHP, because people don't like editing XML and calling a script (besides, you're not on your pc all the time).
this is a bunch of work, but the table data already comes from the db.
Just try to reuse as much as you can...

22.02.2006 - done

http://www.gnu.org/licenses/gpl.html
Include License in code files...

14.05.2006 - done

this leads to cleaning issues:
For all pages, delete/rename comments
for singlepages, delete/rename all entries in _sys_sections. In deletion case, we need an extra warning telling the user about this (how can we explain that this is the case only for singlepages? -> documentation issue!)

in index.php, we need to look for page=_sys_comments, cmd=edit or delete. Then call a function wich does the UPDATE statement.

02.03.2006
done in AdminIndexLib, no message to the user

it's off per default and that is not very intuitive

27.04.2006 - fixed

we need to convert them before we show a link, my test case was Gästebuch

15.05.2006 - seems to be fixed by something (I use urldecode() since some time), I had no problem anymore

it would give the designer a lot of freedom to be able to create own HTML templates.

They would be PHP files that reside in the style/templates - directory. They would contain only HTML and PHP calls to defined and documented functions, like this:
<?writeMenu();?>

Most of these functions already exist:
writeHeader();
writeMenu(); - writeSubMenu() should be separated out of that
writeSidePane(); - that needs to be divided into writeIntro() and writeFeeds()
writeFooter(); - should not write HTML, but the impressum and be renamed to writeImpressum();
writeSearchForm();

those are about to come:
writeToc();
writeData(); - writes all entry stuff...

there would be a default template that outputs HTML fitting to the default skin (picswap). index.php, admin/index.php and admin/edit.php would have to be cleaned of writing their own HTML and just find out which template to use.

another option in _sys_sys would be needed (the valuelist would be read from the file system).

In general, that's good for the code and should be work, but not impossible.

23.07.2006
would be really nice. A problem is that  a certain skin can only operate on a certain template. That is hard to handle (or just a problem of defining the skins)

24.07.2006
made it "in progress". I want to have it, so I can incorporate my Google Reader list :-)
writeIntroDiv, writeFeedDiv (and a future writeSideDiv or so) should also be separately available (and documented).
another problem: those functions should not need any parameters. So we would need a soultion for each of them and that would mostly be making them global (like params should long have been)
here is a list.

• $params
• $path_to_root_dir
• $title
• $feed_amount (in Sidepane - can just be retrieved from the Utils lib)
  
• $show (searchform and toc)
  
• $from_admin
• $res (for toc and writeEntries)
• $listview (writeEntries)
  
• $as_toc (writeEntries - comes from writeToc - should not be global, but a parameter, default false)

One more problem: for our default template, we have now a distinction between #data and #data_admin. How can we map that with one template?
Then we document all in one FAQ

25.07.2006
I think that write SearchForm() and writeToc() should not be publicly documented. saves a lot of hassle and they are controlled per page over the system preferences...
the $res - param should still be passed, because it is defintely meaningful and not just a configuration...

27.07.2006
two more problems to think about:

• the writeData method must be equipped not only to show a result set, but also some text (in case sthg went wrong). So the PHP stores some data (error text) in some variable that can be displayed when $res == "", I guess
  
• sthg I always wanted: Those HTML-writing methods should be given an indent parameter (that can also be left away and has a default). That way, all the HTML can look beautiful, no matter how complex it is. That is work, but not too much. The Code only has to be freed of that standard indent (replaced with a local $ind - variable). That replacement could maybe done automatically (replace "echo('        ", with "echo($ind.'" for example).

09.08.2006
done :-)

the default group overwrites the nr param when it comes to build the SELECT Query in getQuery().
I fixed that in version 0.9.1.

this is since version 0.9.0.
there only seems to be written '0000-00-00' to the database.
test case: bugs

fixed for the next version

a javascript error.
seems to be fixed.

some web providers do so for dome reason (the normal way is running PHP as apache module).
so we should go with a simple session way of authentication: I already have some code together that now needs to read the name and password from the db and llok nice...
it always redirects to admin/index.php but that's not too bad. That way, we can also logout. And it is time to replace the old 5 lines of authentication with an include of a file that does all that - it's just shorter....

A problem is: xampp, at least on windows, has a problem with the session files. One idea: use that session thing only when the former method doesn't work (when the AUTH-Vars are not set). That way, everybody is happy ...

19.07.2006
sessions seem to work with Xampp under Linux... ok, the only question now is which method gets higher priority...
this method can help finding out what the api interface to PHP is:
if (php_sapi_name() == 'cgi')... (other would be 'apache')

ok, fixed. the old method is the default

800 px is not enough. THey need to spread the whole width of the screen.

 

they are wide now...

qdig will feel much better, I guess...

I have seen enough buggy behavior with minimal gallery and face the final decision: I have to customize a better gallery for PolyPager.
At least that is a project that is still active...

09.08.2006
actually, it is not minimalgallery, it it firefox under linux that doesn't show some pictures, although the gallery has them. It was the same with qdig. I don't know what to do there...
Nevertheless, qdig has some advantages over minimalgallery:

1. it can browse subdirectories
2. it downsizes big pictures to a reasonable size
3. it is still maintained
4. you can edit captions online

so this bug is now "new", not "in progress", but this should be done...

19.09.2006
I did it. Sadly, I only could make it work with the HTML templates by putting it in an iframe - that is ok, but not really nice. Haven't figured out why, but it has problemsm finding pictures if I just include it from the write_data()-method...
Fixed anyway.

this only seems to affect version 0.9.4
12.09.2006
after the introduction of templates, auth.php would be called from different locations, so I added them all to the path.
if those fckeditor php scripts fail, you don't notice anything but failure of operation. phu
fixed.

which is:
Unknown column 'default_group' in 'field list'

that field was in the wrong table somehow. moved it into multipages now...
works...

Comments could only been ridicolous 255 bytes long, for whatever reason. Thanks to Jan for posting a longer one.
Also, some comments got indexed with the wrong page name when the form was displayed after a list of existing comments for that entry.
Both of those are fixed for Version 0.9.5

that bug occured because the standard template wasn't named anywhere...
fixed now

When you try to edit/delete such a page (i.e. "gästebuch") from the page-list in the admin-area, PolyPagerLib_Editing.php fails.

The reason is that it cannot determine wether this would be a single- or a multipage. While comparing it to all known pagenames, it compares "gästebuch" (from the db) with "g&auml;stebuch" (because the pagename already got converted with htmlentities() fpr displaying it).

It's fixed for version 0.96

normally, you'd just see a blank page if PolyPager doesn't find the skin.
And if something happens to the skin-directory, this can happen more often than I'd thought...

06.12.2006
done

nothing happens when I delete an entry from the page-list in the admin area.
I confirm the dialog that I want it, but then - nothing.
It works from the form, though.

Was local in my Firefox. Works everywhere else...?

The option list on the system properties - page omitted some of the skins.
Somewhere in the code I'm throwing out picswap from the found skin-directories to treat it special. The PHP-funvtion array_splice() didn't work at all like the documentation says. I'm angry and implemented a work-around for 0.9.7. piece o' shit...

the help popup is flittering when both the horizontal and the vertical position are corrected.

Done for 0.9.7
Now the popup will be moved to the left of the mouse cursor. The mouse just can't be over the popup.

this speeds up the page retrieval
 - done (0.9.8)

done for 0.9.8

Title says it all

07.01.2007
Fixed. Name of show_labels - Field changed to hide_labels in 0.9.8. Therefore, the values have to change, too.
-Nic-
P.S.: Prio 1? Really?

Priority 1 because I think everything that is not displayed any more as it was before after upgrading to a new version should have highest priority. It really is a nuissance if you upgrade and can't go to bed afterwards but have to work for another fortnight to make your site look as it did under the old version. Really!
-jan-

Good point, but this was just an error on polypager.nicolashoening.de. The upgrade_db.sql file already accounts for that (and people should use this when they upgrade).
-nic-

All right, didn't know that. I am sure, most of your dear users will be good boys and girls and do as they are told and use the upgrade_db.sql. Now, shall we change priority to 5 or simply delete the whole bloody entry?
-j-

I just searched the "all bugs" for "fck" and got this result. Same for other keywords and combined keyword and author search. Searching just for an author finally got me where I wanted.

13.1.07
yep, I can confirm that. Happened to me, too :-(
-nic-

20.01.2007
fixed for 0.9.9

Yep, that's right. I just lost my whole "Aufgegabelt" section with feeds and all when I assigned two groups to the page in order to design the submenu for my new skin. Shit.
Earlier today all of a sudden another singlepage of mine was gone and I lost an hour's work. I thought it to be my mistake then, but now I think maybe PolyPager is hunting today.

25.01.2007
this behavior comes up always when singlepages are edited, it seems !
fixed for 0.9.9
-nic-

This should really be addressed once and for all: We should make sure everything is in utf-8.

• All the php-files are shown to be coded in ANSI. When I change the encoding to utf-8 in my editor, I get one or more "" at the top of my page (one for template.php, one for HTML_Framing.php...) -- in the source it is placed before the <xml...> stuff. Firefox will not accept the page as utf-8 (IE surprisingly does), but still treats it as ISO 8859-1. When I manually switch to utf-8 in FF (View-->Character Encoding), the "" is/are gone but some of the Umlaute and other special characters are displayed as black boxes with questionmarks.
  
  Going through my page again, I find that the black boxes with question marks are either my own fault (because I copied manually written html into the editor and forgot to &...; the Umlaute), or it is the title-field's fault. Apparently, when I write an ß in the title, it appears as ß in the source and not as &szlig;. same with &raquo;. For "»ßöÜ«羊" directly inserted into the title field I get  in utf-8 view-- so strangely enough, the number of question marks does not even coincide with the amount of characters?!
  -- same problem with all fields in multipages that are not BLOB.
  
• All my multipage tables in the sql database are still encoded in Latin Swedish -- at least that is what the table statistics ("Zeilenstatistik") is telling me. When I look at the fields directly, the "Kollation"-column is mostly blank and in a few rows it clearly states utf-8 and in none of the rows it says swedish. I tried to switch the other rows to utf-8 as well, but the database would not accept it and the field is still blank and the Zeilenstatistik still says Swedish, no matter what I do.
• When I changed the encoding of PolyPagerLib_HTMLFraming.php to utf-8 I could not log on to the admin area any more (I replace the path with dots):
  Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /.../.../.../PolyPagerLib_HTMLFraming.php:1) in /.../.../.../admin/auth.php57
  Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /.../.../.../.../PolyPagerLib_HTMLFraming.php:1) in /.../.../.../admin/auth.php on line 57 on line
• Firefox indeed does recognize and display all gallery pages as utf-8 (no "" here), so it is only public and admin stuff that somehow must still have the ISO-thing attached somewhere.

30.01.2007
I'll have a look when I'm home.

• The error messages say that sthg has been send before PHP send its headers.
  
  • What is sthg and why does a change in the encoding make it being sent before the php headers?
• What did you do to change the encoding in PolyPagerLib_HTMLFraming.php ?
  
  • I opened it in my editor and went to format in the menu. There ANSI was ticked. I ticked utf-8 instead, safed it and put the file on the server
• The encoding of your multipages is your thing and not Polypagers, I must say. Nobody understands why MySQL takes Swedish as default (we're not alone).
  
  • I did not want to complain about PolyPager not taking care for the correct encoding, I know it is my thing. I wanted to express that I feel like calling the Samaritans because I couldn't change it. I don't know much about databases yet, so would it be ok for you to write an faq of how to change the encoding in the database so that it will actually accept the changes? Cheers.

01.02.2007
Ok, the point is about the HTML-code that gets produced, not the PolyPager code itself. I changed all the encoding statements to utf-8 (they were iso-8859-1 before).
Please report how that works out for you when you get the new version :-)

2.2.07
That seems to have been the right screw to turn. FF & IE both swallow it as utf-8 now. Where are those statements?
Shall we fix it and have a new bug for the title - and other fields? Or leave this one open?

2.2.07
I fixed it. The statements are in all inex.php files (the declare the header for what PHP returns) and in lib/PolyPagerLib_HTMLFraming.php (there we also write it in the HTML head).
-nic-

When I use one of the comment anchors to see a comment (they are used in the RSS comment feed), the data-div scrolls to the comment (seen in IE7 and FF). That's bad - the page should scroll, not the div. Now you can't see anything above the comment.

Example URL: http://polypager.nicolashoening.de/?bugs&nr=268#comment95

click the screenshot:

In version rc2, the search doesn't work.
It's fixed for rc3.

implement recaptcha to protect comments of spam.

When I edit a field, it loses its name. I get as name options a list of the field names of the _sys_fields table, but not of the table I am editing a field for!

 

edit: seems fixed now ...

Safari was not considered in Mikes original script and I have not taken care of this. Now I have. I even made browser detection more lioke 2007 and less like 1996.

When I change the language from en to de in a new installation, PP includes two different scripts (for en before it apllies the change and for de afterwards) with the same method which leads to an error.

After that, everything works fine, but the error while applying the change shouldn't happen.

 

On Installation, when there are no pages yet, the user receives a warning about this. This is nice, but

1. In the admin area, the warning shows a link that leads to admin/admin/... Thats no good
2. The warning disables all further output, so if the user is in the admin area to finally create a page, he can't
3. When you click on 'pages' in the admin area, you see the content section, not the page section. That is bad and strange!

I told polly my start page and I can see it under "the system". Also, when I go to the root directory, the correct page shows up. Nevertheless I get to see

Es ist keine Startseite angegeben, Wenn Sie Administrator dieser Website sind, können Sie das in den Systemeinstellungen nachholen.

The link also has admin/admin

 

When I change the name of an existing page, the content is no longer connected. When I change the page name back to the original one, it is visible again -- I reckon it still is in the table but poor polly can't find it.

nobody wants an empty form after deletion of an entry 

A very nice feature is that Polypager 1.0rc5 is able to fill in m:n tables (m and n are foreign key fields that link two other tables together).

It assumes the table related to m as responsible, so when you edit an entry of it, you get possible values that you can click in or out. This affects the entries in the m:n table, not the original one. And at this point you also only see what is connected when you see the entries in the m-related table.

With this feature, complex data models can be worked on and represented with Polypager :-) 

 

P.S. (you need InnoDB tables for Foreign Keys in MySQL)

Reproduction: in rc5 go to »content«, pick a page with more than one entry in it, delete one by clicking on the red X next to it. The page reloads and I still see the page in question selected in the dropdown-page-selector. I also see »No fitting entry in the database was found...« instead of a list of the remaining entries.

When I select the page in question again from the dropdown selector, nothing happens. I first have to select another page and then the page with the deleted entry again in order to see the remaining entries.

Title says it all.

After upgrading to PP1.0rc5 most of my special characters are fucked up. I don't know how it happened, maybe I shouldn't have exported my database beforehand, but then maybe exporting the database should be possible, too.

I don't know if it is a Problem we can address or if it has to do with the Swedes.

I don't know how to reproduce it, either, and I honestly don't want to know.

Affected characters include everything from &ndash; over Umlaute to Greek and Chinese Characters and they either sit in entry titles, page titles, feed titles, varchar fields (unicode) of multipages or in comment text fields, but they are not affected in blobs.

Trying to edit my comment here, I saw

DB-Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\">here for example.' at line 1

 

For some kinds of table names, queries will fail if the table name is not secured like this: `my-table`.

The above example fails because of the hyphen. From the MySQL spec:

The set of alphanumeric characters from the current character set, “_”, and “$” are not special. Reserved words are listed at Section 8.3, “Reserved Words”.

Some unprotected cases should be in the DB library...

On deletion of simple- and multipages (locally) I see

Warning: mysqli_stmt::bind_param() [function.mysqli-stmt-bind-param]: Number of variables doesn't match number of parameters in prepared statement in /opt/lampp/htdocs/bu-schubert-sys/plugins/codesense_mysqli.php on line 46
Bind parameters failed

Still, the page gets deleted alright.

 

These boxes for the main menu appear in IE and Opera someplace wrong and make the horizontal srollbar dizzy (the "there is no entry..." - text also appears in that wrong place) 29.09.05 - that sure took some time... display:inline was important and a lot of cross-browser javascript

check results from the db that contain the keyword if the keywords only appear in the Markup (like in link-hrefs).
If not, display chunks of the entry without markup that contain the keyword(s)

02.02.2007
on the ramp

13.02.2007
fixed for 10.rc1
We now show only parts of the entries that contain the search words. they get stripped off markup beforehand.

13.2.07
Does that mean
a) only a fraction of the link is being displayed
b) the link does not work any more?

Because if a + b we could simply ignore terms in markup. Would it not be possible to do as  I understood (because I am not quite sure if that is what you meant), so a + b plus
c) Display a link after the broken link that reconstructs the original uri and has a hover saying: "This is the original Link, as the search term occured in a link bla bla bla.

That's basic UI design. think a minute what other controls should be considered.

03.12.2005  - fixed, only for delete-button. Even GMail doesn't ask if you want to save when you close the page...

Comments should be possible, but it should not be too hard to implement.

Somehow use available code...

23.12.2005 - made it "in progress"

12.01.2005

Todo (wrong order):

• call methods from index.php
• they -list comments, - write a form to make a new one (how to import few things? Maybe import_once?)
• table structure: id, tablename, tableid, name, email, www, bla
• can we /do we want to comment singlepages that way, too?
• make an entry in getEntity and create Systables

30.01.2006
good amount done - only finetuning needed (doesn't work yet for singlepages, but I suppose that would be cool to make up a guestbook quickly)

22.02.2006
still to do:

1. should singlepages be commentable or not? maybe give it a try...
   
2. implement behavior for "show_comments" option
3. strip all tags from input but allowed ones. if stripped comment is unequal to unstripped, maybe we should do nothing to the DB but give a feedback and refill the form fields (ugh)? Maybe not if its too much work now...

03.02.2006
singlepages are commentable now, there is still one issue:
"the chosen number was too high - showing newest" appears at the top. something with $params[max] - should be easy...
2 and 3 are still open.
Maybe we could make up validation - regexes for email-adresses and webpages (or find those in the net: http://www.regular-expressions.info/email.html, not this one: http://internet.ls-la.net/folklore/url-regexpr.html - what about this:

((ht|f)tp[s]?://[^[:blank:]]+)

) 16.05.2006 - finally fixed

for future ease of style development, style.css should be made into several files, where

1. one is a map, locating and sizing everything. Using only that as stylesheet, nothing in position should change
2. another is the style ("skin"): colors, shapes, special formatting etc
3. all the rest will be in a stylesheet that includes standard formatting, to be used by all styles

That way maps and styles can be recombined. For the new style, I'd reuse the map of this first one.

20.12.2005 - conventions:

• all font attributes go to skins, besides font-size which seems to alter the box position.

• all border attributes go to skins, besides border-width (because IE takes border-width as extra)

• margin and padding go to maps

done with the separation - result is pretty good... no file for the third class of cs stuff yet - needs some  consideration...

22.12.2005
Maybe a good way to deal with maps/skins is this:
a map defines the basic location of everything. A skin defines how things have to look AND overwrites A FEW special location features of the map with "!important"

29.12.2005
decided to put all border things into the skin. It's no good working with them separated, believe me.

22.01.2006 - done

there has to be a title somewhere. i just don't know where yet...

maybe make the title bar a little bigger

07.12.2005  - I made a quick title bar on top. could be better designed... fixed.

it says: "Query was empty"

02.03.2006
is fixed.

Maybe a good idea to make administration easy in some future version.

All that remains to be administrated in terms of the database is which table you want to see.

The Administration Wizard would only care about the stuff that is not in the db and just show what it finds in the db.

The main places where that would happen is showEntry() and writeHTMLForm().

They would use another function that gets the metadata for them...

 

03.01.2006 - and that other function, of course, is getEntity()

I make this one "in progress" because I hate giving all that information twice...

ok, I'm getting all info I need from the db!

There needs to be smart thinking how we represent meta information about fields (what field is the publish field, the date field and so on in a later user interface), but till now this bug is closed.

a new simple skin, mostly white should be done (I might use it for describing PolyPager).
The content could be bordered with pictures I stole recently.

24.02.2007
finally on the ramp...

28.03.2007
mostly (and beautifully) ready, maybe some work on menu and comments left, but that can be done later :-)

• find a way to lighten up a color (maybe just adding white... or use contentfill.gif?) and use those for background of the data-section - we need friendlyer colors!
  
• make some cool bg-gifs for the data-div, transparent, with little gadgets on the side.
• make a better wallpaper for uptight-colorset: maybe just white with little patterns in each color
• make a better wallpaper for fall-colorset: a gradient somehow...
• make skin import map /@import url("map.css");

20.01.2006
done - I used a lot whiter background for text, a nice headerpic and even made another colorset (saarpreme). instead of wallpapers I made a shadow-jpg for the container pane. uptight colorset lokks a little different. Maybe I don't like some of the contrast colors - we'll see.

some things still suck in picswap-skin on IE. I should go over some little things:

1. the heading is partly cut
2. on laptops with 800x600 resolution, the whole skin is too wide
3. ...

21.05.2006 - I fixed that second problem and at the monent I don't care about the first

The FAQ will basically be the documentation (besides the little question marks within the page). This would go on the PolyPager Website:

1. How can I make a guestbook?
2. How can I make picswap use my own pics?
3. How can the user search for content of a certain field?
4. Why are thumbnails in the gallery not generated? - This is an issue of minimal gallery. I found out that it seems to happen to pictures that are really large- at least for web publishing (like 4260 x 2412 pixels). So make them smaller - it worked for me...
5. some folders in the gallery do not show up? - Again, this is an issue of minimal gallery. There is, however, a reason I know for not showing a folder - it its empty. maybe yours is?

20.05.2006 - done
there is still a lot missing, but the beginning has been made

for multipages that are likely to be used by many people, I could provide a one-click solution that just entails some CREATE and INSERT statements.
Suggestions:
-a blog
-an FAQ
-a guestbook
-an about-page
-...

the hardest question is where to put that option within the admin area

20.05.2006 - implemented the first three of them

the problem is that they have no date field, but that could be added.
Then we need another option in _sys_singlepages and consider the feeding code...

30.04.2006 - "in progress" for 0.9.1.

01.05.2006 - fixed

to make it easier to fill this list
make an $entity option for fields: "fill_from_this_list"
if set to 1, there will be a link list under the input field with possible values as text. When hit, a link calls the (to be written) js function "moveContent(target,source)".
It appends ", " + source.innerHTML to target and makes source invisible.

19.07.2006
is now "in progress" - needed if tagging comes into play on day :)

19.09.2006
done

If one submenu gets klicked and another has been before, the old one doesn't disappear anymore

27.04.2006 - fixed

this should not be too simple. You can save a click for the user that way, but he/she can no more "surf" in the submenus without reloading...

27.04.2006 - fixed

we could give sections a group field. In addition, the singlepage-table gets a grouplist - field, where groups can be listed (in just the form we would need for the valuelist of that field :-) - but beware: the user might use whitespace, so we should strip that: explode, strip, implode again).
The user now has more power to group sections on his singlepage.

27.04.2006 - fixed

first, it should not be used in the admin area
second, if there are only, say, 5 entries, how do I know that there are more and how do I get to them, if not by initiating a search?

15.07.2006
the first was easy - the second is solved by a system message under the entries when step is != "all", containing a link that does use "all"

there is no need to use those terms when not in the program code.
the only place you see those is in the admin area under "pages". Just show all of them in the list, always.
And make a little help under the "new..." - links what the difference is about.

17.05.2006 - fixed

I made that for the pages - admin menue (the template message). but most of the time, it's not suitable

10.07.06 - fixed. had to give that one an extra id. dirty somehow, but not hurting anyone

Well, the title is descriptive I guess...

10.07.06
couldn't reproduce that - seems to be fixed by some other bug :-)

that's just a good idea. When I created a page, that is most likely the first thing i wanna do.
P.S.: the link "new entry" might be misleading here. I know that was more explicit someday. That was better...

13.07.2006
done

doesn't seem to work right now - see blog

16.07.2006
there was a problem with the oswald-function (javascript), the SQL statement didn'T fit the _sys_comments-table anymore (we threw away the time-field) and most important: the field 'commentable' in _sys_multipages was written with three m !!!

Oha... seems to work now.

the admin should have access to those things. good would be a list in the admin area.

16.07.2006
I made use of the capabilities the admin list area has. There are two links in the "content" area that help with listing those things.
the info about comments is not very useful, but you see the text as title.
(you can access the comments direcetly from the entry)

todo:

1. _sys_feed needs a primary key...
2. _sys_comments have comment as title_field but thats not good when not in list_view...

17.07.2006
done.

... especially since the labels have meaningful translations.
simple idea is: let the editor always go over the whole width of the table. then, what do to do with the label? write it on top in another tr...

fixed.

That is also an afford to reach XHTML validity. I think the variable content just needs to be replaced with html_entites($content) in the beginning of the method writeEntry, but I'm not sure if that would cause any trouble.
Should be easy to check...

09.08.2006
done.

I inserted a lot of latin character enitities there (mere inclusion of the external DTD didn't work...)

it should be possible to subscribe to certain channels when using RSS.
That means: the user can decide not to subscribe to all content of the website, but select certain channels.

A channel might be:
-a page
-a category (represented by tags - tagging is not yet implemented)

An excample URL (the one I need this feature for) would be:
rss.php?p=dublin to see only what happens on the "dublin" - page
you could select more pages by giving a list:
rss.php?p=blog,about

"p" is for pages, "c" will then be for categories (someday) - We'd also need a  place to  stick something like that together.

That could be done with a backdoor implementation maybe (if the directory is there, give those 4 possibilites - call skin.php with param so it can set)

20.10.2006 - done

This has to be clear.
At least we'd need an FAQ entry.
Maybe there's a good point in the code to generate a warning...

04.01.07
list of datatypes is in the FAQ.
Rather than checking if the type is supported, I should support all types. There are not much left actually, just special types like medium int, text and the like. That would be  great...

18.01.2007
ok, I think I'm pretty much done for 0.9.9 with that.

The foreign key support has always been rather weak for MySQL.
This tells more: http://www.databasejournal.com/features/mysql/article.php/2248101
They are only supported for one type of table (InnoDB) which is not the default type (which would be MyIsam).
I can make all the PolyPager tables InnoDB, but not enforce that on everyone using a MySQL table with PolyPager.

Anyway, I think that we could have FK relations.
Consider the field-information form the user can use:
For a field of table A he can state that it contains values of the Primary Key column of a table B (we could give him a list of tables to choose from). This (relating the Primary Key only) covers almost all foreign key use cases .
This would imply the following:
-when he edits an entry of table A in the form, the values for the FK field would be filled from a combo box containing title field entries from table B. Adding or updating an entry to table A that would violate the FK relation should therefore be impossible with PolyPager.
-deleting an entry of table B would lead to the message that it's not possible if Polypager finds dependencies.

It would be nice if Foreign Keys (on InnoDB tables) on the database could automatically be recognized.

We would of course need an FAQ entry explaining this (could take text from here)

06.12.2006
I added support for them. The fields with which _sys_fields can connect singlepages in a foreign-key-like manner are hidden for the documentation isn't very good yet.
The code can:
-support dropdown-menus with the title, when a foreign key field is filled in a form
-display the related field rather than the referencing field on the pages
-make smart table of contents with one more sublevel when data of a referenced page is shown

The help-popups sometimes are too low when they contain several lines of text, so that you can't read all of it.
I reviewed the javascript algorithm that computes if that might happen and corrects the position of the popup upwards. Now it estimates the height by counting the chars and assuming a certain width for a char and a certain height for a line.
That's much more sophisticated than the algorithm before that (it just checked if the bottom was 135 pixels away :-) )

Tables that are cerated during the template creation process depend on the page name. That page name may contains signs that are not usable for SQL tables.
Find out what is usable and write a function to ensure compatibility.

Done for 0.9.7

on some places, an unknown page wasn't recognized and the error messages were not very informative.
Done for 0.9.7

ok, supported
yet missing: validation

done - now the table that is referenced twice gets two different aliases in the SELECT query

guess title field if not set (e.g. for admin list)
1st choice varchar fields, then first words from blobs or the like.

27.01.2007
fixed for 0.9.9

There are some problems, for example: those fields need to be shown, too.
This is the first time I test them extensively.

done for 0.9.8

they get utf-8, too
done for 0.9.8

see sitemaps.org

Googles standard has recently become the overall standard, so PolyPager should  do such a sitemap, too.

issues:

1. XML-File or PHP->XML? There could be a lot of robots, so maybe XML is better
2. What gets into it? Extra-option ("archive") or take the feeded ones? Or simply all entries?
3. How to set change status? (can be daily/weekly/mothly/yearly/never) Maybe according to the last change of the entry...
4. set the priority field? After which criterion? Simple: An entry on the start page is important, the others equally average important.

01.02.2007
Ok, due to time issues, I made a really simple sitemap.php.
It takes all entries (it's ok, to have many as long as it's < 50,000), displays the date when there is one.
The change frequency is set to weekly. Should that be made optional somehow?
The priority is 0.5 normally, 1.0 for the entries on the start page and 0.7 for all entries that have a publish-field and are set to "publish" (that's because there has been an explicit user choice to make this public ... unpublished entries will not appear on the sitemap).

PHP 5.2 has a problem with strstr() if the haystack is empty.
Can lead to a lot of uncomfortable warnings.
In PolyPager, most of the occurences only check if a search string fits. That can easily be replaced with eregi().

done for 0.9.8

PolyPager will save up to 50 feed entries.
When the 51st is entered, the oldest should get deleted.
Unfortunately, the newest go deleted.
Fixed for 0.9.8

done for 0.9.8

The SQL query selects not only fields from the table in question, but also the title fields from referenced tables (to show that instead of the reference which is most likely an ugly number).
If the refence IS NULL, then we get nothing at all because the query doesn't select anything anymore. Here is an example of the solution approach (the real solution will not use the * wildcard):

[actors is the table in question and it references stages]

SELECT actors . * , (
  SELECT name
  FROM stages
  WHERE id = actors.stageid
  ) AS stageid
FROM actors, stages
WHERE actors.stageid = stages.id
      OR actors.stageid IS NULL
GROUP BY ACTORS.NAME

MySQL can use subselects since version 4.1. I made a remark in the FAQ...

08.01.2007
seems to be done

1. it should be possible to search on all pages at once by requesting a special page ("_search")
2. the search should work per GET-requests, so that HTML-links to searches are possible
3. it should be possible to search for several keywords at once (per implicit AND operator)

done for 0.9.8

since bug 214 is implemented (better search), it is now possible to offer a search box for sitewide search in the HTML templates.
Per default it only has a keyword box and a little help icon.
If you provide keywords to the function that writes the search box, those keywords will be used to build links to search for that keyword on the site.

example:
function writeSeachBox(indent=3,keywords='cars,women,cars women')

Maybe there is a nice way to make it an option to use the HTML Head Keywords for this? They don't get used by search engines very much these days...

25.01.2007
done for 0.9.9., including using the metadata keywords, but that's on behalf of the skin template...
neat!

All my efforts in this direction have been half-way.
Despite all the different players involved (editor, php functions, mysql, http, browsers, ...), there is at least a best practice used by experts. It's all about using UTF-8.

This is a list of resources I found helpful:

• http://www.phpwact.org/php/i18n/charsets
• storing-bangla-unicode-text-in-mysql-database
• http://babylon.idlevice.co.uk/phplondon/2005-05/

As I understood, here are the steps that need to be done for the PolyPager environment (some of which I already do, but it's important to do all of them):

1. set the header within PHP:

   header('Content-Type: text/html; charset=utf-8');

2. also, to be sure, write it in the HTML:

   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

3. tell HTML forms what kind of data they get:

   <form accept-charset="utf-8">

4. checking the PHP code to handle UTF-8 correctly (no, it doesn't until PHP 6 or so...) Here is a utf8.php file with some functions that should be used (for example a function to replace strlen() or strpos() with - excellent!)
   
5. check if we can tell the FCKeditor to use UTF-8. Otherwise, we might use utf8-encode to check posted data.
6. use htmlentities() when outputting?
7. get rid of invalid characters
   
8. check that MySQL encodes properly: First make sure all tables use "utf-8" (I avoided this to support MySQL 3, but that is no excuse).  Add to the CREATE - Query (NOTE: Since we don't create the database, we should tell the user to do this, maybe generate a warning):
   

    DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

9. Make sure PHP talks UTF-8 to MySQL: add these two lines just after selecting the database, i.e mysql_select_db() function (from here and here):
   

   mysql_query(’SET CHARACTER SET utf8′);
   mysql_query(”SET SESSION collation_connection =’utf8_general_ci’”);
   mysql_query(”SET NAMES 'utf8';")

10. Maybe insert only converted characters into tables, like this:

    INSERT INTO utf8table (utf8column) 
    SELECT CONVERT(latin1field USING utf8)
    FROM latin1table; 
    

11. If we settle on UTF-8 )and all the experts agree we should), then the encoding - option must go.

When it comes to testing all this, we should have some strings to help us:
사설 번역/음성사설 번역/음성
Iñtërnâtiônàlizætiøn
Here are lots more.

And a list of actions that suffice to test functionality:

1. enter this text in FCKeditor: a page entry and a comment!
   
2. enter this as pagenames (maybe we can finally do this by using one of the functions -utf8_tohtml()- in utf8.php)
3. test if the RSS feed with weird characters works

All this is a (maybe overly exact) list of what needs to be done for future use of Polypager.
It doesn't yet cover converting old data, but since there's not too much of it, that's maybe not such a big problem.
Anyway, this wordpress bug shows that even Wordpress is still struggling with this and also how to convert data savely to UTF-8.

20.04.2007
done for 1.0rc2
I left out 6) and 7), but tests were fine.

This is the GET URL to search for bugs solved in version 0.9.8:
http://polypager.nicolashoening.de/?bugs&cmd=_search&_search_version=0.9.8
Now that we made GET requests possible, the URL should be simpler and shorter, like
http://polypager.nicolashoening.de/?bugs&cmd=_search&version=0.9.8

Also, the form produces more parameters. Throw them out.

25.01.2007
fixed (made a lot better at least) for 0.9.9
Without "_search_", we now have the risk that the user has fields in his table that are called like our search terms ("kw", "m", "y")!
-nic-

The FCK editor is flickering once I surpassed a certain length of an entry because it continuously tries to keep the size of the editor window as large as the entry. The result is not only that the cursor position often disappears into submarine realms, but (for my site) the horizontal position changes, too.
After the entry gets longer than x, the flickering stops and the size of the editor is fixed.
Make it fixed at all times.

Not sure about priority, I was hoping to see this fixed in 0.9.8. I'll set it to 2, even though for me personally it is 1+.

09.01.2007
In the file fckconfig.php in the directory "plugins":

FCKConfig.Plugins.Add( 'autogrow' ) ;
//FCKConfig.AutoGrowMax = 700 ;    //this leads to flickering

I found the best result by commenting the second of those lines out, like above. The editor still grows, but stops to flicker.
Can you confirm? You maybe need to restart the browser or empty the cache (I didn't).

If you confirm this as cool, please fix it (for 0.9.9 of course).
-nic-

Confirmed as cool. Fixed it at home, but how shall I fix it for 0.9.9? YOU fix it! -- by they way: you did not yet change it here, did you? Cause PP is still flickering like there was no freaking tomorrow.
-j- 12.1.06

Yes, I fixed it in the code and was waiting if it works for you when you try it at home. I meant, fix the bug, i.e. set the status of this bug to "fixed" and the version to "0.9.9".
Did it.

Until version 6.x IE still went to the css-Kindergarten. Now it seems that it all changed with version 7.x. So: is it safe to modify the IE detour? Should be something like

<!--[if ste IE 6]>
<link href="./style/skins/picswap/iefix.css" 
rel="stylesheet" type="text/css"/>
<![endif]-->

09.01.2007

Hm, I don't have an IE7. Please help me out by looking at the results it produces without iefix.css.

BTW, Google said:

Did you mean: "if gte IE 6" 

Ah, you mean "smaller than or equal", right?

"if lte IE 6" stands for "less than or equal".

I'll include that in 0.9.9

 

I changed it to

<!--[if lte IE 6]>
<link href="./style/skins/picswap/iefix.css" 
rel="stylesheet" type="text/css"/>
<![endif]-->

(cause indeed that was what I meant) for the Brasserie and put the li-menu-margin-bottom to -16 px again. Last time I did that IE 6 looked ok but IE 7 displayed the list items on top of each other. Next time I get to the library, I'll check IE 7 again. If it works, well, what then? Consider it mature or conduct further research?

-j- 12.1.07

 

I'd say if it looks ok in IE7, we close the bug and give it a fair chance. If there need to be adjudgements, we'll open a new bug.

Here is a link to CSS-things that have been fixed (hooray position fixed!)

-nic- 13.1.07

 

18.1.07

Brasserie (menu li margin, min-height, float) looking good in IE 7.

You should change it to

<!--[if lte IE 6]>

for PP and nicolashoening as soon as possible as your menu is not only looking pretty shity in IE 7 when hovering but is also very hard (impossible) to use.
-j-

We talked about that. Sometimes you want to store images you use in the content of another page, so you don't want to have them as a directory in the gallery. Qdig gives the option to exclude folders in (or around) line 539 ("Etcetera):

$excl_dirs[] = 'private';         // Ignore a directory with its name

So we should have by default a subfolder in the Image folder with a colourful name (yet not too colourful as we still want to link to that folder). I suggest something like "private" (I believe that was default) or "excluded_images" and tell people about it somewhere. Maybe in faq (I'll write one as soon as we agreed on the name of the dir).

16.01.2007
let's use "private". I added the directory for .0.9.9.

16.1.07
Don't know if case matters. If it does the directory should either be called Private or the index.php should be changed to lower case.
-j-

When you choose to display the latest entries on gallery pages as well, all links are broken.

Suggestion: Write absolute urls into feed rather than relative.

 

20.01.2007

not so fast. I don't know which domain I'm hosting. Relative is better.
Replace line 123 in PolyPagerLib_Sidepane.php with

global $path_to_root_dir;
echo($indent.'        <a '.$text.'href="./'.$path_to_root_dir.'/?'.$row['thePage'].'&amp;nr='.$row['theID'].'">');

fixed for 0.9.9
-nic-

You are absolutely right about the domain. Where did I have my head?
Fix confirmed.
-j-

The Error reads: "A database-error ocurred... Column 'tablename' specified twice".
I also see ."\n"
Happens at Brasserie and PolyPager, so I guess it is not a local problem -- hence priority 1?

25.01.2007
happened when creating intros.
fixed for 0.9.9 (also removed the "\n")
-nic-

The time on my blog pages is being displayed different from the time being displayed in the rss. The time in the rss is correct, the time on the page is strange.

05.02.07
Excuse me, but what does "strange" mean? The format? The time itself?
I think you mean the latter, but keep in mind that the blog will show the input date and the RSS will show the last editing date on which "publish" was marked when hitting submit. Still weird?

05.02.07
No excuses, they are strange.

1. I just wrote a new entry.
   System time on my machine (GMT): 15:18:xx.
   Estimated system time on server (GMT+1): 16:18:xx
   Time stated in feed: 15:15
   Time stated in Blog: 04:02:59
2. Would the feed get a last edited date if I don't feed modifications? That would mean, if I fixed a spelling mistake in an entry from last year, and don't feed the modifications, the rss would still display it as the latest entry because of "publish"? Then, I have to say, there would be something rotten in the state of Denmark.
   
3. Format: Me disliking the format DD.MM.YYYY - HH:MM:SS is one thing (I would prefer DD. MMM YYYY - HH:MM), but I think the time should at least be in 24-hour format (or if by all means it shall be 12-hour, it should at least state am or pm)

I can only say that on my computer everything is fine. An entry made at 2 after 5 is displayed with this time in both the blog and RSS. Maybe your server is fooling around?
I think your format suggestion is better indeed - changed it.

Well, I don't know what it is. I just created a blog on PP and input time is 7:02 pm. It is 6:35 GMT here.
Somebody deleted the Blog.
I recreated the Blog, made a new entry at 6:40 pm GMT and the entry time still states 7:02 pm. Feed says 18:37.
If my server is funny indeed, how come the feed gets the correct time? Do they not get it from the same source (I mean feed and Blog)?

06.02.07
Ok, I got'im. The format string that describes how to display the date (in PolyPagerLib_Utils.php - format_date() ) was displaying the month instead of the minutes!
"m" means numerical month, "i" means minutes...
Format is fixed in 0.9.9, Minute formatting in 1.0rc1 (rc=release candidate, we might have some of those)

• Would it be possible in admin -> content -> comments, to group comments on first level by page and on second level by entry title? maybe a dropdown with all the pages actually containing comments would be neat. Not really an issue if there are five to ten comments, but there might be more over time or when you have really popular sites (unlike ours...)
• When I tried to post as comment (here)
  But how did you manage to "translate" a space to a "+" instead of "%20"?
  I receive
  There is no entry in the database meeting the search criteria...
• What would you think of a javascript thing similar to toc for "add a comment"? I think it looks ugly if you have the commentfield ready all the time.
• Maybe the "www" in front of the uri shoukd read "uri". Would look a bit silly if someone less correct just states their address without the leading http:
  www www.blaa.de
  Could stay "www" for the entry for, though, as I believe that not all of them commenters out there know "uri"
  

I like the suolution of telling people that there is more to readnow. However, there are two issues.

Issue 1 is small: Could you give "click" a capital C, as it comes after a full stop?

Issue 2 is this: The "there's more then what you see" message is tagged <div class="sys_msg">, so it is the same as the sys messages you get in the admin area. I would rather like a solution similar to the data and data_admin (so sys_msg and sys_msg_admin), so you can actually have two different sys_msg styles, one for public, one for admin. If somebody wants them the same, one could still achieve that pretty easily .

In the course of writing a new entry I wanted to safe it, but without yet publishing it. The title was published in the latest entries nonetheless. When I clicked on the link, I did not see the entry, though. I think the feed entry should be written when the entry is published for the first time.

31.03.07
Technically, you ordered PP to make that feed entry (the form says "feed now" and you left that checkbox checked).

You're right in the point that it's not making much sense to have that checkbox checked when "the publish" checkbox is not checked. That holds for the whole lifetime of an entry, not only when it's published for the first time.
Maybe I could
-build a Javascript dialog that tells the user about this problem?
-make it impossible to  feed when it's not published?
-if a publish-field is there, add to the help text sthg like "This feed will only be made when the field is published"

I favor the third option, because generally, I found that feeds do not change with the published state. I need to change that. When an entry gets "unpublished", all its feeds must be hidden, too. The same, in reverse, when they get published.

31.03.07
fixed for 1.0rc2

As of rc2, my Crème in the menu was a Cr&egrave;me. Comments were not possible ("There is no known page specified"), so I finally changed it to Creme. But alas! all the feeds still had Cr&egrave;me, so I had to change them all manually again.

I guess there must still be something wrong with real internationalisation. Sorry. 

May have sthg to do with the [updated] in front of their title...

Think for 5 minutes what would be the smartest solution.

fixed.

When adding a link, FCK now by default adds target="undefined" to the anchor tag. That results in the link opening in a new window. It shouldn't be like that.

Don't know if we have control over it (same here) or if we just have to take FCK as it comes.

 

19.7.07: Screenshot for temp fix (see second comment below):

 

Display a link under each entry (in the options) that tracks all comments for this entry via RSS. This requires a little more intelligence in rss.php and the link creation, nothing more. Some users might find this very useful, for instance if they commented and are waiting for a response.

It might be good to revisit the FAQ about RSS feeding.

Done.

This resulted from a bet with Jan that I could do this in 1 hour.

Turned out, it took longer, but I am so glad I did this. No Javascript in the menus is a great step towards usability.

 

(Most of the work was to adjust all the skins) 

Since now some pages maybe only allowed for admins, rss.ph needs to be smarter in what it allows to deliver and what not, depending if the user is authorized.

That may result in some feeds only being usable in RSS readers that allow authentication (for instance Google Reader can't do this). Maybe there is a way to graciously fall back to only deliver what is allowed (maybe add a notification that some parts are missing as a comment).

should be possible, was at some time possible.

For instance search for keyword and priority in bugs on PolyPager... 

When the MySQL table field is UTF8 collated, then the maxsize for the field is too small, thus the Form input field is too small.

When gathering the meta information from the database, PolyPager uses information_schema.COLUMNS. From there, it sees:

[Type] => varchar(100)
[CHARACTER_MAXIMUM_LENGTH] => 33

We use Character_Maximum_Length (not all types carry a length with them!). It seems to grow with the varchar size. Via myphpadmin, I can insert more values than 33, so this value is misleading. 

 

Google javascripts (e.g. the one for Google Reader, but also others) check a variable called "opera" for being "undefined". It's a variable that the Opera browser uses.

If one of PolyPagers scripts initializes a variable with that name, Googles check will come out with something else than "undefined". Then, Googles script will happily use my variable, assuming it's running on Opera, thus Googles script will crash.

In some cases, there might be no suitable title-field, so the id should be it and then needs to be shown.

At the moment the fields are displayed in an order that doesn't reflect the order specified by the  user. The latter would make good sense, I think.

In the search options I have an option to search for 1→1 related stuff.

However, it doesn't work. I have a drop down, but the entries are broken. I can't take a screenshot of an open list, here is the source code:

<option>|2:Meitner</option>
<option> Liesel|</option>
<option>|1:Müller</option>
<option> Paul|</option>

But it should be

<option>Meitner, Liesel</option>
<option>Müller, Paul</option>

Another instance is an ID. This one doesn't get cut at the blank space but still doesn't work and comes with ":" and "|"

<option>|1:1|</option>
<option>|2:2|</option>

  And it doesn't yield a result either.

 

 

26.09.05 I found the useful function addslashes

in editing

18.11.2005 - made the menu come before h1 and float:right

22.11.2005 - still not working for everything

I want to redefine searching. this section, bugs, is a good(test) case for that.

1. I need more search options (where grouping just isn't enough). Think of bug status and topic.
2. All different search options should go together if the user wants to combine them. Show a checkbox for every action (tweak: make it inaccessible and activate it by Javascript when a search form field gets focus)
3. I would maybe like a link that offers to save that search URL as bookmark or tells you what you were searching for at least
   
4. show search on top, hide/show it with Rico java script
5. in the range search some pages have the option 'all' as maxnr...
   

22.11.2005 - first two points working (still shitty looks in IE), third point difficult, because we have POST data. I would have to reconstruct the link with GET params so it can then be saved.

02.12.2005 - looks ok now in IE (was another bug) - I added point 5. point 4 is not a must...

 

07.12.2005  - worked on Nr. 5. Excluded range search for now, rather worked on the previous/next links. That needs a little work still. Has a lot to do with the step param...

19.12.2005 - decreased priority, only nr 3 and 4 are open

 

19.01.2006 - nr 4 is done, too. and there is one more thing: when you select no option and search - you get an error. maybe java script could warn you or the error should not happen...

22.02.2006 - that error is fixed.

 

14.04.2006

one more thing: when I search for bugs with topic: style and status: new I get some results, but there are not style bugs?

27.04.2006 - fixed

An automatic gallery with thumbnailing and everything.

I just wanna give a directory on the server with pictures and that's it.

 

05.12.2005 - I found these on freshmeat.net:

• http://minimalgallery.net/home
• http://spgm.sourceforge.net/
• http://tftgallery.sourceforge.net/
  

Of which I think the first one is my first try...

The server needs GD (for thumbnailing), which mine has.

TFT sounds good, too, but it needs Sessions...

is uploading multiple files a requested feature?

 

17.12.2005

made it "in progress". a little ba(t|sh) file to upload a folder wouldn't be bad,

but everyone can have his/her own FTP program...

 

03.01.2006

tried it out on www.accb.de:

• the main folder can have an name
• the preferences should be sitched to show "thumb" as default
• we need a chmod on the thumb-dir
• we don't need the home-dir or the php_info.php - file
• the webadmin-script could then hide the _mg - dir and the idex-file. That's all which is to do.

12.01.2005
mostly implemented - some design issues remain. And it might be cool to integrate the gallery into the data div with an own template (they are really easy - just take the basic one)

20.01.2006
done - now integrates with the page - had to alter the basic css as well as index.php

22.01.2006
mmmh... it's a pity that subdirs are not supported - maybe qdig.sourceforge.net is worth a check. it also can do captions.
spgm doesn't generate thumbnails, take a look at this: http://php.soundboss.cz/index.php?lang=en&co=phpfa1

It should be no big problem to add this plugin

to handle a file directory where the user can upload or delete

files of all kinds.

A good place would be the Admin Index.

 

14.04.2006

long since done with webadmin.php

in all bat/bash scripts currently the path to Java is hardwired!

17.12.2005 done within installation requirements
JAVA_HOME needs to be set...

you heard me.
fix those warnings. Should not be too much, mostly stuff in the HTML head.

21.05.2006 - Yes, there is some more.
All the &s in URLs need to be &amp;

I did some of those, but there are maybe more, and different errors...

22.06.2006 - for instance, quotation marks in headers lead to errors when they appear in links - maybe text that did not come from FCKeditor but inputs, type text, needs to be escaped...

13.07.2006 - I think I took care for that one. in several places, that is... I am curious how good we are on the next validation test :-)

21.11.2006 - I made a validation for the whole bugs - page (with version 0.9.6 running).
There are some errors that are due to the strict doctype which will be changed to transitional in version 0.9.7.
Then, 2 or 3 come from wrong markup that FCKeditor supplied (mostly it has to do with <ol>-ordered lists.
The majority boils down to one problem: Not allowed characters in id-attributes. Those are messages like this:
-character "!" is not allowed in the value of attribute "id"
There are many not-allowed characters, so I have to see if there is a simple way around (some method that makes a string id-attribute compliant would be the solution).
This page says:

The short answer is that the first character 
must be a letter, and any other characters 
may be a letter, a digit, ".", or "-".

Since the ids are not visible to anyone, the method could just use regular expressions to specify what is allowed and replace every other char by some default or nothing. The method could do this charwise, in a loop.

27.11.2006

done. I'll wait for 0.9.7 to see the new validator results (since the FCK editor  introduces some validation errors there is no hope for complete healing anyway)...

18.12.2006

there is now an error with the empty ul-tags of the Foreign-Key lists in the toc. But we're moving here :-)

03.02.2007

that is resolved.

Still testing with the whole bugs page (several thousand lines) against the W3C validator, I get some errors from the head - the rest is from content and due to FCK-editor.

So, this seems to be almost fixed (as far as I can, that is, but that is far enough).

 

5.2.07
Checking my site gave me 6 errors on each page -- all in the head. For me there does not seem to be a problem with the FCK-Editor.
Only problem: On one page I use the same title twice with a different subtitle. PP writes IDs like this:

<a class="target" id="pp-BLABLABLA"></a>

so I get the same ID twice on my page -- and the validator does not approve of that.

∼ jøn ∼

 

24.03.2007

I was just testing the whole bugs page with 1.0rc1 and I got 18 errors for a page with over 11,000 lines. Of those 18 errors, about 8 were just describing the same errors double. From the leftovers, all were caused by some old FCKeditor version producing bad HTML.

Only one was addressible with PolyPager code and so I did.

Considering that I have long switched from "fixed" to "transitional" XHTML, I now consider this bug fixed.

As always: When a big issue comes up, we can open another bug for it.

make an index of contents for the actual page.
The index contains anchors to the actual entries and is

• optional (in the page)
• javascript-on/off ?

mostly it would just show the title field, like list_view does. Maybe we
can use the result set and set it back afterwards.

another idea is to make it more like a table of contents (toc) for all pages for which the entries are grouped:
group1
--entry1
--entry2
group2
--entry3

03.05.2006 - fixed in version 0.9.1.
...

the minimal gallery uses tables to build up its structure. that is no good for slim designs.
Maybe there is an easy way to make the gallery use divs...

in mg_brain.php, I changed the function thumbnail_table.
<table> became <div>, <tr> became <div> and <td> became <td>.
We'll have to see in practice how the skins get along with it, I guess.
But it looks quite ok, as I can see.

i don't yet know if that should be an option and if so, where...
maybe under "the system"
I mean, you could still render them invisible via CSS, be it in the skin or in the user.css file...

15.05.2006 - I made them invisible per default

when a page has a last_edited-field, the admin may want to feed the fields also when they have been edited (like a bug that has been worked on...).
The feed-field could become a little valuelist:

• do not feed
• feed new entries
• feed changes
• feed new entries and changes

and the behavior must be programmed, but that is only in PolyPager_Sidepane.php
(maybe don't show fields twice - only the newest...)
for instance, one item should not be in that list twice. Or maybe it should? Maybe we should indicate why it is in that list (new/updated). So this is not that simple...

and: the SQL-Update would first insert that new feed-field, then update it with 'feed new entries' where the old one was '1' and then throw the old one away.

22.06.2006: another idea is to have a checkbox on the editing form, that says "feed this again, now!" That gives you as editor the total control (but automatition is good, right?).
I am also not quite sure what feed readers need to refeed an entry...

07.07.06
I like the last idea better. Some changes are important, others are definitely not. I would need a table that contains entries that have been pushed to the feed like that. A good thing about that is: That way, you can feed anything, even if it doesn't have a date field (you just need a title). That could change the whole feed-approach here:
1. you say that some page needs to be fed automatically when a new entry arrives
2. you can always do that manually by hitting a checkbox before saving (for multipages: the code could give you a text input if you have no title field)

The rss.php would then consider both: entries and the changed-table. One problem: How to keep that table clean from too much entries?

13.07.2006
todo:

1. a table that contains a datetime, title, pagename and id of the pushed items
2. code that displays the checkbox nect to the "save" button (in PolxPagerLib_Forms.php)
3. code in PolyPagerLib_Editing.php that cares for that extra table. It gethers information on how many items are in there. If that exceeds a threshold (50, test with 2), it deletes the one with the oldest datetime-entry. it also deletes all entries with the same pagename/id key. then it inserts the new one.
4. PolyPagerLib_Sidepane.php needs to be updated so that it can handle all that. It merges arrays sometime, so before that all issues must be resolved (e.g. splitting the datetime in date and time). Generally, date and time is too much. We should use datetime where we can (singlepages, comments, templates like blog,...). Some more thought should go into the question if we expect datetime fields for being feedable on entry? maybe we should accept date AND datetime fields and sort the date-fielded entries in somewhere... (00:00:00)

14.07.2006
I did it! Actually, I threw away the old feed option and code. This is the new way. In the form you have always the choice to feed or not to feed. Per default, you feed new entries (maybe that needs a few days more thought: is that really what we want?).

request from jan:
some entries should always be there.
My answer: I'll make a standard group for singlepages that has the following semantics:
All entries in that group are always there, no matter what group you select from the submenu.
It has now own entry in the submenu - or should it? Maybe it should be the default group, too, so that it is the only group you'll see when you just request the page...

20.05.2006 - implemented

there should be nothing or the first page's contens

08.07.06
fixed by another bug yesterday - back to list view was broken

...has a lot of fixes and performance enhancements.
it's not that easy replacing it, though:
-style of the editor
-my own adjustments
-the authentification in the upload phps

need to be considered (the last ones have changed).
maybe such an update could be documented roughly for later use...

12.07.2006
ok, done. updated that text fiel that contains all the stuff that must be updated...
resize option is cool :-)

a demo should be available so people that are interested can browse through PolyPager themselves to see what you can do.

The only real problem here is: make it hard to abuse.

1. can we somehow restrict upload size? i don't think so... an alternative is to regularly clean everything up. Since I don't have cronjobs at all-inkl.com, I could write a PHP script that gets called every morning by me...
   
2. we need to make the adminname- and password ("admin", "admin" or so) unchangeable
3. we need to make that public, with some unchangeable info text

For 2 and 3, we need to hardcode something, maybe by a global boolean variable ("run_as_demo" or so)

P.S. good point to watch what happens with directory permissions...

15.07.2006
should work, but is untested. I'm curious :-)

17.07.2006
some small problems, now it works :-)

Previewing an unpublished article is very useful.
that one should mostly consist of stealing code from other places around here.
a popup window should display the current state of the entry.
the point is that the best thing would be to see the entry "live", without saving the code in between. then, how to send the code? That would be JavaScript and I hope that some googling would help there...

03.03.07
I would like to use this script to blend in the preview. That'd be awesome.

3.3.07
I disagree with the website's anouncement: popups always suck!
BUT: for a preview this would indeed be beautiful!

06.03.07
fixed for 1.0rc1

looks different in every browser - there must be some css gone wild

 

09.08.2006

fixed

That speaks for itself.
Some users might forget that everyone can edit everything when they don't change it.

26.10.2006 - implemented

Since not every skin can work with every HTML template, it's better practice to let a skin define the template it's working on.
So PolyPager >= 0.9.6 will expect a file called template.php in the specific skin-directory.
Note: Don't forget to adjust the FAQ for that.

The template - directory and the option in the admin area should disappear.

02.11.2006
The skins now define the templates. But the user's possibilities to alter them are not clear. Should they alter the skin's templates? Or copies of them? What happens if the skin gets upgraded? Shouldn't it still happen in the user - directory? All of those questions are wothwhile...
The FAQ is still unchanged and the template - directory is still in place, though unused at this point.
Not very professional :-(

17.11.2006
I decided that a user with admin privileges should be able to change the template. Now, I changed the webadmin.php script to allow him to do so directly. As he now has some access to the style directory, it's also necessary to get rid of that Style-directory in the user-directory and move its contents to the style directory. This includes user.css and the bg-pics for picswap. A rather big change, but this issue was pressing.
Will be available in 0.9.7

There seems to be an option in the gallery script, but it's not sure if it's working...
Jan provided some changes to the script such that clicking on the picture is working.
Will be included in 0.9.8

If I could assign fields to formgroups, theys could be grouped together visually on the input form.
A whole group might even be hidden (showable vie a js link) if it's none of the "important" issues.

That would make the user experience lighter.

That formgrouping could either happen in the code of getEntity() or even as an option the user has in _sys_fields (and then, for a page he might specifiy the valid groups) - but that's maybe too much.

Most of the changes for the first option would be in writeHTMLForm() and would ruin the ordering of the fields. It would be smart to collect all the generated form input HTML in an array and then display it groupwise. That's not too much work...

06.12.2006 - implemented without collecting HTML. I reorder the field list before displaying it.

the field order should be manageable. It's no fun to change field orders in the db.
Done for 0.9.7

PP will then show something like 30 Nov 1999 or so.

Done for 0.9.7
it now shows a text saying "no date set yet" or so.

Users should be able to label their fields as they please.
Done for 0.9.7

done for 0.9.7

there can very well be archives or other stuff that should not be assumed to be a skin.
Done for 0.9.7

see here for more information: http://blogs.law.harvard.edu/tech/rss
Should be no big work...

25.01.2007
ok, done for 0.9.9

I included these item-childs:

title,link,description,pubDate,guid

anything else you want in?

 

26.1.07
For now that's fine. Would be sweet if one day we could have images in the feed (like tagesschau). And in case we go for tags, maybe categories would be good. Although I Don't know what they are good for. I believe Google Reader showed them, sage doesn't.

-jan-

 

26.1.2007

Well, pictures... we do everything automatically, so I would have to search the HTML within the field (that I guessed is the primary text field) for sthg like <img src=....

That's work, but may be nice. someday.

not much work, just thinking about what is needed more often for a minute.

04.01.2007
done for 0.9.8

Disable the group-field when there is nothing to group by (no valuelist)?
Or, on this occation: I maybe sometimes want to group *without* saying what values there can  be, but use the values that are there (e.g. group after usernames) - how can we do both?

04.01.2007
Here is a plan:
display a combo-box AND a text field to enter values for that field (if there is no valuelist entered in _sys_fields). The combo box is filled in getEntity() with some GROUP BY statement. If there is nothing, don't show the combobox. This is not much work. The places in the code using the valuelist can stay like they are. TODO:
-implement GROUP BY stuff
-change writeHTMLForm
-change getEditParameters so that it first checks for the text field, then for the combo box
-adjust the FAQ and the help text

25.01.2007
implemented the GROUP BY stuff. Now you can use any field as group field. If it has no valuelist, PP will figure out what values there are.
The rest is not really important, just a nice idea, not more.

done for 0.9.8

 done for 0.9.8

done for 0.9.8

we handle a title field like Firefox handles the titles of its tabs:
HTML chars like <,> are not allowed (they will be shown as is - that means encoded as &lt; or &gt; in the HTML -), but & is allowed, so that you can include special chars (they will not be encoded and the special char will be visible).

• "Back to Admin Index"-Link is redundant
  Under "The System" there is a "back to admin index link". Everything I see after clicking is already there before clicking.
  

• <h1> "Admin Area" missing in some places
  The <h1> is there on some pages (pges, content) but not on others (the system, editing a page). Would not bother me but I have problems with my recent skin layout on all pages where the <h1> is missing.

25.01.2007
fixed for 0.9.9
-nic-

Somehow the dropdown list with the topics vanished from the FAQ admin section. I tried to fix it, but the settings would not show.
I put the priority to 3 this time as I thought it might be something PP specific again. If it is not, should be higher priority.

16.01.2007
I fixed it.

fixed for 0.9.9

For given skins that get renewed by an upgrade, edited template.php files might get overwritten in the process. That might cause trouble and anger.

Why not do it like with user.css? If PP finds a user_template.php next to template.php, it should prefer that one.
user_template.php will, as user.css, not be part of the PolyPager-archive, so it will not overwrite the template that the user edited when (s)he upgrades PP.

Comments?

04.02.07
Sounds reasonable. Another suggestion would be: Take all skins out of the upgrade and deliver only a very simple one (mostly black and white), so no one actually will want to use that. And then make another area for downloading skins.
The more I think about it, the more I think skins should get a separate download section. It really is unnecessary to deliver them with every upgrade again.

05.02.07
yes, that is worth considering. The default skin doesn't need to be ugly though, just one that is mostly white and doesn't take too much space.
Maybe use these pics to surround the data-frame, select nice fonts?
Or convert another Wordpress skin - not too difficult.

5.2.07
No, does not have to be ugly.But doesn't necessarily need pics, does it? If converting Wordpress css is easy, maybe we should go for that.

15.03.07
I changed the script that builds the distribution to make separate archives for the skins and PolyPager. That leaves us with:
-still the same problem for the default skin. If you change that template.php, it will get overwritten :-(
-we should collect screenshots of each skin and write one sentence about each so that they can get published on pp.nh.de. Do you wat to throw in your chinese - looking one?

15.3.07
Let's just tell people that if they decide to change anything in the default-skin, they should rename the folder for above reason. Should be a task of medium complexity for most of the folks that know how to change a template.
Yes, I'll throw my bamboo in, but there are still things missing (submenus, comments) and other things that don't look too good (menu looks like shit once you get more then approx. 5 entries as it will expand to two rows then). Have you tested default in IE yet?

15.03.07
Nope. And it still lacks comment styling and I don't like the menu very much. Would you do the first if do the latter?
I think your idea with folder renaming is ok for now.

15.3.07
In the beginning, I did not like the menu much, either, but the longer I looked at it, the more I liked it. I tried to give the single entries a bit of a margin, but that did not work.
And yes, you do the menu, I have a look at the comments on the weekend.

24.3.07
I deliver the skins as distinct zips from now on.
Still needed:
-the asia - skin :-)
-screenshots from every skin - let's say two or three. Should we decide on a standard view of which we take the screenshots?

Right: Wikipedia knows this on time formats:

"The 24-hour clock is a convention of time-keeping in which the day runs from midnight to midnight and is divided into 24 hours, numbered from 0 to 23. This system is the most commonly used time notation in the world today. [...] It is also the international standard notation of time (ISO 8601)."

So: Time should be in 24-hr clock.
But: What do we do with leading zeros? I personally think they look ghastly:
01. Nov. 2006 - 09:30 h
So My favorite would be:
1. Nov. 2006 - 9:30 h
Which - as a template - should look something like this:
d. mmm yyyy - h:ii h

07.02.07
See here for how that would look like.

7.2.07
Just for consideration: Sage gives a weekday automatically. Wouldn't it be neat if we could fill the vacant pm/am space with the day? Like "Wed, 1. Nov 1921 - 0:23 h"

07.02.07
Who the fuck is sage? btw, I can get all I need from the date-function in PHP.

7.2.07
It is a feedreading fucking Extension for Firefox. I thought I had bloody mentioned it that often by now that I could drop the fucking description.

26.2.2007
fixed for rc1

Full RSS feeds may be more appealing to people who use feed readers - and it doesn't matter to the others. At least that's the point I see here.
This is an ongoing debate. Maybe it could be a system option - what do you think?

21.2.07 Well, you always were the guy who did not want to have options. I'm fine with an option. But when I give a full RSS one day I don't have to design a website any more because people will jeust use their feed readers. As long as I can keep it like it is -- fine.
If we are talking about it anyway: What do you think about another option: Only display the title?

And by the way: I totally disagree with scobleizer. What I want tomorrow is a feed that gives me a representative brief abstract of the entry. So after having read the feed I want to have to things:
A general knowledge of the content
A yes or no answer to the question "Is it worth reading the whole entry?"
If the answer is yes, I actually prefer reading the content on the original site, because form shows you something about content as well.
Asking for complete content in the feed means asking for a reproduction of the website's content. Why would I want to have my content reproduced? It is already there where everybody can see it.

But again: I'm fine with an option if you want to go through the trouble writing it. And now I am getting Ideas:
Make the option like this:
display zero content
display first xxx words of content
display complete content
display customized rss content
If anybody ticks the last option, there will be another editor underneath the editor for the entry. So after writing your entry, you write the rss-entry yourself and then you click on a send button and everybody is happy.

Whatever...

13.02.2007
I made a simple option for now.
Your idea is sure nice, but I haven't got the time right now.
Committed revision 76 for 1.0rc1
You'll need to upgrade your database...

I do not know how, but I managed to fuck up my whole feed table. reconstruction goes as far as this:

1. renamed page "Ausgewandert" to "Crème Anglaise"
2. "Crème Anglaise" appears in the menu but produces "no known page specified"
3. I try hexadecimal unicode entities by c&p from a website and get weird characters
4. I try to change the name back
5. I get an error message from Polly
6. I go into the sql database and rename manually
7. Feed links are broken
8. I rename pages in PP so that feed links and page name is consistent again
9. I rename pages in PP to desired title
10. Not a single latest entry shows up
11. I have a look at table "feeds"
12. ALL feeds link to Cr&egrave;me Anglaise (even the ones from other pages)
13. I rename ALL feeds accordingly by hand
14. I swear a lot

Entities should be possible in Page titles, should they not?

24.3.07
yes. I went through all the code to make sure that they also get encoded in link URLs. That was one source for errors.
The bad news is that I could not reproduce your error. Can you?

20.04.07
This seems resolved for 1.0rc2

When you use FCK to style comment (I tried boldface, so I clicked on the bold B), PP will not accept the html with a message like: You have used forbidden html tags. You are allowed to use <b><i><u>. Your item has not been stored". I presume the problem is FCK using <strong> instead of <b>

28.03.2007
fixed for 1.0rc1
FCKeditor will now use <strong> and <em> which had to be reflected.

I like the FCK now already showing my entry in formats similar to my own css. Only problem: My <body> has (needs for page layout to work in IE) text-align:center Everything else (p, li, ...) is justified. FCK chooses to use body-information, so all my text in the editor window looks crap.

• In "the system" full content in feed should be next to number of feeds
• Maybe "Content" should be furthest left in "Let's talk about" as it is a bit contra intuitive to have "content" open as soon as you go to admin but then find it on the far right
• I'm not sure on this: Name of gallery seems to belong to "pages" rather than "the system", so maybe we could move the complete gallery field to "pages"?
• I believe that "gallerys order index" should read "gallery's order index"
• In Admin -> pages -> misc it says "asc/descending order of order". Not quite clear what is being called to order here.

03.04.07
Fixed all issues for 1.0rc2 - besides the gallery-in-pages issue. That's just not simple...

At the top of singlepages that are not visible in the menu it now states "from the page BLA", even when I view the whole page and not only a single entry.

29.03.07
It's not a bug, it's a feature.
If it's not in the menu, it should be clear where you are. If you agree to the above statement, delete this bug.
If not, tell me a better way. Maybe a less distsracting formulation?

29.3.07
I don't like things being written into my page when it's not me writing them. It should be clear where one is from the title-tag. And when I want to make it very clear, I can always put it into the menu (or submenu). You say "If it's not in the menu, it should be clear where you are." Usually there is a reason why something is not in the menu. So I don't like the feature.

29.03.07
The title-tag doesn't include the page name if there is only one entry shown - in that case it displays the entry title.
Maybe it should always display the page name. But won't it get a little long then?

29.3.07
I don't know, I still think there must be a reason why something is not being put into the menu, so I still think the whole feature is unnecessary. The only idea I have will just provoke a conversation we've had many a time: Make an option. 
Another way would be to always write the page name into the title tag, and never write the entry title there thus preventing the thing to become too long.

29.3.07
I still think one can feel lost when there is no info about the page somewhere.
Let's put it in the title. If someone chooses too long homepage and/or entry title, it's his/her fault.

29.3.07
Fuckin' A

29.03.07
...err... anyhow, now I remember why I did it in the first place: When you see a single entry from a page, how do you know that there is more to see on that page? There is no clue. That struck my heart as a content provider.
Any ideas on that?

30.3.07
We briefly talked about that in Dublin or Osnabrueck (or New York or Kuala Lumpur), but under a slightly different angle: My concern then was that when one arrives at an entry through a link, it is not clear that there is more -- even when the page is in the menu. Maybe like this: Put a link at the bottom of every page that only shows one entry but has more in the database: "Read more from the page "Bla". But I still think it does not make any sense to tell people where they are when they already see all entries (title-tag should be sufficient).

30.03.07
when they see all entries, nothing happens, no? Below the entry is a good compromise, I guess.

30.3.07
Seeing all entries, page visible in Menu: nothing happens
Seeing all entries, page not visible in Menu: nothing happens
Seeing one entry being the only one from in the database from this page, page visible or invisible in menu: nothing happens
Seeing one entry but more from this page are in the database: link.
I recall that you have a similar thing already going when you decide to use "step", i.e. show only first 20 entries or whatever. Maybe you can recycle that?

02.04.07
ok, fixed using your suggestion.

I update feeds when pages change or get deleted. However, I oversaw updating them when entries change their titles ot get deleted, too.

done for 1.0rc2

The default name for the galleryt menu link should be "gallery"or so.

Fixed for 1.0rc3

done for 1.0rc3

When I tried to restyle the Brasserie css to allow comments I encountered the following problem: The entry is inside an area tagged <show_entry>. The comment fields are not within this area. I separate my entries with

.show_entry{
    ...
    margin-bottom: 100px;}

I can't reassign the margin to the comment-tag as there are still several pages that don't use comments. I could only work around this because I only have comments on multipages where entries are tagged something like nameofmultipage_polypageranagram. So I could set the margin for these to -100px and assign comments with 100px.

Again: I believe the comments belong to the entry, so they should be inside show_entry.

fixed.

If you edit a comment (in the admin area) and give it HTML attributes, and submit, the response page looks ugly.
The bug: For consistency, the old comment content is hidden in an HTML attribute to be compared with the new when you submit again. When it contains HTML with attributes, it breaks the attribute it is in. But textarea fields should maybe not be consistency-checked at all.

Done.

Something is still wrong with entities in titles, at least with quotation marks. I used them here, here, and here. I put all of them in like this
"
It worked fine when I saved them. But after saving they get turned into
&quot;
in the title-field. When I came back after the bug was fixed to add the actual description, they all looked like and saved again, they get displayed as
&quot;
too.
It doesn't seem to happen in the feed.

When the user selects to administer a new field of a page, he has the choice between all field names of the table.

But if there have been entered some fields already, don't give those as choices.

This helps when Polypager gets upgraded.

The PolyPager_Config.php needs to be created with a new install, but I left PolyPager_Config.php.template to copy.

 

there is also a template.php.template for every skin that can be used to make an own template that also will not get overwritten when uploading the newest Polypager. Here, Polypager will fallback on the .template file if the original is missing.

Since rc5 comments on polypager.nicolashoening.de seemingly are not being advertised any more. The default text is now »Add a comment«, even when there already are comments. See here and herefor instance.

This one is nasty. I found out that this appears when some CSS file could not be found. In our case, user.css might not be existing. Then, the CSS from that 404 error page will overwrite ours! So, the fix for this will be to only link to an existing user.css file.

If you customise the labels on a multipage, the search options don't receive them. If my sql table row is called »price_range« and within Polypager I specify the label as »Preisgruppe« for instance, in the search options it will still read »price_range«.

I find it a bit confusing to see

You are seeing a selection of all entries on this page. See all there are.

when I searched for something, because I do see all entries there are -- the ones matching my search criteria. So maybe suppress this message for search results?

After deleting a comment I see "Es wurde kein passender Eintrag in der Datenbank gefunden..." even though there are two other comments.

Also, a link back to the actual entry from its comments would be nice.

I use Georgia for links only now...

27.09.05 - PHP doesn't need to initialize vars - can be your own trap

27.09.05 - made the two menu rows a lot better: you really see where you are

make new, higher gifs for the sliding doors and de-attach the background from the ul! 27.09.05 - it's not perfect, but better that nothing

28.09.05 - done

First, review validation in general. sometines they do not seem to work like expected...

13.07.2006
fixed, No one needs that by now

Both on the clientside and the server (especially) I would like to delete all PHPs that we are transforming/uploading beforehand. Should not be too much work...

17.10.2005 - My Server doesn't accept the * wildcard. I removed this code for now.

22.11.2005 - Since I have not so much files anymore, I turn this to "fixed"

It should be possible not to say URL/?page=X but URL/?page.

Maybe grap the first param and call it "page" internally.

06.12.2005 - increased prio 4 -> 2 because I like this bug

 

29.12.2005 - done

Two rows of options should suffice.

Who really needs font families? Also make use of the new feature that turns font elements into spans... how is W3C compatibility?

19.01.2006 - fixed - we're using FCKeditor now...

You can toggle from "no.gif" to "ok.gif" but not back.

in javascript.php:

Opera seems to store the whole url in link.style.backgroundImage, though I write something else in there :-(

that requires some trick...

 

fixed it - now it decides what to toggle if the picture matches /.*ok.*/

If date fields are to be filled in, the supreme plugin would be this Java Script Open Source Calendar .

18.01.2007
put it "on the ramp". It's too cool and since I support all types in 0.9.9, this should come.

18.01.2007
done for 0.9.9 :-)

possible:

1. PolyPager
2. Spa (Structured pages)
3. Sherpa ( Structured ... Pages)
4. YoPa (Your Pages)

19.01.2006 - I chose PolyPager (the domain is also free...)

useful for search results, feed chunks, listing of entries

We need the first paragraph or 2-3 sentences or just 100 words but how to get them?
sentences with search terms are the most difficult case.
Markup needs to be taken into account, that means, ignored correctly.

Here is a PHP function to do it. We could then look again if the keyword was really in the non-html part... (and make a substring out of that region surrounding it).


24.07.2006
there is now a function to get the first n words, without any HTML in it.