Skip Navigation

[Resuelto] EXTRA Theme and Toolset serious problems

The Toolset Community Forum is closed, for technical support questions, please head on to our Toolset Professional Support (for paid clients), with any pre-sale or admin question please contact us here.
This support ticket is created hace 7 años, 5 meses. There's a good chance that you are reading advice that it now obsolete.
This is the community support forum for Types plugin, which is part of Toolset. Toolset is a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients and people who registered for Types community support can post in it.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

Este tema contiene 56 respuestas, tiene 6 mensajes.

Última actualización por Akhil hace 7 años, 4 meses.

Asistido por: Beda.

Autor
Mensajes
#536509

This is absolutely correct.

It would work.

But we will not prefix a Framework that powers millions of Websites.

This is exactly what the single Theme, that is customising in a special and unique way Bootstrap native classes, should do.

But I will not encourage discussions here.

I forwarded this to Our Developers, who will decide and also get in touch with whom needed.

Thank you for your immense patience.

#536521

There are several more problems in other places on the web because of this.
Another question, Toolset with DIVI does not have these problems?
In your opinion, what should I do?
I ask for a refund or can there be a quick solution from the developers?
What did they tell you?
I have to give a solution to my client as quickly as possible.
Thank you very much for your help Beda.

#536536

All I can say, for now, is that we do deliver a Bootstrap Plugin and we ship it with a native un-customized CSS and JS.

This is standard, there is nothing to do on our end.

If we start prefixing Bootstrap we can as well just create our own Framework, which is not in our plans, and would kind of defeat the whole Purpose of using Bootstrap.

I will update you ASAP with our internal decision.

#536544

But, from what I've seen, your plans are to get Toolset to work with other market themes, and from what I've seen in your blog you want to integrate it fully and in an advanced way with DIVI, so you have to make many decisions.
I await your decision.
Thank you.

#536547

Bootstrap is a framework used (I am not really sure by how many), but they go into millions, of Websites.
enlace oculto

Of course, we will not touch, modify, prefix or other, this Framework. We will ship either Clean vanilla Bootstrap or something else, but now, Toolset is based on Bootstrap.

The idea of adding an Integration Plugin is exactly what I asked our Developer to consider.
But this is not a one day task, it will require lots of work and testing if we do that.

I am fully aware that we need a decision, and I pressed for that, but I also want to point out why we need to do that:
Because a Theme is customising classic and native Bootstrap Classes.
Instead of using "container my-theme", "container" as in native Bootstrap is used.
And probably there are more such cases.

It is unavoidable to create conflicts when you code HTML like that.
The best is to prefix OR to use a Framework that follows, well, standards and delivers all the CSS and JS that you need.
We use a Framework, Bootstrap, for major simplicity of usage and the perfect responsivity.

So, it will require more than my authority to make this happen.
It is not a BUG, which I can debug and suggest a fix.

It is a question of collaboration, support, continued development on an eventual integration, and more.

I will update you here as soon I have precise informations.

Thank you.

#537670

Hi Beda,
Anything new about your decisions regarding EXTRA support?
Thanks for your help.
Best regards,
Francisco R.

#537697

Hi Francisco R.

Beda is not available today. he will get back on Sunday to follow up with you.

Thanks.

#537700

Hi Mohammed,
Ok. Good weekend.
Best regards,
Francisco R.

#537874

Hi Francisco,

Thank you for identifying and pushing for a solution for this problem. You are so right -- I did not realize how bad the issue was. I am likewise in a similar situation: We committed to a project using Extra and Toolset Types and Views and now are so far into the process and close to deadline that eliminating either Views or Extra is catastrophic to project outcome.

Thank you Beda for representing this issue to the development team. We have committed our development practice to Divi and Extra because of the flexibility and efficiencies it provides. We have likewise selected Toolset over its alternatives for similar reasons. The combination has zero overlap and is a win for WP Types, Elegant Themes, Developers and Clients. I hope we can find a short term solution that does not involve choosing one or the other.

Keeping fingers crossed that a short term solution materializes in the next few days.

Thank you.

#537941

Hello Beda and Mohammad,

I understand the position of your developers regarding not namespacing the default bootstrap classes. However, it appears to me that there might be sone occasions where that might be desirable though not necessarily best practice.

I had an idea for addressing the need and sticking with your principle that I would like to share for your consideration:

What if Layouts or Toolset in general provided a single global option for a custom namespace?

It would be blank by default; but would allow developers to assign a custom namespace on a case by case basis. When assigned, Layouts (and perhaps even Views) would apply this custom namespace to the bootstrap class definitions and the generated markup.

This may be harder to implement than it seems; but I thought it was worth mentioning.

Thoughts?

Thanks for considering this (likely uninformed) suggestion!

#537971

@francisco_ramonm5108

Anything new about your decisions regarding EXTRA support?

No, I have not yet heard back from the management.

I will update here as soon I have any news.


@donovand

I hope we can find a short-term solution that does not involve choosing one or the other.

Keeping fingers crossed that a short term solution materialises in the next few days.

This will likely not happen in a few days.

Maybe we will be able to come up with some custom code workaround, but given the size of the issue, this is most likely not possible.

What if Layouts or Toolset, in general, provided a single global option for a custom namespace?

This works (in theory) in PHP.
But what with CSS?
If you namespace the classes, the CSS needs to be addressed with the new class as well.
As far I know, CSS can not hold variables like $custom_namespace-classname.
You can do things like:

div[id^=custom_class] {
    color: #f00;
    /* and so on... */
}

This would then address each class that begins with "custom_class".
But it's self-explaining that this will not work in that case.

I am not 100% sure but I do not think this will work.

Anyway, please be assured that our management, myself and the DEV are:
1. Aware of this issue
2. Generally speaking, we use a native (Bootstrap), and good-practice following standard code
3. We will push and communicate where needed and ensure 100% compatibility with Themes; this is our primary goal.

But I must also inform you that every development needs coding, testing, QA, QC and so on.
This requires time.

We do not send you out there with no help or assistance, but we will require some time on this.

If you are in an urgent situation, I cannot say more than that currently, another Theme should be chosen instead of EXTRA.
This is hard, I know, but I have to inform you about this, otherwise, I would be lying if I say, we will fix this in a day or two.

I cannot state ETA's or make things happen faster; this depends on many decisions that I am simply not in the position to take.

As such, I have to honestly inform you that if you are in a real hurry, waiting for a "fix" might be a too long process.

I apologise that I cannot provide a generic all-in-one solution.
I will push for it though, that I can guarantee.

Let's also not forget that ANY Plugin requiring Bootstrap will provoke the same issue, in conjunction with this kind of Themes.
That is not an excuse; it is just a reminder that we try to solve something that would be avoided if the Theme would simply use a Custom Class.

I am also not trying to put any fault on anyone.

As said we will work on this, and in a way or another, we will provide solutions.

Thank you again for your patience.

#537975

Beda,
It really is not that complicated to solve most problems with EXTRA.
We have been working Vlad and me with each of the problems and the following code that Vlad (Elegant Themes support) has given me solves most of the problems:

.container {
width: 90% !important;
max-width: 1280px !important;
}

.container::before, .container::after {
content: none !important;
}

#et-secondary-menu.nav > li > a:hover, #et-secondary-menu.nav > li > a:focus {
background-color: transparent !important;
}

.extra-woocommerce-details-accordion .ui-icon {
text-indent: 0 !important;
}

As you can see, it's not a complicated code.

You have a problem with the latest version of Toolset, you commented that it would not be necessary to have the DIVI compatibility extension installed, however, if it is not installed, the Woocommerce products are not rendered correctly. This problem you have in both DIVI and EXTRA.
Look at the following ticket:
https://toolset.com/forums/topic/extradivi-and-woocommerce-product-description-problem/

There is another problem with the WPML language selector in EXTRA when Toolset Layouts is active, but this should be very easy to solve for you.
Comment on this ticket:
https://toolset.com/forums/topic/extra-wpml-toolset-and-shopping-page-problems/#post-537799

As you will see, I do not think that it would take much work to incorporate this code or some more improvements to Toolset to solve most problems with EXTRA.

It is simply getting to make the corrections.

Thanks for your interest and help.

Best regards,
Francisco R.

#537976

The code you add alters Bootstrap native Code, overwritig it with Theme CSS.

This means, Layouts will eventually NOT work as expected and neither will Views features like the Bootstrap GRID, because you now hardcode Bootstrap responsive elements to be "stiff" (not responsive)

This is like not using Bootstrap at all.

Those are not corrections, those are hacks that alter Bootstrap Classes.
I am not sure if I explain myself correctly, but if you alter a native Bootstrap CSS rule, it is not anymore native Bootstrap and Layouts or Views will eventually have issues in responsivity as example.

The other issues you mention are not related to this ticket.

This ticket is related to issues with EXTRA and Layouts, where once Layouts is active (or let's be precise, as soon Toolset Loads Bootstrap) the design of the Theme is altered because now native Bootstrap takes over.

This 2 code changes seem different:

#et-secondary-menu.nav > li > a:hover, #et-secondary-menu.nav > li > a:focus {
background-color: transparent !important;
}

.extra-woocommerce-details-accordion .ui-icon {
text-indent: 0 !important;
}

Those are not Bootstrap classes. They are namespaced, as far I can see, and should not be affected by Toolset Bootstrap.

But let me state again, our Developers and manager are informed of this.

Solutions and/or statements will come.

I can not push this right now - and I can not solve this right now in our plugin, in a satisfying manner.
It is weekend, and the management will be back monday and hopefully let us know more.

I also added the other 2 tickets you mention to the internal tracker to be looked at ASAP.

Thank you for your patience, once again.

#538046

Thank you very much for championing this issue and setting realistic expectations Beda.

Can you also add this Extra/Layouts ticket (https://toolset.com/forums/topic/problem-with-activating-and-displaying-full-width-layout-with-diviextra-theme/) to the priority list for the devs looking at the issue - If you believe it is the same core issue?

Thanks!

#538057

I will check that ASAP.

It's late, after midnight here, but I just had a small idea.

In Toolset > Settings > Layouts (you must activate layouts for that) you will see a setting for container widths.

Those go from full width to several other settings.

Can you check if it makes a difference when you choose "full width" there?

It may not be absolutely perfect but I could guess, you could come much closer to the EXTRA design with this setting!

I apologize for not trying this myself now, as said it's late and I'm actually on a mobile, where I don't have MAMP local server access, otherwise I would never ask you to test this without having first double checked.

But given the urgency of this, I think it's worth a shot?

Please let me know about the results, if you don't have time, I'll do those tests myself asap.

Thank you all once more for the patience, and please enjoy the weekend!

El foro ‘Types Community Support’ está cerrado y no se permiten nuevos debates ni respuestas.