[Support System] Support System plugin is not displayed correctly in Divi Builder

Support System plugin is not displayed correctly in Divi Builder.

  • Adam Czajczyk
    • Support Gorilla

    Hello GiaNet Media

    I hope you're fine today!

    I tested it on my test setup but didn't experience similar issues. It's possible then that either some other plugin is involved or it is related to some specific setting of either Support System plugin or Divi theme or the site itself.

    I would like to take a closer look at this so would you please enable support access to your site for me? To do so, please go to the "WPMU DEV -> Support" page in your site's back-end, click on "Grant support access" button there and let me know here once it's done.

    I'll then check the site in order find out what's causing this and how to fix it.

    Best regards,
    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hi GiaNet Media

    Thank you for granting access.

    I've checked the site and while I could see the issue there, I still wasn't able to replicate that on my end with Divi until I actually imported that specific layout from your site to mine. Once I did that, the same issue started to happen for me.

    Upon further investigation I found out that for some reason the shortcode output seems to be affecting the Divi-generated column structure. This is a bit weird as at the same time it doesn't seem to cause any syntax errors in HTML markup - like for example "unopened/not closed" HTML tags or similar. Still though, the culprit isn't e.g. CSS or JS but the "broken HTML structure". I admit that I'm not sure why this happens yet, since I only could replicate this with layout taken from your site.

    However, it seems that there's a "fix" for that that I already applied to your site: adding an opening "div" tag right before the support system shortcode "fixes" HTML structure and the sidebar gets back to it's proper location.

    Could you take a look please at that now? The sidebar should now be in place.

    Best regards,
    Adam

    • GiaNet Media
      • Site Builder, Child of Zeus

      Hi Adam,
      Thanks for the reply and the solution.
      So, the issue is too strange.
      I have created a new page, with a simple new layout, http://assistenza.inonda.tv/apri-ticket-2/, but I have the same issue too...
      But, when I load the Visual Builder, all work perfect...

      In this site are avaible only the network plugin. I have deactivated all network plugin, but the issue is always present...

      I added the <div> also in the Open Ticket page, http://assistenza.inonda.tv/apri-ticket/, and it work...

      So, you think that the issue is generated by some Divi Builder bugs, or by the Support System plugin bugs?

      Can you ask to the Support System plugin developer?

      Thanks

  • Adam Czajczyk
    • Support Gorilla

    Hi GiaNet Media

    Thanks for this additional information.

    So, you think that the issue is generated by some Divi Builder bugs, or by the Support System plugin bugs?

    Can you ask to the Support System plugin developer?

    We've tested it more and we're still thinking that it's somehow related to the specifics of your setup (or it's something that is in the plugin but only reveals itself in certain environment).

    To be honest, I'm not quite sure how to troubleshoot it further. It would be best if we could actually work on this specific site but I understand that it would interfere with what you are doing there (we might need to switch plugins/themes on and off, make changes to layouts and configuration and so on). I was thinking that maybe it would be possible that you set a staging site where we could test it fully? By staging site I mean mostly a "one to one" copy of entire setup rather than a sub-site on the mulitisite. If you could set that up and grant us support access, that would be great and really helpful.

    If not, we'll try to work with what we got available though :slight_smile: Just let me know please.

    Best regards,
    Adam

  • GiaNet Media
    • Site Builder, Child of Zeus

    Hi Adam,
    sorry for the delay.
    I'm trying to create a staging site: http://supportest.inonda.tv
    I have created a new subdomain, installed WordPress, cloned the plugins and themes folder, and cloned the upload media folder related to the cloned subsite.
    With Snapshot Pro I have created a DB backup.
    When I try to restore it on the subdomain about the staging site, the restoration stop at 7%, returning the "504 Gateway Time-out" message.
    it stops before restoring wp_options table.

    What should I do?
    Now I have enabled the grant access!

  • Adam Czajczyk
    • Support Gorilla

    Hi GiaNet Media

    Thanks for getting back to me!

    The error suggests that either the wp_options table is somehow "broken" (it might e.g. include some "uncommon" data that breaks import) or it's actually simply too big and server times out because it's not able to complete import process in time.

    I understand, though, that this is on the supportest.inonda.tv site and that's a staging site so I could work on it safely without affecting the live site right? The snapshot backup file is also already uploaded to that site?

    If so, I think I should be able to restore it "manually" form the backup file. However, I'd need a full access in such case - support access doesn't give me access to all the necessary tools. Would you be able to provide me with direct access credentials to the site and server then? I'm referring to the staging site of course :wink:

    Note: Don't leave your login details in this ticket.
    Instead, you can send me your details using our contact form https://premium.wpmudev.org/contact/#i-have-a-different-question and the template below:

    Subject: "Attn: Adam Czajczyk"
    - Site login URL
    - WordPress admin username
    - WordPress admin password
    - FTP credentials (host/username/password)
    - cPanel credentials (host/username/password)
    - Folder path to site in question
    - Link back to this thread for reference
    - Any other relevant urls/info

    I'll then try to restore the site manually and after, hopefully, it's set I'll get back to that initial issue that we discussed here.

    Best regards,
    Adam

  • GiaNet Media
    • Site Builder, Child of Zeus

    Hi Adam, thanks for the reply.

    The error suggests that either the wp_options table is somehow "broken" (it might e.g. include some "uncommon" data that breaks import) or it's actually simply too big and server times out because it's not able to complete import process in time.

    So, if you find what is broken in the wp_options table and you have a solution to adjust the table, can you send me the solution to apply it into the main multisite database? I think that the broken is present in all subsites database table.

    I understand, though, that this is on the supportest.inonda.tv site and that's a staging site so I could work on it safely without affecting the live site right? The snapshot backup file is also already uploaded to that site?

    Yes, the supportest.inonda.tv site is a staging site, not in the multisite network, and you can do all you need to find the issue. Yes, there are 3 snapshot backups uploaded to that site. I have tried to test it 3 times.

    Now, I will send you all the credentials you need by email.

  • Adam Czajczyk
    • Support Gorilla

    Hi GiaNet Media

    Thank you for additional info and for providing credentials.

    It seems that there might be some sort of "resources limitation" on server as I not only wasn't able to restore the site via Snapshot but also after manually importing all the tables I wasn't even able to run a standalone script (not wp plugin) to update urls/paths in the database - it also was breaking after some ajax calls. It's a bit alarming that it happens at the same point but I think we could get to that later if necessary.

    Anyway, I did restore the database manually and I manually updated the most important URLs in the db. I am now able to open site's front end and also login via front-end using login and password that you shared with me (the users table wasn't included in the snapshot so I kept the one from the staging site). I'm slightly confused though because being logged in at front-end now I don't see any regular user links (like profile llink, dashboard link etc) in admin toolbar - just like the user wasn't admin, even though it's set as admin - and whenever I attempt to visit wp-admin area, it's either telling me that I'm not permitted to do so or puts me in to the redirect loop.

    I'm writing this because I wanted to ask you for confirmation if all the necessary plugins were also transfered to that staging site (backup only contained databases) and if there were/are any "non-standard" settings on the original site such as some custom "access control" or custom user roles or something like that. Let me know please and I'll work on it further to make that staging site fully usable and after that I'll get back to the original issue.

    Best regards,
    Adam

  • GiaNet Media
    • Site Builder, Child of Zeus

    Hi Adam,
    Thanks for the reply.
    So, I think that there are no limitations to the server, I have bought the hosting with the highest resources... I think we could get to that later, too.

    I'm trying to access into the site with my credential and I have the same issue...
    Yes, I have transferred all plugins (not only the necessary) to that staging site, and the backup contains only databases about all plugins used in the original site. One of the plugin used in the original plugin is the Ultimate Membership Pro, where there are some non-standard" settings about some "custom access control" for specific pages. But the homepage would be visible to all users... or the registered users would be redirect to the Support Page...

  • Adam Czajczyk
    • Support Gorilla

    Hello GiaNet Media

    Thanks for additional information!

    I think we're good to get back to the initial issue now as I was finally able to make the staging site work. Let me explain though what was happening :slight_smile:

    There were actually two issues after import/migration. First was something that I didn't notice at first: since the site was actually "extracted" from multisite after manual import there were some small inconsistencies in some user-related tables naming that used a wrong prefix. The prefix would be fine on Multisite install but not on a single install. Once I found that, I was able to adjust that and that fixed the login issue.

    The second issue is with that _options table. I initially mentioned that there's either some sort of limitation on server resources or the table is broken, as I wasn't able to run any update script on it. Finally though I was able to update URLs in it using Better Search Replace plugin that allows settings smaller "page size" ("page" is not the WP page in this case, it's related to the "db query data size") which suggests that there's some row that might simply be a bit "too big" to work with "standard settings" during regular update procedure - it just breaks the ajax query. So, after all it's not quite a bug or a "broken" table, more of a certain limitation of the data size.

    The bottom line is: at this moment the site seems to be fine so if you could please clear cache in browser and then try to login with your account and check if everything's working, that'd be great. If you can confirm that the site is "ready", I'll move back to the initial issues on work on this and hopefully we'll be now able to sort that out :slight_smile:

    Looking forward to hear from you,
    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hi GiaNet Media

    Thank you and I'm sorry for keeping you waiting again, it's been quite "hectic" here recently.

    Getting back to the issue. Thanks to that staging site I was actually able to finally replicate this, even on my own setup. I also did a number of tests on my but to be honest I can't find why this is happening. I mean, I can still confirm what's causing this - as in my earlier posts it's about that "div" tag - but I couldn't drill down to the "core" of the issue.

    I've asked our developers for help. I took a liberty of providing them with access to your test/staging site in case they needed to do some additional checks there so I believe they'll be able to find out the permanent solution for this.

    We'll update you here as soon as we know more.

    Best regards,
    Adam

  • Konstantinos Xenos
    • Rubber Duck Debugger

    Hi GiaNet Media ,

    Sorry for the late reply. I've made a change into one of the plugins files and everything should be as supposed to now as far as I can tell, but please be kind and send me a confirmation as well :slight_smile: .

    The code change is in file /plugins/incsub-support/inc/classes/shortcodes/class-abstract-shortcode.php -> Lines 12 - 13

    From:

    echo '<div id="support-system">';
    ob_start();

    To:

    ob_start();
    echo '<div id="support-system">';

    I can't be entirely sure if this will be on the upcoming release, so please note this change just in case you'll have to re-adjust this particular file in the future. If you're not comfortable changing code, you can always reply to this ticket again and I can change it for you if an update happens and this change is lost.

    Regards,
    Konstantinos

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.