Jump to content

MadeMyDay

Members
  • Posts

    371
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by MadeMyDay

  1. 22 hours ago, bernhard said:

    Great looking site as always! What tool is this? ? 

    Danke Bernhard ? This Lighthouse score, built in in Chrome/Chromium. Look in DevTools -> Audit.

    21 hours ago, teppo said:

    I had to take a closer look, and it's actually mostly related to our PHP task, which runs PHP_CodeSniffer (which can be very time-consuming). You can use this with any files, though — check out https://www.npmjs.com/package/gulp-cached. It's really easy to add, basically just require the package and add a single line to your gulp task.

    The basic idea is that gulp-cached keeps track of files, and makes sure that files are only passed downstream if they've changed since last run. What this means in practice is that when using watch, the initial build may still be slow (none of the files being watched are cached) while subsequent ones are going to be much, much more performant, as all files that didn't change will be skipped over.

    Seems a very good idea. Will try that!

    21 hours ago, teppo said:

    You seem to be running sourcemaps on every build. If this is really the dev/watch process, then I don't really see a reason to do that, and it's definitely going to slow things down. We're using gulp-if to check for env and only setting sourcemaps up if it's a production build (basically gulp build vs. gulp watch).

    well, I use/need sourcemaps in dev more than in production. But sourcemaps are not the bottleneck. The thing is: This is my standard gulp setup and it is usually so fast that I cannot even see the refresh in the browser because my eyes cannot switch so fast from editor to browser ?

    22 hours ago, teppo said:

     I'm not seeing anything related to purge here. If you're using the purge setting in Tailwind config, this is a relatively new thing and I really can't say anything about that — for me it seems easier to just run purge as a part of the gulp task:

    Purging is only done in production builds. And yes, I am using the purging in tailwinds config like this:

    module.exports = {
      purge: {
        content: ['./src/*.php', './src/**/*.php', './src/php/*.php', './src/fields/layout/**/*.php', './src/fields/layout/parts/*.php'],
        options: {...}
                  
      }
    }

    In dev the whole tailwind declarations are used (2MB css file). BUT: This is it! Thinking about it it doesn't make sense to bundle everything (including Tailwind) up in development and distribute one (large) CSS file. It would be better to distribute the Tailwind CSS as it is in dev and only process my own css/stylus files like I always do. Will try that. Thanks for the rubber duck debugging ?

    22 hours ago, teppo said:

    Actually it shouldn't — just having something like px-3 in a file with nothing else should be enough. Again this is based on the code I've posted above, so if the native feature is using some sort of "advanced" matching algorithm, it could be a major problem for a lot of code. Weird.

    yes, this is the other major problem. I really don't see why this just doesn't work. I already quoted the tailwind config above and you see I already tried to add more sources and be more specific, but somehow a lot of the classes just don't get recognized. Problem is the first time I purged or better tried to purge the project already was pretty complex. So I have no clue which classes are missing and why. I will try to set up a test case with an empty PW installation and then try to observe what the problem is. But thanks for pointing out that it should work even if the classes are not in a proper HTML syntax.

    • Like 1
    • Thanks 1
  2. 13 hours ago, szabesz said:

    @MadeMyDay Thanks for the showcase.

    Note that the contact form in the English version is 404.

    Thanks szaesz, fixed. ?

    22 hours ago, kongondo said:

    This is unusual. How does your setup look like?

    Pretty basic I guess. But I also assume that something in there is slowing down the process, extract from gulpfile:

    // CSS task
    function css() {
      var plugins = [
        tailwindcss(),
        autoprefixer()
      ];
      return gulp.src(srcPaths.styl)
        .pipe(plumber())
        .pipe(sourcemaps.init())
        .pipe(stylus())
        .pipe(postcss(plugins))
        .pipe(sourcemaps.write('.'))
        .pipe(gulp.dest(buildPaths.css))
        .pipe(browsersync.stream());
    }

    Knowing that it should be faster, I can iterate over it and try to eliminate the bottleeneck, thanks.

    Quote

    Depending on your setup there may be steps you can take to get it down considerably. In our gulp based workflow, for an example, one major bottleneck was solved by adding gulp-cached — on a moderately large site this took dev build time down from what was originally probably 6-10s to 1-2s.

    Interesting, could you give an example of your setup?

    The other issue still remains. A typical .php of the project file looks like this:

    <?php
        $cssClass = "";
        $textoutput = "";
        $waveClass = $page->checkbox1 ? " wave" : "";
        $colClass = $page->checkbox2 ? " flex-matrix" : " md:flex-1";
        $containerClass = $page->checkbox2 ? " matrix" : "";
        $containerHeadline = $page->text1 ? "<h2>{$page->text1}</h2>" : "";
        $cardoutput = "<div class='boxes__cards flex flex-1 items-stretch flex-col lg:flex-row {$containerClass}'>";
        $cardClass = "boxes__card";
        foreach($page->cards as $card) {
            include('parts/card.php');
        }
        $cardoutput .= "</div>";
        $output = "
            <div class='element element--boxes{$waveClass}' id='{$sanitizer->pageName($page->text1)}'>
                <div class='container content pt-8 relative z-20'>
                    {$containerHeadline}
                    <div class='flex items-start'>
                        {$cardoutput}
                    </div>
                </div>
            </div>";
    
        echo $output;

    Most of the tailwind classes don't get caught by purge, some do. I assume it is looking for sth like class="...". And my classes are dynamic depending on settings. I don't know how to solve this without adding a lot of overhead to the template files.

    Quote

    Note: I've got some beefs with Tailwind myself, but those are all about the general methodology. Tech wise it's been really, really slick ?
       

    Absolutely. I really see the benefits and also it makes a lot of fun trying things out and adjusting "on the fly". But with the above mentioned problems the benefits were reduced too much. I am also considering Tailwind for some vue projects, but the overhead for dynamic classes scares me off a little.

    • Like 1
  3. Hi there,

    another one finished, up and running. 

    https://bots4you.de/

    bots4you.thumb.jpg.f2bcf3e12961b48f0444441463043bab.jpg

    The website informs about bots4you which is a German based Chatbot creator. Special with this chatbot is its b2b purpose, that means it is pretty decent in "knowing" what customers of several industries (real estate, insurances etc.) want to know and describe their efficiency with nearly 80% of success for common customer inquiries. 

    From the ProcessWire perspective I mainly use Repeater Matrix with which I only have one template (even for home) but 8 content modules that can be arranged like the customer wants to create different pages. Other than that I used TailwindCSS for the first time, but I am not convinced, at least in a PW environment. Downsides where: 

    • build time when in dev mode (hot reload takes up to 6 seconds)
    • purge of my php files was less than reliable. I ended up putting most of the classes on an allow list in the tailwind config. Could be my fault, but the overall experience wasn't that great.

    Anyway, client is happy, and I am, too:

    image.png.9a0b5b3e247ce7d02caeb061bd123f3a.png

    ?

     

    • Like 10
  4. @celfred: This has nothing to do with the map itself. It takes 15 seconds four your server to generate a response, after that the map and all of its content loads fast. So I assume your process of building the list of markers is somewhat ineffective. Can you show the code with which you generate the $allElements Array?

     

  5. Thanks you two ?

    Quote

    P.S. What about that "rant against Joomla"? Where can we find it?

    Is not online anymore. But I have a backup, it was in German: 

    Spoiler

     

    Schade eigentlich.

     

    Dieser Artikel entstand im Sommer 2006. Bis dahin hatte ich Mambo/Joomla genutzt und hatte die Schnauze voll von dem angeblich so tollen "CMS".

    Ich habe Mambo (4.5.1.) zum ersten Mal im Oktober 2004 runtergeladen und war nach Installation dieses Systems begeistert. Als eher mit rudimentären HTML- und CSS- (von PHP ganz zu schweigen) Kenntnissen ausgestatteter User, der einfach mal ne Seite machen wollte, war ich überrascht. Die Struktur war zwar nicht unbedingt sofort verstanden (Sektion? Kategorie? Was und wann und warum überhaupt), aber dieses System konnte das leisten was ich erst einmal benötigt habe. Ich konnte über eine Oberfläche Inhalte recht schnell verwalten. Nachdem ich eine Seite erstellt hatte und mit diesem konkreten Projekt prinzipiell alle Standardfunktionen testen konnte, stand als nächstes das Erstellen dieser Seite an. Ich hatte vorher ein auf Wordpress basierendes Blog, das eigentlich für diese Bedürfnisse ausreichte. Allerdings hatte ich ja nun dieses System getestet, also musste ein Blog auf Mambobasis her.

    Schon beim Erstellen taten sich einige Schwierigkeiten auf, die aber flugs durch ein bisschen Hackerei im Core bzw. Coremodulen erledigt waren. Daraus erstanden die ersten Tipps auf dieser Seite. Nachdem die Seite wuchs, ein Forum sinnvoll wurde und sich auch meine äußerst beschränkten PHP-Kenntnisse um ein, zwei Befehle anwuchsen, wurden die ersten beiden Module veröffentlicht (Simpleboard und Akocomment latest). Da diese nur simple Datenbankabfragen beinhalteten muss ich mir auch im nachhinein keinen Kopf wegen etwaiger Sicherheitsbedenken machen (sogar bla war drin), aber dazu später mehr. Die ersten Kunden wurden als Nebenjob über Mambojobs aquiriert, für lächerliches Geld wurden erste Projekte realisiert. Der Spaß an diesem System, das Wiederentdecken der alten Liebe "Homepage basteln", die fortschreitende Entwicklung meiner HTML/CSS-Kenntnisse und die Unzufriedenheit im Job ließen mich einen wichtigen Schritt wagen. Den Schritt in die Selbständigkeit, spezialisiert auf Mamboprojekte. Der Gewinn des abstrusen Mambo 4.5.3. Template-Wettbewerbs hat dem ganzen natürlich Vorschub geleistet, keine Frage.

    Kunden fragten an, ob dies oder jenes Design realisierbar wäre, meine eigenen teilweise nicht ganz "mambostandardgemäßen" Designs und das wachsende Interesse an sauberem Code ließen mir oft keine andere Wahl als in den schon bald gut bekannten Coredateien rumzusuchen und diese auf meine Bedürfnisse zu ändern. Soweit alles kein Problem, wenn sich diese Vorgehensweise nicht als äußerst kurzsichtig herausgestellt hätte. Denn ich vertraute meine Zukunft Leuten an, die ich nicht kannte und über deren Qualifikation ich mir erst recht kein Urteil bilden konnte - und zwar den Entwicklern des CMS Mambo. Auf dem Mamboday 2005 konnte man zwar einige kennen lernen, allerdings war das zu einem Zeitpunkt, als alle sich im großen Aufbruch befanden, und zwar einem Aufbruch hin zu dem Open Source Content Management System. Dass es letztlich weniger ein Auf- als ein Zusammenbruch wurde, konnte keiner ahnen. Die Wandlung von Mambo zu Joomla hat die Entwicklung natürlich verzögert, letztlich war es ein unfreiwilliges aber dennoch willkommenes Marketing-Instrument für die Bekanntmachung des Systems. Joomla war in aller Munde, selbst heise berichtete. Große Pläne wurden geschmiedet und vielversprechende Roadmaps ausgegeben, die mich voller Überzeugung weiter an diesem System festhalten ließen. Vor allem die Aussicht auf ein Template-System, das mir keine Gestaltungen vorschreibt (seien es Tabellen oder einfache Content-Anordnungen), hielten meinen Optimismus auf steter Flamme. Erste Einführung des pattemplates Systems war für Mambo 4.5.3. geplant. Voraussichtlicher Release: Juni 2005.

    Es ist nun Juli 2006. Das Land hat einen Jahrhundertsommer, hatte eine Jahrhundert-WM aber hat immer noch kein Mambo/Joomla, das sich in irgendeiner relevanten Funktion von der Version der im Oktober 2004(!) erstmals runtergeladenen 4.5.1. unterscheidet. Sicherlich ist es etwas bunter und im Backend schneller. Und sicherlich hat sich "unter der Haube" einiges getan. Doch was juckt mich das? Wenn man schon Funktionen neu schreibt, warum dann nicht einmal die größten Fehler bzw. Mankos dieses Systems angehen?

    • Tabellen als Layoutelemente: Immer noch hart gecoded, unumgänglich ohne Core-Hacks (liebe Portalkiddies: ich weiß, Euch juckt das nicht, mich schon)
    • Sektionen/Kategorien: Warum überhaupt? Warum das Festlegen meines Contents auf 3 Ebenen? Was ist, wenn ich zwei will? Ja sicher, eine Sektion, darunter alle Kategorien, aber warum? Was ist, wenn ich 4 Ebenen brauche? Klar, statische Übersichtsseiten etc... Aber nochmal: warum überhaupt? Sicherlich, die Rückwärtskompatibilität soll gewahrt werden. Aber hey, dann müsste auch Matthäus noch spielen. Abgesehen davon bezweifel ich, dass es nicht möglich wäre, einen Layer zu programmieren, der in (eventuell auch nicht perfekter Art und Weise) die alten Tables auslesen kann. Oder eben ein Installationsscript, das mir die alte Content-Tabelle sinnvoll umschreibt. Aber wem sage ich das?
    • Keine Objektorientierung der Contentelemente: Sektionen/Kategorien sind noch enigermaßen hierarchisch aufgebaut (solange ich die Menüstruktur auch so abbilde), aber die statischen Contents schwirren einfach so im Raum, ohne jegliche Zugehörigkeit. Ach so, klar, ich muss die ja erst verlinken (vorher sehe ich sie sowieso nicht) und kann so eine Hierarchie abbilden... Prima Idee auf einer Seite mit >200 Seiten. Denn im Backend sehe ich nur einen Haufen von Dokumenten, wo die hingehören, das weiß nur das Menü.
    • Apropos Menü: Der unsäglichste Versuch, das System individueller zu gestalten war die Einführung der Itemid. Jetzt sind diese oben genannten Dokumente nicht mehr nur umherschwirrend und willenlos per Menü verlinkt, jetzt kann jedes Dokument auch noch 10mal verlinkt werden. Das führt zu 10 unterschiedlichen Links, die alle auf denselben Inhalt verweisen (juhu SEO...). Aber klar, das braucht man ja, um die Module ein-und auszublenden und das richtige Menü-Item zu highlighten. Was aber auch schon wieder nicht funktioniert. Denn habe ich im Topmenü einen Link zur "Startseite", im Hauptmenü auch, dann sind das unterschiedliche Links. Je nachdem wo ich drauf klicke, ist ein anderer Punkt "aktiv". Komisch, oder? Sicherlich, das lässt sich über "Link-URL" umgehen, hilft aber auch nix, denn da wird ja keine Itemid angehängt. Lustiges Core hacken mal wieder. Auch sämtliche Pathway sowie Darstellungsprobleme nach Klick auf "weiterlesen..." in der Blogansicht sind auf die Itemid zurückzuführen.
    • SEO: Keine Corefunktion lässt mich gescheite SEO-Links erstellen. Aber ein Core Developer vertreibt eine kostenpflichtige Komponente, die genau das kann... und was jedes Nachwuchs-CMS bereits an Board hat. Ach lassen wir das.
    • Teufelskreis einfaches System und Scriptkiddies: Natürlich ist es schön, wenn ein Portalsystem (nichts anderes ist Joomla) erfolgreich ist. Natürlich ist es schön, wenn viele Leute ein System nutzen. Natürlich ist es schön, wenn es einen Arsch voll (sorry!) Erweiterungen gibt in Form von Modulen, Komponenten oder Mambots/Plugins. Aber was hilft das, wenn jeder Depp (mich eingeschlossen, s.o.) Erweiterungen schreibt, diese als "total geil" erscheinen, aber letztlich die reinsten Scheunentore sind für Angriffe von außen? Da wird ein ext_calender für Joomla angepasst, aber nicht einmal diese eine essentielle Zeile in die PHP-Dateien eingefügt. Das Mambo/Joomla-eigene Forum (Simple/Joomlaboard) krankt seit 2 Jahren rum und ist aktuell wieder Ziel von Angriffen. Nicht falsch verstehen, ich mache den Entwicklern keinerlei Vorwurf, die machen alles in Ihrer Freizeit (die meisten zumindest). Ich mache auch den Usern keinen Vorwurf, denn woher soll Lieselotte Nimsgern wissen, dass das was sie da runter lädt ihre Website zerstören kann? Kann sie nicht. Peter Gibsihr kann es auch nicht wissen. Allerdings kann eine mit großem Trara gegründete Foundation und ein eigenes Quality Assurance Team doch auch mal bitte schauen was da so auf den offiziellen Joomla.org Seiten zum Download angeboten wird. Zumindest die meist eingesetzten Komponenten wären doch mal einen fachmännischen Blick wert. Jaja, ich weiß schon, die machen ja auch alles in ihrer Freizeit. Leute, aufwachen! Keiner, der sich dermaßen für ein Projekt engagiert, hat nichts von seinem Engagement. Seien es Auftragsarbeiten für das System, Schulungen oder was auch immer. Und das ist ja auch richtig so. Was ich aber nicht verstehe, ist dass genau diese Leute ihr Baby so dermaßen unterentwickelt in der Welt herumwatscheln lassen und damit ihre eigene Zukunft außer acht lassen...

    Klar, der MadeMyDay labert wieder klugscheisserisch rum, was macht er denn? Warum engagiert er sich nicht? Einfache Antwort: Weil es keinen Sinn macht diese Strukturen aufzubohren und diese Eitelkeiten zu streicheln um überhaupt mal was zu bewegen. Joomla ist ein Mammut (Kiddies: ausgestorbenes, großes Landsäugetier), jeglicher Versuch - selbst durch Teammitglieder bzw. dem Team nahestehenden Personen - ist kläglich gescheitert aufgrund persönlicher Vorlieben und aus Angst vor Niederlagen in m.E. schwachsinnigen Grabenkämpfen. Dazu kommt die - für mich persönlich entscheidende - Fokussierung der Entwickler auf andere Dinge als sauberen Code. Auf was sie sich fokussieren kann ich allerdings auch nicht beurteilen. Bisher sehe ich nichts. Ach doch: Ein deutsches Backend Ende des Jahres. Glückwunsch.

    Panta rhei, alles fließt. Und deshalb ist es auch nicht schwer, zu einem anderen System zu fließen, bei dem man einen positiveren Eindruck hat, bei dem die Entwickler mehr up to date sind was moderne Systemarchitekturen angeht, bei denen das aktuelle Geschehen im Web beobachtet wird und bei Bedarf zeitnah neue, aber auch bewährte Technologien in das System einfließen, ohne dass alles zehnmal angekündigt und dann wieder verschoben wird. Ich wünsche Joomla viel Glück, denn das wird es brauchen. Als Co-Admin auf Joomlaportal werde ich trotzdem weiterhin aktiv sein, sofern es meine Zeit erlaubt. Denn Joomla hat weiterhin eine Zielgruppe, nur diese ist nicht mehr meine bzw. es ist eine andere geworden. Aber meine Erfahrung schmeiße ich nicht einfach weg. Aber gerade Firmen sollten sich doch eher nach Alternativen umschauen, denn was bringt einer Stahlbaufirma eine Hot-Or-Not-Komponente? Oder hat mich als potentieller Kunde jemals das Wetter in Buxtehude interessiert?

    So, das musste mal raus. Dies geht auch an Interessenten, die Joomla-Templates bei mir anfragen: Nein, ich entwickle keine Lösungen mehr für Joomla. Auch keine Gamesportal-, Partyseiten- oder Singlebörsentemplates.

    Der Blog wird im Übrigen nicht geschlossen, es gibt halt kein Joomlakram mehr. Endlich wieder Filme, Fußball und sonstiges Zeug, das keinen interessiert ?

     

     

    • Like 4
  6. I never submitted the newest iteration of my own business site which already is 3 years online, promoting my webdesign/UI/UX/Frontend stuff. "Just" a Onepager, content managed by PW, usage of D3 for the circles and a completely handwritten gallery at the top. But as always, way more hours went into this as expected ?

    https://siebennull.com

    screenshot of website siebennull.com

    • Like 20
  7. After making more App stuff (UI/UX/SPA) lately I finally made a website again ? It is the Website of the German Association of Osteopaths. Information about the Association, Osteopathy, workshops, search for Osteopaths (Members) as well as a Membership description plus application form.

    Mentionable: 100% 100% 100% 100% Lighthouse score with only 121 KB transferred data/8 requests for the start page. Processwire-wise usage of ListerPro (for managing Members and workshops), Form Builder for application of members. Croppable Image for the images. Managing pages with flexible teaser blocks, built with ASM select and core functionality. Pretty fun project especially because client delivered his part on time and we ramped up the thing in 4 weeks (me working part time).

    https://vwod.de

    1984324527_GemeinsamsindwirstarkMitgliedimVWODwerden!2019-10-1722-06-09.thumb.jpg.133be858fd042ad737bc164c31d15d9f.jpg

    • Like 9
  8. Honestly I have no clue what is happening there. Just out of curiosity, could you try to autoload the module? So in FieldtypePageTableExtended.module try 'autoload' => true (perhaps same for PageTable). Doesn't make that much sense but I have no idea why FieldtypePageTable isn't ready since it is already present. The modal injects its changes via ajax, I guess somehow there could be the problem with your referenced PTE template block. But its just wild guessing.

    • Like 1
  9. Sorry, I never saw that error. 

    Quote

    This only happens if the PTE has a page reference block.

    You mean a page reference field? I also use page reference fields a lot so this shouldn't be the root cause. Do you have an another PTE field active in that template? I know there might be problems if there is more than one PT/PTE field in one template.

  10. I guess you are talking about the

    Quote

    Pri nas si lahko pričeske uredijo vsi željni profesionalnega videza. Gospe, gospodje ali otroci, dobrodošli so vsi, ki dajo kaj nase. Imate željo po pričeski iz fotografije? Prinesite fotografijo in domov boste odšli s popolnoma enako, morda še lepšo. Dobrodošli! ;)

    block and the corresponding detail page.

    You seem to put the text in the pte template. Why not put a page select field to the pte template and put the content of that textblock where it belongs, to the detail page (let's call it "summary"). Assuming your detail template is "detail" and the pte template is "pte_textblock".

    Add a page select to pte_textblock named "linkedPage". So in your pte_textblock template you have access to the fields of the detail page via

    $page->linkedPage->summary and also to the read more destination via $page->linkedPage->url.

     

    Ring a bell? ;)

     

    • Like 1
  11. Could you explain the use case for me? Why are those fields not filled in the details template and you just pull them to the PTE template? So the PTE template for example just consists of a page select field. You select a page and the PTE template renders the information pulled from that page.

  12. Sorry, I don't get it. You three different layouts for PTE, so far so good. Now you wanna do what? The read more link to a different page should point to a different template? Why not? For that URL the detail page template is used, isn't it?

    • Like 1
  13. See it as an alternative to the Repeater Module. For the repeater you define (the same) input fields for each item. The PageTable module is technically pretty similar as both store the items in own pages somewhere. But with the PageTable module you have the opportunity to use different templates as input field sets to choose from. The PageTable module shows those (sub)pages as a table with each page as a row. PTE extends that functionality for rendering the items as they are rendered in the frontend.

  14. Just now, Donald said:

    Question: Can you recommended to use for bigger projects related to the fact that I would like to use it as an "content block builder" or like Lego for the frontend?

    Sure, why not? I am using it on more than ten websites. Some of them have thousands of visitors each day, but that is not the crucial thing since the module doesn't do anything different than the PageTable module itself. It "just" renders the templates also in the admin. There can be some glitches (as this thread shows) but as long it works for you in the admin area, it will also work for your visitors ;-)

     

    • Like 2
  15. It is currently not actively under development but I use it as it is on several sites (I guess a lot of others do so, too). So I am wondering about this line:

    <?php echo $page->pagetableextended->render(); ?>

    The parts are just pages (see PageTable docs) . So with your code you just get an array of pages and PW is so kind to show you which. What you wanna do is:

    <?php 
    foreach($page->pagetableextended as $pe){
      echo $pe->render(); 
    }
    ?>

     

    • Like 1
×
×
  • Create New...