faddah

whoops! @iandunn , they closed that #41174 bug as it was on Trac WordPress core, not Meta Trac. re-filed it, here, Meta Trac Ticket #2899 — https://meta.trac.www.ads-software.com/ticket/2899#ticket

best,

— faddah wolf
portland, oregon, u.s.a.

@iandunn – done. see: https://core.trac.www.ads-software.com/ticket/41174#ticket. i have no idea how to add that good-first-bug keyword.

best,

— faddah wolf
portland, oregon, u.s.a.

thanks. that’s a nice hack, but not really a solution to my problem. if they update core 3.5.x or the text widget itself, all that work gets wiped and/or i have to re-do it again (provided that code you hacked is available).

i just want to know if it’s wordpress codex “canon” that you can’t put <script> tags in the text widget in the sidebar or not. if not, what can be done to fix that, short of hacking the code for the text widget.

i do appreciate your answer, but i need to know why this is happening. thank you, though. still unresolved.

best,

— faddah wolf
portland, oregon

Seacoast Web Design —

well, o.k., thank you for that, sure. yes, i know that is the one tried and true way to fish out which plug-in zotz’d my site, sure. i remember testing for stuff like this with old mac os classic 9 or less for extension/control-panel conflicts, sure.

however, that does not really answer my question. what i still want to know is: does the wordpress MySQL database keep a historic record, with date and time, of updates, and if so, where can it be found, please?

i have updated a number of plug-ins in the last two months. i would like to narrow it down to just the plug-ins i have updated in the last two weeks, when i know the error occurred, just can’t remember all of them. i know it wasn’t my fiddling with the css or php, as i have not touched that in a year.

besides all this, i think it would be helpful to have some db method by which you can fetch your update history, core, themes and plug-ins, even if i didn’t have this problem. a sort of update history manifest to help track issues.

if you wish to see my wordpress site where this is happening, see —> https://ialsowent.com/

i’ve done a temporary band-aid fix, adding to my child theme style.css —

#main {
    ...
    overflow: hidden;
    ...
}

…to the #main div so the background color is back to the same as the primary for the two widget sidebars, but i’d like to find out what update in the last two weeks did it so i can remove that.

again, really want to know if the wordpress MySQL db keeps a historic record of updates, and if so, what table to access it in? that is my question.

thank you.

best,

— faddah wolf

i don’t think there is any need to step in here and be pro bono attorney, good cop, bad cop, donut-eating cop, protector, white knight or helicopter-parent for otto. i’m assuming otto is a reasonable, grown adult who can respond for himself, if he so chooses. i feel if you upload a plug-in to the www.ads-software.com repository, for pay or no, you commit yourself to supporting that technology for its lifespan and responding properly when users report valid issues with a bit more than “i need more info, it’s working for me,” when plenty of info to reproduce has been detailed. if you do not wish to support your tech, you should remove it from the repository and notify of such where you can.

the quick work around to get out of the trapped hell of not being able to log-in with otto’s facebook connect plug-in turned on for your WP site is to log-out of facebook in the browser session you’re in, and also clear cache and/or cookies if that alone does not work, and try logging in to your WP site again. you then need to turn off the log-in through facebook in the plug-in settings or register your WP log-in account through facebook through his plug-in. that is what worked for me.

however, nowhere is this detail documented for his plug-in documented in the plug-in or plug-in page. this needs to be documented by otto, at least on the www.ads-software.com plug-in page. and also, the requested user bug reports, that it should not lock you out if you already have a valid log-in with your WP site simply because you haven’t connected your log-in with facebook yet. that is a real issue here and needs to be addressed. it’s just plain, simple, common UI/UX horse sense.

anyway, that’s my input here on the workaround and the documentation and bug fix that is necessary here. we’ll see if otto responds.

best,

— faddah
portland, oregon

otto, the problem described here, of being stuck in a loop on log-in and unable to get to the regular log-in page and log-in as an admin and disable this feature, or the plug-in, is happening also on the site i’m working on, https://www.fullofwin.us/wp-login.php.

this is especially hard to deal with as i cannot get to a regular log-in to log-in with my admin credentials and disable what i need to make this work properly. my client can no longer log-in either, which makes me look like crap.

several people now have described this same problem to you, in greater and greater detail. simply coming back and saying things akin to, “welp, not happening for me, working fine, need more info!” without properly detailing what that “more info” would be is not being very customer responsive.

will there be a fix for this in a future update to the plug-in? if so, when? otherwise, i will have to disable it off my client’s site.

please advise at your earliest convenience.

— faddah wolf
portland, oregon

hi,

o.k., i got it to work — you were correct, it was matter of figuring out the correct spelling in the “namespace” field of the developer facebook app to get it to work.

the problem was — our “namespace” in facebook for the fanpage was the following — https://www.facebook.com/fullofwin.us

the problem was, developer facebook apps don’t like anything but lowercase letters in the “namespace” field, leaving me scratching my head was to what to put in there, as i keep getting errors for “fullofwin.us” and just “fullofwin.” both kept erroring out on me.

i finally figured out, as it was not really explicitly written anywhere, that you just remove anything that isn’t lower case letters in the developer facebook app “namespace” field. just “fullofwinus,” no punctuation at all, in the developer facebook app “namespace” field worked, finally.

so —

a fan page like “https://www.facebook.com/mycoolpage.fun”

would need to be in the facebook developer app in the “namespace” field — mycoolpagefun

no capitals, no punctuation.

i would highly suggest, in future updates to your app, you please make this explicit in the instructions in the set-up of your plug-in, letting your users know, step-by-step, that in setting up the developer facebook app, that if their fanpage has any punctuation or capitals in the namespace, then in the “namespace” field set-up, they make capitals lowercase and remove any punctuation.

in any case, you can now consider this resolved. thank you for the help.

best,

— faddah wolf
portland, oregon

wow! that was quick. looks like sergey fixed the trackback issue… by adding two brackets! see latest updates – Trac, #21624, “Multiplle Trackbacks field in edit screen removes spaces btw. URL’s on save/update in 3.4 & 3.4.1.” & the 21624:21624.patch .

so, might be in 3.4.2. so yay! thanx for working this out with us, all.

— faddah
portland, oregon

o.k., new ticket is created in Trac, #21624, “Multiplle Trackbacks field in edit screen removes spaces btw. URL’s on save/update in 3.4 & 3.4.1.”

some follow-up from before:

i understand that you, Ipstenu don’t feel trackbacks are useful, or at least don’t use them yourself, and just use the pingbacks that are in-line, that go automatically to other WP sites, and the sites you mention, like blogger, that receive WP pingbacks; and this, as you state, has not been totally updated in the codex material i quoted to you. i also acknowledge you think trackbacks are turned off by a lot of people as possibly used as spam.

However…

trackbacks are still useful.

yes, blogger, MT, WP and other CMS’s acknowledge the automatic pingback in-line in a post or page, others do not, and you did not mention Drupal, or Joomla, etc. also, as readily available open source and other CMS’s are nowadays, the majority of web sites one might link to out there are still done in straight HTML/CSS, with some javascript/jquery plug-ins to help and google analytics. for those, you need trackbacks. also, trackbacks and pingbacks are both useful, because those links in other sites draw possible traffic from those reading comments on the other linked-to site, seeing that there is related material referenced from there at your site.

also, if you have akismet or a similar plug-in running, that relegates most spammy trackbacks or pingbacks from truly unrelated sites into your comment spam folder.

my 2 cents about why trackbacks still are needed.

we’ll see what happens with the Trac defect.

thank you for all your input, help and guidance throughout.

best,

— faddah
portland, oregon

hi again, ipstenu,

thank you for responding again and the follow up. i’m glad that it seems you understand a little better what we are trying to do here, that is a part of the main WP core edit post screen. however, some things you responded with have me a bit a confused.

Okay… Wow. I honestly did not know ANYONE still did that. For the last umpteen years, you just in-line linked, and every blogging system picks that up now. Really ??

this seems to fly in direct contradiction to what www.ads-software.com’s codex currently says about non-WP site linked trackbacks, and what i quoted to you previously in this thread from the current WP codex in https://codex.www.ads-software.com/Writing_Posts , https://codex.www.ads-software.com/Introduction_to_Blogging#Trackbacks , and https://codex.www.ads-software.com/Introduction_to_Blogging#Pingbacks . what you say is true about pingbacks, which are in-line links to other WP sites, but the current codex says quite plainly this is what you do with trackbacks, which are to non-WP sites. or at least, that is what the codex, in the sections i’ve quoted to you, says.

if i may please ask, is there some section of www.ads-software.com or the codex or some other documentation that i am missing, that supports what you are saying here? it’s not that i doubt you, but as i point out, this is in contradiction to what the WP codex says.

I dug back through trac, and the only related change I see is this one: https://core.trac.www.ads-software.com/changeset/19675

The ticket it’s based on is https://core.trac.www.ads-software.com/ticket/17560

o.k., that appears to make sense that it might be where this change in WP 3.4 & 3.4.1 came from. however, if this is just for windows live writer, it seems a bit cutting off the nose to spite the face. the problem he was getting was in the server returning in the cron “comma separated,” and in the trackbacks field in the WP edit post screen, it clearly states clearly to separate the URLs with spaces only. in sanitizing, while i’m not quite sure what constant variables like “PREG_SPLIT_NO_EMPTY” or function/method lines like —

else
    $to_ping = '';

… do, exactly, it appears they are, as you guess, removing spaces entirely where they don’t need to in the trackback field and thus might be causing the problem.

For reporting bugs: https://make.www.ads-software.com/core/handbook/reporting-bugs/

o.k., i’ll file a bug there after reading then accompanying how-to-file info, and report back here when i have done so.

thank you again for working with me on this. i’d be interested on your response to the above.

best,

— faddah
portland, oregon

hi ipstenu,

thank you for your response.

as to your requests for more info on this issue —

How are you ‘sending’ these trackbacks?

i can’t speak for stergos (hopefully she’ll see this and respond also), but for myself, i am doing it just as the www.ads-software.com support info says to do it, in the trackback field provided by wp-core in the edit post screen. see — https://codex.www.ads-software.com/Writing_Posts , and https://codex.www.ads-software.com/Introduction_to_Blogging#Trackbacks , and https://codex.www.ads-software.com/Introduction_to_Blogging#Pingbacks .

i put my referenced links in that provided trackback field in the edit post screen of wp-core, i separate each link with a space, as it says to do on that edit screen, when there are multiple links. prior to WP 3.4, doing that would notify the non-WP legacy sites that i referenced them just fine. in WP 3.4 & still in 3.4.1, it takes the multiple links, separated by spaces as it says to in the edit post WP screen, and takes out the spaces so it becomes one, long, meaningless garbage line, then attempts to send to that (which is garbage). consequently, the separate non-WP sites never get notified of the trackback.

For example, when I do that, I tend to have an in-line link. In my sentence, I’ll link back to the site I’m talking about. I did this just yesterday, and it worked fine, so let’s first make sure we’re all talking the same thing.

i do that, and for sites that are non-WP, i put links, sometimes multiple ones, separated by spaces, as it says to in that trackback field in the edit post WP screen. that’s what you should do. worked fine prior to WP 3.4. in WP 3.4 & 3.4.1, removes the spaces between links on “save draft” or “publish” and the track back links become a smushed together garbage line.

Are you just putting in a raw URL, two in a row, to ‘ping’ another site?

i am doing this as a trackback, to non-WP sites, as i know WP site are automatically pingbacked. so yes, as it says to in the edit post WP screen in WP-Core, i put in multiple non-WP links i reference and separate them with a space. prior to WP 3.4, this worked fine. in WP 3.4 & 3.4.1, takes out the spaces on “save draft” or “publish” and it becomes a garbage line.

this is easy enough to test. in WP 3.4 or 3.4.1 —

1. create a new post in WP
2. in the post, have links in-line with your verbiage to non-WP sites, say three of them.
3. in the trackback field in the edit post WP screen, put your three or so non-WP site links, separated by spaces, as it says to right on the screen for that trackback field.
4. click on “save draft” or “publish.”
5. go back and look at at the trackback field.

expected result —
in WP 3.3.x and earlier versions, it handled the non-WP trackbacks fine and notified those sites of the links in the post or page to it.

issue —
in WP 3.4 & 3.4.1 still, the spaces between the links in the trackback field are removed on “save draft” or “publish” and the multiple link line becomes one long garbage line and WP attempts to notify that, which, of course does not work.

i hope that all answers your queries and makes it clearer to you. please let us no if you have any further questions, but this should be enough to notify WP-Core devs thru trace and post an issue, please.

thank you for your response to this. i hope this moves this along.

best,

— faddah
portland, oregon.

bump! i’m seeing this issue also. where do we file bugs for wp core? and I’m seeing it in 3.4.1.

and has anyone tested to see if this is 3.4.1 itself, or 3.4.1 reacting badly against a certain theme or plug-in? i’m using a child theme of twentyeleven i developed and several plug-ins at my site, https://ialsowent.com.

again: wordpress admins or core devs, any help, at least that you acknowledge the problem exists and are working on a fix, would be appreciated.

— faddah
portland, oregon.

@explorz & @saradiop,

so here’s the code i extended in my child theme of twentyeleven —>

#access li:hover > a, #access a:focus {
	background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#eddcca), to(#eddcca)); /* Older webkit syntax */
	background: -webkit-linear-gradient(#eddcca, #eddcca);
	background-color: #eddcca; /* Show a solid color for older browsers */
	background-color: -moz-linear-gradient(#eddcca, #eddcca);
	background-color: -o-linear-gradient(#eddcca, #eddcca);
	color: #373737;

so to change the border color, you could add to that block —>

...
	border-color: -webkit-linear-gradient(#ff9800, #ff9800);
	border-color: #ff9800; /* Show a solid color for older browsers */
	border-color: -moz-linear-gradient(#ff9800, #ff9800);
	border-color: -o-linear-gradient(#ff9800, #ff9800);
...

give that a try, or play around in some of the other #access selectors.

— faddah

then you read my answer already. no fix for conflict with other google plug-ins for wordpress, like google connect, only solution is to delete it, no word from @raggedrobbins as to a fix with the conflict.

actually, yes, tho’ it requires a hack into sharedaddy php files you have to remember to re-do each every time you need to update the plug-in, until they include it as a feature. see this thread in the forums. good luck, works for me.