blekerfeld / donut Goto Github PK

The thread functionality needs to be finished, with links to the reply and new thread pages. There needs to be a setting regarding permissions and the entry title needs to be shown in the discuss part :D (Might to have to do some moving around).

More render modes, these include:

• Select from table
• MarkDown textarea
• Flag
• Templates

For security purposes, it would be really helpful if you could ban IPs or specific users. Bans would be permanent or temporary.

Need to find a way to combine both lemmas and 'translations' (with lang_id = 0, so definitions).

Check all foreign keys, to solve #27

This line in /code/classes/DataModel.cset.php (line 200) gives a syntax error:
$count = (p::$db->cacheQuery("SELECT count(id) AS total FROM ".$this->_table." ".$this->_condition.";"))->fetchObject();

Parse error: syntax error, unexpected '->' (T_OBJECT_OPERATOR) in {...}/code/classes/DataModel.cset.php on line 200

The same error occurs in InflectionTable.cset.php on line 36 and IrregularTable.cset.php on lines 37, 39 and 42. It's possible you can instantiate a class and invoke a method on it in one line, but can't invoke a method on the result of a method if you but parentheses around them (which is weird, since it's basically the same thing). Anyway, removing the parentheses like this fixes the issue:
$count = p::$db->cacheQuery("SELECT count(id) AS total FROM ".$this->_table." ".$this->_condition.";")->fetchObject();

Form.cset.php gives an 'Unexpected character '[' error on lines 194 and 195, but this can be solved by replacing

				$output .= ($this->dataModel->data()->fetchAll()[0])[$this->_showField];

with

				$output .= $this->dataModel->data()->fetchAll()[0][$this->_showField];

Line 220 in LemmaSheetDataModel.cset.php, an 'uxpected new' error occurs. 'new' is a resolved keyword, renaming it should fix the issue. In the same file, on line 297, the following line causes a 'Fatal error: Cannot use isset() on the result of a function call (you can use "null !== func()" instead)'
if(isset($dM->data()->fetchAll()[0]))
Replacing it with something like this fixes the issue:
if(array_key_exists(0, $dM->data()->fetchAll()))

The same error occurs in SetHandler.cset.php on lines 65 and 76. Changing that line to the line above (but replacing data() with getObjects() fixes the issue. In User.cset.php, the issue also occurs but can be solved using the same line as in LemmaSheetDataModel.cset.php.

In User.cset.php the following line gives an error (Strict Standards: Non-static method pUser::load() should not be called statically):
return self::load(self::$dataModel->data()->fetchAll()[0]);

Since you don't have an object (non-static methods can use static methods, but static methods cannot use non-static methods (since static methods are not part of any particular object)). I haven't looked at how to fix this one, but I'll let you know.

Dispatcher.cset.php calls to code/Dispatch.php, but since that file doesn't exist, it fails. It can be fixed by replacing the following line:
$this->_dispatchData = require_once p::FromRoot("code/Dispatch.php");
to
$this->_dispatchData = require_once p::FromRoot("code/dispatch.php");

Since I have already applied the changes (apart from the user loading issue) myself, I'll submit a pull request within the next 15 minutes.

Build: 93b0877
PHP version: 5.6.31

Should not be that hard to do.

That way it would be possible to have two linking tables for words within words (synonyms and antonyms).

..

... maybe with a setting, or word-for-word configuration... or just derived forms as normal links...

Let's face it, productive PHP is a pain in the ass.
Starting with creating an OOP admin panel, the goal is to OOP-ify the whole code by its first release. Bit by bit. It's just much easier to have everything neatly in once place! 👍

There seems to be a bug in the permissions of the menu. The editor menu heading keeps being shown when logged out... this needs some research.

Rules (inflection, context, ipa) should be able to be organised in some folder-like structure called rulesets.

The Batch-Translation functionality from the non-oo donut was pretty usefull, this needs to be rewritten ASAP, but better, even allowing for batch adding of new lemmas and examples, relationships or translating a premade list of english words into the primary language (thus creating new lemmas).

The generation of ready to be compiled latex dictionary file was one of the important features in the original Donut code, before the OOP adaptions, it has not yet been rewritten. It'd be okay to use more or less the same code, but maybe database driven templates are a cool little extra.

Don't know why! Needs research.

Probably a problem with the parse translations function

This repository is still more or less private, as I have not yet shared it with the interessed members of the conlanging community. As the public prototype comes closer and closer (that does sadly not mean it is there yet, at all): I am looking for people willing to test donut.

cset was meant for a set of classes, but since the files just contain a single class, let's change it to the more default .class.php!

The existing auxiliary inflection (basically adding inflected words before or after other words) uses the older gram_group system, which is replaced by the scope selectors, auxiliary inflection needs to be adapted to that.

The idea is then: just the basics, so lemma, ipa, lexical category, grammatical category and tag plus translations in only one (chosen) language.

Have you considered using namespaces? Basically, what you'd be able to do is have multiple classes with the same name. You're currently prefixing all classes with 'p' to avoid class collision, right? Well, if you're using namespaces, you wouldn't have to worry about that.

Again it's just a suggestion, but you might find namespaces to be very convenient.

Fix:

• The same queries over and over.
• Not taking double search hits into account

Main.css is quite a mess, with almost 3000 lines. A lot of things can be removed, made simpler. Maybe I will have like 5 css files instead of one big one.

The admin panel is the first part of donut.oop.a.1, however it is a bit outdated, some parts still need to be added, some parts are obsolote. The set-and-sheet infastructure needs to be incorperated plus there needs to be a general settings section! A lot to do. Link tables may be obsolete too.

When emptying the searchbox, the search event seems to be fired with a previous value, resulting in the following ugly bug:

I just saw I started with this in the constructor of pInflector:

foreach($idM->getObjects()->fetchAll() as $cachedInflection)
			$this->_inflCache[$cachedInflection['hash']] = $cachedInflection['inflected_form'];

Don't remember why, and what I was going to do with that, need to find out.

Recent theme changes caused the mobile theme to break...

-- look up where it goes wrong (probably in the database structure).

Hello,

code/classes/dispatcher.cset.php contains a line that calls for a file named "code/Dispatch.php", but on case-sensitive server configurations that would throw an error.

In code/classes/dispatch.cset.php, replacing

$this->_dispatchData = require_once p::FromRoot("code/Dispatch.php");

with

$this->_dispatchData = require_once p::FromRoot("code/dispatch.php");

solves the problem.

Editing items in the management panel does not seem to work anymore, probably a problem with the field set in the datamodel.

...

This will make things easier for the upcoming inflection table builder!

Out of laziness i left lots of hard coded English strings in the code, they should be localised as soon as posible, no later than the first public release.

For Dictionary PDF generation, Donut uses the mPDF library, but because of its poor php 7.1 support, the development branch had to be used, I fixed lots of things myself and even implanted new functions that work together with donut.

The thing is, installing via composer, will just pull a version from the mPDF-repository that does not work 100% with Donut. Which is why for now, my custom mPDF-library is permanently included as vendor.

I might fork it at sometime and requite my own fork via composer, for now this works.

Any thoughts?

P.S. Version requirement should probably be bumped to php 7+ because of mPDF, but it might just work (untested), otherwise another posibility is just to turn of pdf generation if an older php version is detected...

The new sheet-infastructure for rulesheets is pretty convient. It would be very comfortable to be able to edit a whole lemma (including all examples and translations) on a sheet page.

A simple inflection could be notated into the admin panel using a simple syntax, something like:

-en > +t > ge+#
(maken -> ge+mak+t, which a FSM (to design) could convert into gemaakt).

> seperates operations
-x remove -x from end
#-x remove x- from the begining
+x add x at the end
x+# add x at the begining

Complexer inflections should be handled with a finite state machine, or something inspirered by that.

Folder: root/pages/ -> all .MD files should be rendered as pages on the following querystring:
?page=name.

Pages are hidden from the menu by default, for the purpose of adding them there should be a structure present in the root/pages/-folder that handles it.

Just in case I forget

... would be quite useful!

Etymology fields, that are searchable, so that, if that's what the user wants, an etymology dictionary can be provided. Cognates will be simple links between words and translations.

Because example behave like entries.

VOW_CON_+.CON=> will ditch the second consonant, but right now that can be any consonant. What if it only needs to be removed if it is the same as the match in the middle context? For this a backreference to the match should be introduced.

Proposal for DIS-syntax highlighting to easily understand a rule (morphological or phonological):

[a,b,c].CON_^CON|[o]|&name_CON.CON

becomes:

And...

ge-!^ver[-en-!^aren]e&D;

becomes

Maybe the sheet structure would be best for the tables? Assistant can be used as a helper later on?

... or at least I guess so?

Search queries could be inflected forms of a lemma. There need to be some kind of algoritm that tries to apply all the inflections rules the other way arround to find out what the base word might have been. Alternativly there will be a) a table that links generated inflections to words b) files that do that.

Just as the title says. The pLinkTableObject would need to accept extra fields that are specified in the outgoing_links or incoming_links field.