Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Joss

  1. 9 minutes ago, ryan said:

    @Joss Good to see you here! Lots of emoji/emoticons require 4 bytes and thus the UTF8MB4 database charset. This is something you can select at install time. You can also convert an existing DB to use it too, but I think you have to export the SQL, create a new DB and import it, replacing any "charset=utf8" with "charset=utf8mb4" in the SQL dump. This DB charset is needed whether using TinyMCE or any other kind of text field, if you want the emojis support. Though if you are already using utf8mb4, let me know, as it's always possible there's a bug I need to resolve too. Btw also check out TextformatterEmoji https://processwire.com/modules/textformatter-emoji/

    Hi Ryan! Good to see you too.

    This is on my local machine using Laragon running MySQL 8.

    I ran the query:

    SELECT * FROM information_schema.SCHEMATA S WHERE schema_name = "aelwenjones";

    And it returned:

    SCHEMA_NAME			aelwenjones
    DEFAULT_COLLATION_NAME	utf8mb4_general_ci

    But if on phpMyAdmin I select one table and click on show create I get:

    CREATE TABLE `field_article_text` (
     `pages_id` int unsigned NOT NULL,
     `data` mediumtext NOT NULL,
     PRIMARY KEY (`pages_id`),
     KEY `data_exact` (`data`(250)),
     FULLTEXT KEY `data` (`data`)


    I notice on my host, however, that most of my schemas are latin1, so I need to make sure they aren't, as it were, for this table.

  2. This is my hanna code

    			if($ad == "random"){
    			echo "<div class='footad'>";
    		    		echo $product->amazon_paste;
    		    echo "</div>";


  3. This is the error I am getting:
    Fatal Error: Uncaught Error: Class 'TextformatterHannaCode' not found in site/modules/HannaCodeHelper/HannaCodeHelper.module:111


    Fatal Error: Uncaught Error: Call to undefined function wire() in /site/assets/cache/HannaCode/inline-ad.php:5 Stack trace:


  4. 26 minutes ago, teppo said:

    It can result in a lot of data being stored in the database. From your earlier post it sounds like that could be at least one reason why your database takes so long to back up.

    In my experience a ProcessWire database taking very long to migrate/backup/etc. usually means that the site has at least one, and possibly more than one, module that keeps storing data without limits (or with very loose limits). Jumplinks' 404 monitor is one module/feature that can do this, while ProcessChangelog and ProcessLoginHistory are other typical culprits.

    I believe Jumplinks has an admin tool for checking the number of stored 404 hits and clearing them, so it might be a good idea to check that, just in case ?

    Hi Teppo!

    I turned it off and cleared it. I notice in the notes it says that it is limited to the last 100 only. I don't know if that means it only displays the last 100 or only keeps the last 100.

    But the entire database is not very big.  5000 rows total? A couple of megabytes? It is still a bit of a puzzle. Kualo couldn't see an obvious reason. I also got this with another small site that doesn't have jumplinks installed.

    HOwever, I think the logs have gone nuts. I am getting this error about not finding the Hanna Code text formatter.  I am just updating Wire because of another error (not displaying fields or templates in setup). 

  5. Hi, psy

    It's the same on all themes. I have just noticed this in the Chrome console. No idea if it has anything to do with it, but I am not getting it on sites without the problem:

    Uncaught SyntaxError: Unexpected token u in JSON at position 0
        at JSON.parse (<anonymous>)
        at HTMLDivElement.<anonymous> (InputfieldTextTags.min.js?v=1-1619298240:1)
        at Function.each (JqueryCore.js?v=183:2)
        at init.each (JqueryCore.js?v=183:2)
        at InputfieldTextTags (InputfieldTextTags.min.js?v=1-1619298240:1)
        at HTMLDocument.<anonymous> (InputfieldTextTags.min.js?v=1-1619298240:1)
        at l (JqueryCore.js?v=183:2)
        at Object.fireWith [as resolveWith] (JqueryCore.js?v=183:2)
        at Function.ready (JqueryCore.js?v=183:2)
        at HTMLDocument.A (JqueryCore.js?v=183:2)


  6. UPDATE - Installing the dev from today seems to have solved the issue

    On the sites I have upgraded to 175, when I click on Setup->Templates->Template name, I just get nothing as shown in the pic below.  Well, it says I am editing it, but there is nothing shown even though the pages are working fine.

    The same happens when I click to edit a field

    This is happening on both dev sites on my local set up and on live sites. When I updated (from 168, I think), I also updated a pile of other things like ListerPro, page actions, a couple of pro fields. Not that I think they are anything to do with it, but I throw them into the mix in case.

    It is the same in the Ukit and default themes, so it's not a theme issue.

    Any clues? Have I missed an important announcement somewhere?

    I was about to start on a new site, and I can't!




  7. 8 hours ago, adrian said:

    Does the upgrade work OK if you just tell it not to backup? I don't honestly see the point in the backup while upgrading - PW upgrades almost never make changes to the DB anyway.

    Adrian, I have confirmed it works without hitting the backup button. ? 

  8. I have had an email from support at Kualo, and I must give them a positive shoutout. They really have gone into this in detail. Brilliant.  Anyway, this is what they have said (which I have slightly redacted)


    Hi Joss,

    Thanks for the patience,

    We have further analyzed the case with the team. Debugging the process carefully, the error occurs after 1 minute 40 seconds. Viewing the Timeout values of the database is set by default to 2 minutes, which should be enough.
    Checking the base process we see that in fact it is not performing any action and remains in sleep:

    | 2316866 | PASSWORD | localhost | PASSWORD| Sleep | 78 |

    The execution that delays and cuts the connection is a PHP process:

    ps -aux | grep XXX
    XXX 3129 94.3 0.0 547792 104252 ? Rs 20:56 0:02 lsphp:ngb/public_html/ABCDEFG.com/index.php

    That by making a trace we see that it does the following:

    strace -p 3129
    rite(10, "\nINSERT INTO `process_jumplinks_"..., 256) = 256
    write(10, "\nINSERT INTO `process_jumplinks_"..., 268) = 268
    write(10, "\nINSERT INTO `process_jumplinks_"..., 239) = 239
    write(10, "\nINSERT INTO `process_jumplinks_"..., 229) = 229
    write(10, "\nINSERT INTO `process_jumplinks_"..., 232) = 232

    Pushes data into a thread, possibly the database dump.

    By way of tests, we have applied an unlimited boost to the account and raised the execution times to more than 20 minutes and even then the process fails. Investigating a bit the error specifically of Processwire I found a quite old thread but very similar to the current function:


    Being the current parameters of the resources, we could estimate that it is a kind of bug in the execution of the backup function of the processwire.
    In this case, I think that the post you made in the forum is the most appropriate to determine if it is a bug or if there is an appropriate fix.

    Does that throw any light on the situation for anyone?

    • Like 1
  9. 9 hours ago, wbmnfktr said:

    I had very very similar entries in my logs on not that cheap hosting providers over in Switzerland and here in Germany ... I can't remember all the details but the end-result was... their database servers where more crowded than any Walmart on a Black Friday. Those servers were packed with users that even minimal resources couldn't be applied to each and every client.

    Thanks, wbmnfktr. I use Kualo and they are very robust. I have used them for years.  They are being very helpful trying to work out what is happening.  The resource use on the particular server is quite low. 

    8 hours ago, adrian said:

    How big is the DB for the site? The backup mechanism built into the upgrade process (and also via ProcessDatabaseBackups) doesn't handle large DB's very well at all. I actually recently requested that Ryan consider changing the latter to use native backup tools (ie mysqldump) to avoid this.

    Does the upgrade work OK if you just tell it not to backup? I don't honestly see the point in the backup while upgrading - PW upgrades almost never make changes to the DB anyway.

    Hi, Adrian.  I am going to try upgrading without hitting the backup button on a different site (I want to leave the site we are messing with as is till I work out what has gone wrong).  But the DB is very small. Just 61mb.

  10. HI Robin

    I can back up with Phpmyadmin okay.  I am not sure what SessionHandlerDB is, unfortunately! There wont be any large tables - the site is not that big. Also, I have updated this site before without any issues.

    What about the list of errors the host sent to me? (up a couple of posts).  Does any of that give a clue?

  11. Hi Horst.

    Trying to upgrade to the current dev. 

    Although I could do a manual upgrade, that doesn't solve the problem as to why this is going wrong in the first place. I have tried on two different installations which I think are on slightly different PW versions.

    The upgrade module is up to date on one and not on the other. So I don't think it is that as such.  There is a conflict somewhere, and it is recent. I upgraded a couple of other installations on the same server a couple of weeks ago without a problem.

  • Create New...