Bootswatch Flatly under Plugins

[gtbu]

After installation of TP 511b1 of 02-12-2019 the Bootswatch Flatly appears under Plugins

[juek]

Already discussed here

[gtbu]

No - discussed as appearing in the CE Version - but to this is 5.11b1 ! - no excuses...... In CE it disappeared after removal of [FrontEndFramework]

[mahotilo]

I do not have such problem.

[juek]

Behavior changed with this commit. Still subject to change, though.

[juek]

FYI: the change might need a clean install in order to get rid of already registered hook entries.

[juek]

@mahotilo

can you imagine any useful filtering or action mechanisms to be implemented in the FrontEndFramework ini key, which would call anything dynamically at runtime? I cannot at the moment.

[mahotilo]

[FrontEndFramework]
name = Bootstrap
version = 3

OK, now it is hint for used version of Bootstrap. But it is hardcoded in \gp\tool::LoadComponents() in template.php.

Maybe we can put in this section a list of connected gadgets, if they are hardcoded in template? Notifying users that they need to install additional plugins for used theme can be useful.

[juek]

Just to clarify the terminology: Typesetter 'gadgets' cannot be part of a theme, while plugins hooks can.

If I understand you correctly, what you mean would be a different key section, sth. like

[Dependencies] plugins = 'Simple Blog, Catalog Easy'

Correct?

[mahotilo]

Yes, speaking (writing) of gadgets, I meant something like this in template.php

<div>       
    <?php gpOutput::Get('Gadget','BBC_Online_Visitor') ?>
    <?php gpOutput::GetAdminLink();?>
</div>

[juek]

Unfortunately it's getting a bit off-topic, so I'll make it short.

I've already done that and it's anything but trivial. My current solution does not rely on an Addon.ini entry but solves all sorts of dependencies using a custom 'post-installer' in the theme. It is not yet ready for publishing but I can share a screenshot with you:

[juek]

... of course it has also a button ;)

[mahotilo]

Wow 8)

[juek]

another sneak peek:

Of course, such things have a price tag: We get the same trouble we have to tame WordPress premium themes and make them behave the way we want them. Everything with an admin interface tends to be more complex on the programmatic side.

[mahotilo]

Although I am not a fan of themes that can be customized via interface, positively it is cool and a great work.

[juek]

Although I am not a fan of themes that can be customized via interface…

So am I. But people without programming skills need them. Current Bootwatch themes are great boilerplates for developers, but 'ordinary' people are having a hard time even adding a brand logo.

[mahotilo]

Agree, but how demanding are 'ordinary' people to the template. They will always be unhappy with the available settings... Off-topic, off-topic, off-topic:) Great job! It will be appreciated.

[juek]

True.

@gtbu

if the original issue is solved from your POV, can we close?

[gtbu]

Though i do not want to ride on it ...me again...(fresh installation of the changed master) I hope its not windows and Laragon and php 7.2 - but i will check tomorrow online ( i wish a had Your code flexibility...)

[juek]

Thx - seems as I have to check it again.

I hope its not windows and Laragon and php 7.2

Certainly not.

[juek]

Should now be fixed with this commit.

To unregister as plugin, all layouts deriving from themes formerly registered as plugin need to be 'deleted' via Appearance -> Manage -> Bootswatch Flatly/LayoutName -> Layout Options->Delete and then reactivated via Appearance -> Manage ->Available

[gtbu]

It is now ok. It In my Laragon installation i had problems with the long delay of bootswatch Flatly 1.0.2 - but it comes after 30 seconds - ( but also in the master of 2 weeks ago). This delay can be improved if You make a long list as in the CE-Version and add the directories of the older version. less1.php : require_once 'lessc.inc.php'; include DIR . '/lib/Parser.php'; ......

[juek]

30 seconds is way too long for a local development server to compile Bootswatch Flatly (Less). My Raspberry Pi 3 only takes 5-6 seconds for that task. My 'real' local server (8-core Xeon) does it in less than 1s. Doesn't speak for Laragon IMO.

[gtbu]

May i allow me inspite of my poor i5-3570 and 4 virusscanners to offer You this file for test http://typesetter5.bplaced.net/data/_uploaded/file/less.php.zip (less 1.7 wiki) Just delete the content of the less.php-directory and fill it with my bad but fast (!) code - hopefully - Yamantaka will like You then ! Please think of all those slow processors in the shared hostings - also 15 seconds are slow ( P.S. How can 8 cores help, You if the compilation is a single process..)

[juek]

Compile Bootswatch Flatly/Sticky Footer Less

Test results on Raspberry Pi 3:

Current less.php (TS 5.1.1-b1):

1.19 MB Memory 13.15 MB Max Memory 4.714 Seconds 4714 Milliseconds

Your version:

1.02 MB Memory 12.51 MB Max Memory 3.616 Seconds 3616 Milliseconds

[gtbu]

This measurement - I do not know the procedure - takes place on a 'dedicated server'. On Xampp and Laragon I have a factor of at least 5 --- in a fast web of about 2. People with small ram have bigger problems. On the github page of Ojeyorge is also referred to the further development in the wiki less-version. But heck - my corresponding CE version is 2.53 and correspondingly fast and extensive, and I do not want to force anyone to happiness.

[mahotilo]

May i allow me inspite of my poor i5-3570 and 4 virusscanners to offer You this file for test

I use only one simple MSE antivirus on my i5, but I exclude dir with my local web-server form checking due to its noticeable impact on site speed. Could it be, that your CE version is detected by system/scanners as local files and checked only once, but TS downloaded from github is detected like as a dangerous object for permanent monitoring? Could this be a source of speed loss? Have you checked TS-b2 without 4 virusscanners?

[gtbu]

Just for fun : I have Avira free, Iobit malware fighter 7.3 with bitdefender (giveawayoftheday.com) and Secure aplus with 12 engines(share on sale) - thats the reason for speed loss inspite of 16 GB Ram : The CE-Version is quite the same - just version 1.83 and with a different folder and less2.php (and php7.4 ready). My scanners check everything ... just not spyware (adwcleaner 8 is for that!).

The version of the above link is 1.7 just as the momentaray version of tp511b1 but a bit faster (and evtl. some corrected isuues), depending on the server. The newer version 1.8 ist not tested with php5.4 (Hm - YOU can do that - it is quite easy !) Seen from a long distance You will have to use the wiki-version anyway (if not less-i - which needs bigger adaption).

Well - if You have doubts - just make a directory ___tmp in the less.php-directory and shift everything into it - then copy the files of the above version into the less.php-directory and test it in the web. Before measure the time after cleaning of the tools-cache by installation of a version of flatly-theme with the old version, and compare the times of the new version - You will see whether it is worth. (P.S. There is also a bootstrap 4.31 less-version )

[juek]

a 'dedicated server'

Although the RasPi acts as a dedicated server (it hasn't much else to do normally), I'd say a 3rd-gen i5 is roughly 30 to 40 times faster than the RasPi's ARMv8, and a recent Xeon some 200 times. Your issue with local windows dev hosts is most likely due to antivirus stepping in. Especially when large amounts of temp files are created, which is the case upon less compilation. Not a real-world issue IMO.

[juek]

Seen from a long distance You will have to use the wiki-version anyway

I personally do not use less anymore, since Scss is more powerful and the compiler performs better.

[juek]

This measurement - I do not know the procedure

In this case I simply used the Admin Menu -> Performance section. With a fresh setup without installed plugins…

• assign BS Flatly to a single page, use a BS Scss theme as standard.
• clear the cache (Tools -> Resource Cache).
• return to a standard page and let Typesetter recompile the Scss and Admin part, then switch to your BS Flatly page.
• when the page shows up (after the Less compilation finished) the Performance section will show the results, mostly caused by the Less compiler.

You can subtract some 20-40 ms and ~0.7 MB memory usage for the normal CMS operation.

[gtbu]

Sorry - but i disagree a bit : I prefer, after complete installation without Flatly 1.02 themes and then cleaned cache , the choice of a flatly theme, then click at it and measure the time until it completely appears in the 'chose as template'. This delay is the nerving point in some webinstallations. Similar is the choice of a Flatly-Site after cleaning of the cache, and the wait-time until the site appears. The wiki-versions is remarkable faster (and have less issues. Mediawiki is based on Less - they remove Scss where possible and have Less integrated) : In the normal shared hosting the memory is 32 (east europe, cheap and free providers) to 256 MB (Strato,1&1) and a delay comes from harddisk-stepping (if no SSDs) and queue with other users. So we have a worst case scenario and an average scenario and to consider poor installations.

[juek]

In order to clarify my point of view of which LESS compiler we use at the moment - for everyone reading along.

Josh stopped the maintenance of his less.php compiler some time ago. Wikimedia forked and still actively develops it further, which is fine. In the meantime Bootstrap also offiicially moved from LESS to Scss, same as Typesetter. We have ScssPHP for quite some years, which is IMO superior for several reasons. However Josh's less.php still is part of Typesetter and required to process legacy Bootswatch Flatly (and other less-based) themes.

Wikimedia's current less.php version requires PHP 7.2.9. Typesetter still supports PHP 5. This is why we will not simply upgrade, which would lock quite some older Typesetter installations out of our current bug fixes.

With the next major release, whenever it comes, things will look different.

[gtbu]

No - its not quite like that . Josh's version was still under vendor at mediawiki 1.29 and now removed. Version 1.80 and 1.81 (which i have) should be ok . Mediawiki got the versions from github-asenar. Version 1.80 an 1.81 should be 5.3 to 7.3. (The << link contains the raw version!) For users of php7.3, version 1.7.0.10 has some bugs. (1.82 and master need 7.29+; 1.8x.dev is for 5.3+ ...my CE Version was at time of publishing for php 5.6+ ---- a big Chaos)

[juek]

Well, if …

• it works with our current minimum system requirements (PHP 5.4 but I could also live with 5.6 for Typesetter 5.2) and
• it's actually faster, which appears to be so

… we should use it.

But we should then strip it down to what is actually needed. Your package is ~2.3 MB in size while our current version is only 256 KB.

@oyejorge Mind to look into this?

[oyejorge]

Will do!

[juek]

Great!

I can confirm that it works with PHP 5.4.4

For testing please update to

343 and this commit