Forum Replies Created
-
AuthorPosts
-
v 4.7.1 should hopefully also now take care of those bits
seems fine now.
you do however seem to have some strange visual artefacts next to any selected/added ingredients (on the right).
that has something to do with your theme , but i’ll see if i can do something that deals with this too and forces these to disappearit’s actually the way you have designed your scrollbars.
will have to do a bit of tweaking, but it’s minor in any case and has nothing to do with functionalityfor example, the version you put back on the server will not have a “comment” before any additional comments (as the db will not have been updated to that effect), and you also have old css files….
what changes discussed did *you* do to that plugin (unless you are talking about different things entirely) ?…
in any case, the latest is 4.7 and – looking at your files/outcome there – you are somewhere in between
when i put things on your test server, i did not always update versions numbers when i changed things (as that can get tedious when testing things, before actually making it an official release so to speak), so I would have thought best thing is – to make sure we are looking at the same thing – i’ll put 4.7 on there (if you give me the ok)
ok
on a different note though, you seem to have overwritten the AI plugin on your test server again with old files ?! (or old db entries ? cant be sure)
>Not sure how to test it has worked though ;)
just look at the page source
if it sayslink rel=’stylesheet’ id=’cff-css’ href=’http://blablablablbalab/cff-style.css?ver=4.1
etc it’s fine otherwise it just says
link rel=’stylesheet’ id=’cff-css’ href=’http://blablablablbalab/cff-style.css
(same goes for js files)
that bit does:
remove_wp_ver_css_js
to spell it out
——no version numbers——a) day 1: customer comes to site , does his thing
b) day 2: plugin gets updated, javascript changes and server expects those js variables to be passed on
c) day 3: customer comes back to site, customers browser says: wait, i do not need to downlaod that javascript again, i already got it cached, let m use that oned)result=> some, more or fewer of required variables get sent to server as old js is being used
e) server response: what do you want from me ?
—– with version numbers——
a) and b) are the same
c) customer comes back to site, browser says: “hang on, that javascript file has changed , better download/use the new version”d)… we all live happily ever after…
(same goes for css by the way ,except that it won’t be fatal, just screws up your layout)
as long as you are omitting version numbers , i am not even going to try, sorry…
dunno, maybe your theme or some plugin does this…
Not quite sure what’s not a good idea…
omitting version numbers
>and let you know of any faults.
please douploaded an updated version to your test server.
should now all be fine (and include a label for textbox entries)
will do some checking tomorrow..
PS:
you test server omits version numbers in linked files (css/js) , so you might have to clear your cache/reload pages(it isn’t such a good idea to do that btw)
i guess i could add some label in front of those comments that makes it clearer that it’s a comment or something
in any case.
this will not be an issue anymore with the update which should be done tomorrow
(just need to tweak a couple more css bits)ie , NEVER have
define(‘WP_DEBUG_DISPLAY’, true);
on a production servera) can’t replicate this (as in being an error , stopping me from adding this to the cart)
b) i *can* see this in the debug log. easy enough to fix
(though a production server should never output these errors, only log them . if you output anything to ajax other than what needs to be there (warnings,errors, notices – you name it WILL fall over – hence the error_reporting(0) at the top of the ajax files as – more often than not – other plugins throw many many notices)… anyway, i digress…that’s a whole topic in itselfc) – pretty much just ignore b) . i’ll take care of those particular warning …
>So far so good. No issues to report.
sounds promising.
>Thanks again for your support.
thanks for being a guinea pigin the meantime, i am messing around with making those radio buttons behave better on all devices
so the selected black radio input dot is not all over the place on some browsers/devices…think i got it, but need a bit more testing as i had to add a span element
and – while i was at it – i also enabled the text to be clicked as opposed to just the button next to an ingredient. seemed to be an obvious thing to do really….
I have put a new version on your test server to test things before making it globally available.
from what i can see, this seems to work now having tried a few of your menu items .
However, as you probably know your setup better than i do, it would be helpful if you could just double check items you know might have a setup that could/did cause issues
(and – of course let me know if you find any)this should now be fixed in 2.1.7.4 (once and for all one hopes)
had a quick look and i know why this is
it only ever seems to happen in conjunction with the yoast SEO plugin.
having said that, I was reasonably certain this was taken account of ages ago – then again, maybe wptouch in this case plays also a role…
not sure yet, but will try to replicate here first -
AuthorPosts