....I'm so lost now..

[Tohsaka Rin]

Yeah, hence using the censor words area would just be very tedious.

I figure to just wait for a bit and see what Shrike or someone else says about it since they did mention converting the attributes.

Until then, I have just been focusing on other aspects to work on in the meantime to address other issues that I can resolve by searching around on the forums for their various fixes or plugins.

Will check back later.

[Tohsaka Rin]

Bump. I still need help on a lot of things in order to get a direction on how a lot of these can be fixed.

Everyone that I know is still freaking out because no one is willing to make a style tag converter and many of the sites that I had helped get started are at their wits end. A few even decided that proboards is a lost hope and began swapping to jlink or other forum applications that will support it.

With the amount of threads my site is getting, at the average of 3 posts per week by near 70 characters, the total number of posts using these things is getting overwhelming to deal with.

[VS Admin]

Hi,

Is changing [style=...][/style] to [div style="..."][/div] all you need?

If that will fix this issue, I'm sure we can add it to our converter.

[Kami]

VS Admin - there's also the issue of changing the tags for Eton's "Enhanced UBBC Tables", which uses [atrb] and [cs] and [rs]. CS/RS function identically to determining a column and row span, but atrb ranges from [atrb=width,xxx,true] to [atrb,border,0,false] or what have you.

[VS Admin]

Dec 27, 2012 14:31:19 GMT -8 Kami said:

VS Admin - there's also the issue of changing the tags for Eton's "Enhanced UBBC Tables", which uses [atrb] and [cs] and [rs]. CS/RS function identically to determining a column and row span, but atrb ranges from [atrb=width,xxx,true] to [atrb,border,0,false] or what have you.

That sounds a bit more complicated to fix with a patch from us. I don't think it should be too hard for any of these code-swapping codes to be updated to v5 if a coder has the time to look through it.

[Tohsaka Rin]

Yeah that is pretty much all that everyone is asking for, a converter.

It will resolve the entire issue and save a whole heck of a lot of frustration for lots of members.

[eton]

It may look like a simple conversion process on the surface but there are underlying factors that need to be considered

• Standards Mode: All v4 Enhanced templates were created and expected to work in v4's quirks mode which compared to the standards mode in v5 is far more forgiving of erroneous markup. A sampling of existing templates taken from various RPG forums revealed numerous flaws which may have been overlooked in v4 but would fail in v5 if not fixed. A commonly seen one would be the omission of the hash mark when specifying color (e.g. FFEEDD instead of #FFEEDD) which the browser would ignore as invalid in v5. Another common one would be adding "px" when specifying the value for an attribute, such as width, which expects a percentage or simple integer (no units, e.g "50" not "50px"). These and other small errors would mean that the templates would need to be edited to fix these flaws which would defeat the purpose of requesting a conversion plugin in the first place. The alternative would be to instruct the plugin to look for these flaws and attempt to fix them prior to conversion, this is however not ideal since all cases would not be accounted for, just the more common ones.
  Numerous other discrepancies between standards and quirks exist such as: font properties except family not inherited by tables in quirks, table border color not determined by foreground color in quirks, empty cells are hidden by default in quirks, etc.
  All these present special cases that need to be addressed and is far from being an exhaustive list.
  
• Unsupported Properties: There are certain attributes and styles such as box-shadow that Proboards will reject which means acting merely as a simple "convertor" would not be feasible, the plugin would also need to have knowledge of these blacklisted properties and leave them unconverted with a throwback rendering component to handle these nonconvertible properties. Dynamic detection through before/after comparison looks trivial but there's the question of unnecessary AJAX communication to get this accomplished. The alternative would be to give the plugin a list of properties to look for and not convert them, this is however not ideal since all cases would not be accounted for, just the more common ones.
• Style Tags: The sampled templates also revealed that [style] tags are inexorably intertwined with the enhanced Tables Code. At some point someone threw caution to the wind and began creating templates that required both codes, so having one without the other would mean many templates would not properly render. If VS Admin gets them to do a simple conversion of [style] tags that would help but still would not address the cases of blacklisted or unsupported css properties. Also if the template uses the more advanced features available in the more recent style codes such as the ability to define css rulesets rather than just inline styles then the Proboards convertor would not help. Those advanced features present the opportunity for abuse and I suspect would not be allowed on v5.
  

[Tohsaka Rin]

Well I always use "px" and hashtags for my hex-coded fonts. I never used any box-shadow so those two upper parts are really nothing I have to worry about. The main issue that comes to mind when I am discussing a conversion for the enhanced table properties is the ability to remove a border from table boxes (to me this one is a must) and the conversion of [style=] to

.

Those are the two concerns I have; as I use this prominently to set widths of forum templates so that they do not overlap or push the forum window past it's designated space ([atrb=border,0px,true][atrb=width,532px,true]) and the obvious [style=] tags.

The rest of that appears to not be much of a concern.

[Chris]

Jan 4, 2013 10:21:52 GMT -8 Tohsaka Rin said:

Well I always use "px" and hashtags for my hex-coded fonts. I never used any box-shadow so those two upper parts are really nothing I have to worry about. The main issue that comes to mind when I am discussing a conversion for the enhanced table properties is the ability to remove a border from table boxes (to me this one is a must) and the conversion of [style=] to

.

Those are the two concerns I have; as I use this prominently to set widths of forum templates so that they do not overlap or push the forum window past it's designated space ([atrb=border,0px,true][atrb=width,532px,true]) and the obvious [style=] tags.

The rest of that appears to not be much of a concern.

Your reply gives concrete examples of what I was talking about since you're adding a unit on a width ATTRIBUTE when the HTML specs say the attribute should be an integer or a percentage. If you somehow feel an uncontrollable compulsion to specify a unit of "px" then set it as a  style ([atrb=style,width:532px,true]). The point is although that incorrect construct was allowed to pass in v4 it would more likely be challenged either by the browser or the PB parser in the stricter doctype environment of v5.

As stated that was far from an exhaustive list but rather a sampling of commonly seen flaws to illustrate the various obstacles a plugin would need to navigate in order to produce a fairly seamless transition. It may not be a concern for you but by no means does that not make it a concern, so checking them off as if they don't matter or somehow not applicable to you is counterproductive. A plugin after all would need to account for all but the most unlikely cases, not just your case. If you take a look around at templates in the wild authored by others you'll find flaws or assumptions that are forgiven/ignored/auto-corrected in v4 by the browser since it is quirks mode but definitely would not be in v5, which means what looked "perfect" in v4 would look "weird" or "don't work" in v5 (I can just see the deluge of complaints now).

I've written a preliminary plugin that does the conversion but because of the aforementioned unsanctioned AJAX calls (to determine what Proboards accepts and what should remain in the realm of pseudo-tags) it is not compliant with coding guidelines. But more importantly the following shows screeners first of a rendering in v4 environment and then that exact same template rendered in a v5 environment. Even without errors there exists what appears to be a mountain of difference between standards and quirks for a simple conversion plugin to cover.

Word Count plugin has experimental convertor

[Tohsaka Rin]

I am trying to figure out what you are getting to. You forget, I am not a coder in any way, I do not really know anything about ajax or how to use any of this div stuff. I have managed to make the templates that I have merely out of testing codes.

It took me a while to read over your post several times to try and understand it. I do apologize for this.

After reading what you posted about all I was able to glean from that is that I have to have ([atrb=style,width:532px,true]) that. The thing that I am wondering about is the fact that in V5 "ATTRIBUTE=" does not even exist in any of the scripts for UBBC. Nor does STYLE because they removed all of that. So regardless if I were to put atrb=STYLE before some of it - it still will not work because there still is no conversion plugin for changing style tags to div tags, nor anything to support the old Enhanced UBBC function that allowed you to use attribute in the first place.

So regardless if I were to stick "atrb=style" into the "atrb" area it still won't solve the overall issue - as none of that even exists in a plugin or the normal coding for the forum itself to support any of this in the first place.

---

Quick question:

Just to clear this up, I have to now use [atrb=style,width,xxxpx,true] because I no longer can use [atrb=width,xxx,true] or [atrb=width,xxxpx,true] or does [atrb=width,xxx,true] still work?

(Again, I know that atrb won't work at all in V5 since both it, and styles, have to be converted.)

---

The huge dilemma everyone is facing is having to edit thousands of threads. We are all trying to figure out the swiftest coarse of action to resolve ALL OF THIS with a much larger fix that will only mean we have to edit some small parts here or there while something else handles the bigger chunk of what we are now FORCED to deal with.

When discussing this with other forum owners we feel a bit kicked in the teeth after years of using what we have and building up tens of thousands of posts and threads and now forced to change ALL of them because the code is changed. THAT is the very real issue we are all trying to solve in such a manner that won't piss everyone off or force years of work to be lost at a spit in the bucket.

We are all basically forced to have all of this resolved in 3 months or told to GTFO because we can't fix our work.

And /that/ is harsh.

[Kami]

I think it bears repeating that the "Enhanced UBBC Tables" were not a ProBoards-created code. Eton (the person above you) was the one who created it as a workaround to v4 / v4.5's limitations in UBBC, and that ProBoards really isn't responsible for what codes you put on your forum. To be entirely fair to them, they have listened to a lot of user feedback and catered a lot of v5 to those requests - I don't think it's "harsh" that this code was overlooked, considering everything else they've done, and considering the fact that it's not impossible to change to make compatible with v5, just time-consuming. There is a difference, and that is the risk you run when you use 3rd party codes.

---

To continue - basically, what Eton is trying to say, in layman's terms, is that a converter is going to be a pain in the arse. This portion specifically:

"As stated that was far from an exhaustive list but rather a sampling of commonly seen flaws to illustrate the various obstacles a plugin would need to navigate in order to produce a fairly seamless transition. It may not be a concern for you but by no means does that not make it a concern, so checking them off as if they don't matter or somehow not applicable to you is counterproductive. A plugin after all would need to account for all but the most unlikely cases, not just your case."

A plugin for the Enhanced UBBC tables would have to account for common mistakes such as, but not limited to defining the width attribute with px. Eton is saying that a plugin cannot cater just to your needs, but to the needs of everyone who would use the converter plugin, so you cannot be dismissive of the other concerns he brought up because they are not relevant to your particular situation. Basically, there are a lot of mistakes people make when using the Enhanced UBBC code to make tables that the current software ignores but v5 does not, and the plugin will have to account for nearly all of them.

So while, yes, a converter is likely possible it is not a 'simple fix' for what you want, nor is it 'easy'.

Edit;; also this: "I've written a preliminary plugin that does the conversion but because of the aforementioned unsanctioned AJAX calls (to determine what Proboards accepts and what should remain in the realm of pseudo-tags) it is not compliant with coding guidelines."


^ Basically, the plugin as-is uses something that ProBoards doesn't allow in terms of coding.

---

To answer your question, [atrb=width,xxx,true] works. What Eton is saying is that defining a width value needs ONLY integers (0-9), and you do not need to specify the unit of measure. If you want to define the unit of measure, you'll need to use [atrb=style,width:xxxpx,true].

[Tohsaka Rin]

Ok, so the current atrb that I am using is fine. I was pretty confused on it since the way that it was worded made me double-think what I was doing was incorrect for some odd reason.

Someone had told me that atrb was not going to be working any more; which left me trying to figure out "why" and "how" to change it. If atrb is fine the way it is then I won't be too worried about that whatsoever. I only use it to take the hideous borders off the tables and make the posts not spread the page out.

I wouldn't have minded if I had to just do minor edits to some of the templates if it somehow required me to put 'px' in. I know that half of the plugins I have for V5 require the unit of measurement or else they do not function. Which, I will point out, is pretty silly because several of those plugins also do not want you to use it at the same time.

To me, I had just always been use to either setting it as a numerical value, without using px (because it is the only measurement for numerical sizes) or percentages.

Sorry if that took so long to figure out. I just rather be safe than sorry.

If nothing more is required for the tables to function (on their own) then that is cleared up and my only concern is the style issue which I just have to hold tight and wait for that to be done sometime.

---

Thanks for the help so far. Upgrading things is really frustrating. Hopefully soon people will have time to answer what few questions I threw out there to their current plugins.

Several of them are not working properly (side tables) and the dynamically tabbed table.

Anyone have any idea how to stop/get rid of the category padding/gradient...I tried to stick images in place of the category text name and it just does not work right at all. It spreads it all out with gradients. I also cannot seem to move the forum jump area under the news fader. It keeps spanning the whole page and is hideous. The thing is taking up a lot of space and should be the same size as the news feeder, in the same area (if not below) the news feeder.

Any time I try to move the css or mess with it, it just puts it at the top (or bottom) of the entire page.

I will try working on more of it tomorrow. Two months will end up going by so fast that I worry about deadlines.

[Kami]

Okay, I'm a little confused I have to admit.

A few posts up, you said, "Well I always use "px" and hashtags...". This s wrong if you are using this atrb tag: [atrb=width,xxx,true]. Do not put "px" at the end of the number in the xxx spot -- the width attribute only takes integers (0-9, whole numbers) and adding 'px' at the end of it is a bad habit and incorrect markup.

Someone had told me that atrb was not going to be working any more; which left me trying to figure out "why" and "how" to change it. If atrb is fine the way it is then I won't be too worried about that whatsoever. I only use it to take the hideous borders off the tables and make the posts not spread the page out.

Okay, I don't know what you're referring to here. Are we talking about v4.5, or v5? If it's 4.5, then the [atrb] tag still works provided you have the appropriate "Enhanced UBBC Tables" in (this is what I thought you were talking about).

If we're talking about v5, then the [atrb] tag has not been included with the upgrade.

As I explained before, the [atrb] tag is not a real tag, it is a workaround for v4.5, and the variables within it (including mistakes people make, as Eton pointed out) will make a converter incredibly difficult to create. You do not have to have borders in tables / can define width now as you can see below:

width: 500

Row1, Colspan 2
Row 2 column 1	Row 2 column 2
Row 3 column 1	Row 3 column 2

But again, you will have to change all of that manually, which brings us full circle to your request for a converter. Which, again, is not as simple as you're thinking it will be. It looks like Eton is working on one, but it (a) appears it is non-compliant with ProBoards coding guidelines, and (b) looks like it's in very preliminary stages, since he says he's just trying to see which pseudo-tags still work, and which will no longer be needed.

The long and short of it is I have to reiterate what I've been telling you since the beginning. A plugin to make all the pseudo-markup from the v4.5 "Enhanced UBBC" code applicable in v5 is possible, but I still wouldn't hold your breath for one coming out prior to the release of v5 (if at all, considering).

---

To answer your other questions:

Several of them are not working properly (side tables) and the dynamically tabbed table.

If you have plugins that are not functioning properly, post in the individual plugin threads for each detailing exactly what you expect it to do, and how the plugin is not meeting your expectations. "Not working properly" doesn't really give anyone much to go on, and you'll likely get a quicker response if you post in the plugin thread (and likely support from the creator themselves).

Anyone have any idea how to stop/get rid of the category padding/gradient...

For the gradient, if you go to the themes > visual editor portion, Select Body (Content), expand the Containers > Title Bars dropdown. There is a section under 'background colour' that says 'background image'. Click the dropdown and select the first option ("none"), which will remove the gradient.

For the spacing, I looked for a moment in the CSS / template section but couldn't find it (I didn't look very hard, however, as I am currently attached to my TV and it's not great for coding). You might want to check in the Template Modification board's sticky of current modification posts to see if someone's already done it, and if not, post a request there.

I also cannot seem to move the forum jump area under the news fader. It keeps spanning the whole page and is hideous. The thing is taking up a lot of space and should be the same size as the news feeder, in the same area (if not below) the news feeder.

Just to clarify we are talking about the Nav Tree, correct?



I looked at my test forum and I couldn't find a forum jump. If I'm missing something let me know :]

[Tohsaka Rin]

I.  UBBC Table stuff.
- Yeah I know it was used in V4.5 and people are having trouble trying to adjust/make it compatible as a plugin for V5. For whatever reason whenever using any tables... it ALWAYS wants to put a border in so I have had to use atrb to remove the border. Even in V5 it still wants to do it on any table I was making as a table prior to reaching a decision that "I cannot do this, and if there is no plugin/request for it I better try to request one."

Removing/adjusting atrb stuff does not bother me, remaking whole templates and stuff for (gods its increased in the past month) 5k threads/posts now... now that bothers me.

I just cross my finger since that can be fixed in time with a style converter. Atrb stuff, not a huge deal, if I can figure out why/how the darn borders can be removed. I can easily remove 1 line later from the posts.

---

II. Side-tables and such

I have already posted in specific posts about those issues, but nothing has changed for those threads since mid-December about the issues; hence I have been throwing out questions to try and move it all along.

So far I have not seen any template modifications for the few things I have asked for and already posted threads requesting help on them which have yet to really be answered.

The problem about the padding is that, if you look on my site, it puts that blue gradient around the images but also at the bottom/bridge gap between the image and the forums listed in each category. If you remove the gradient using what is posted below, it ends up making this ...transparent gap of 5px or so under the category image and the first forum listed...since the gradient "use to" be there.

It's difficult to remove that gradient without it messing up and separating the category image from the forums listed within it. I do not know if it is due to the category collapse plugin (it does not seem to be) but it definately is not working right and so I have been trying to figure out a better way..

So far, no one has had any answers on how to fix it, or a simple plugin to just change category names to images. Sure, you can do it in the properties listing of each Category by using url but... again its that problem with the gradient breaking everything if the gradient is there... or removed using what you stated. Tried it several times thinking it was a bug way before requesting it and decided that if it is a bug its nothing I can fix...

For the gradient, if you go to the themes > visual editor portion, Select Body (Content), expand the Containers > Title Bars
dropdown. There is a section under 'background colour' that says
'background image'. Click the dropdown and select the first option
("none"), which will remove the gradient.

---

III. The NavTree can be used to jump to previous forums, sorry just bad terminology on my end.

Yeah I am trying to move it or fix it so that it isn't so..... bleh.

When using Side-tables plugins, they automatically crop/move the News Fader to the right place but not the navtree at all. And because the side-table is still bugged (if you move it so that the side tables are to either side of your forum banner) it overlaps the navtree/forums and everything... and so far many of us have posted in that particular thread trying to shed light on this problem but as of yet there has not been any help/fix for it.. thus I am wondering how/why/if it is even possible to remove/move the navtree in the first place...

[Kami]

I. It should be fairly easy. 

Using [table][tr][td]one[/td][td]two[/td][/tr][/table] gets you

one

two

with no borders, so it doesn't look like you'll actually have to add anything, just remove the [atrb] tag. :] As far as defining width, again you'll have to remove the [atrb] tag and use table style="width:###px;" within the opening table tag:

[table style="width:500px;"][tr][td]test[/td][/tr][/table]
(with a border to show width)

test

II. I really recommend just waiting, honestly. The best support you're going to get for a plugin is from the plugin creator, so have some patience. A lot of people are just winding up their holidays or may be busy with returns to school / work, so repeatedly asking for help in multiple places about the same thing is really just extra effort on your behalf. If people can't fix your problem in your original thread / you're still waiting for replies, posting MORE times in MORE places is just going to yield the same results. Bump your thread every so often (not sure what the bumping rules are here, but 24 hours wait is probably a good guess), and wait patiently for replies.

You're probably not going to get too much more in this thread specifically. For one, your opening post has a LOT of information (again, best posted in their individual areas/threads) and it's honestly not 100% clear what you need. It may be easier for you to post a tonne of information all at once, but that's not how support is best handled.

Looking over what you wrote regarding the visual editor being 'bugged', I can tell you it's (probably) not - I don't have a gradient in my categories on my test site. If you're experiencing trouble with it, it's likely because of a conflict with something else (such as a plugin). Try disabling all plugins on your forum first, then attempt to remove the gradient again. IF it doesn't work, then it should be reported in the Bugs board. If it DOES work, then re-enable your plugins one by one (checking the forum each time) and see which plugin it is conflicting with.


III. Yes, it is possible to move the nav tree. I've done it. If it's a conflict with the side boards plugin, as you seem to indicate by this

 and so far many of us have posted in that particular thread trying to shed light on this problem but as of yet there has not been any help/fix for it

which goes back to what I said in II about waiting for the plugin thread to update. In the "Layout templates" section of the admin panel, click Forum Wrapper and find this:

<div id="navigation-tree">
$[navigation.tree]
</div>


This is the nav tree (not including the 'participated' button). Fiddle with it as you like. To control the CSS, go to the Visual Editor, click "CSS template", and CTRL/CMMD F find "navigation-tree". If you can't figure it out yourself, then keep an eye on the thread you originally posted in and have patience. :]